content security policy (csp)
TRANSCRIPT
CSP and HTTP Security HeadersANOTHER LAYER OF DEFENSE IN DEPTH (FOR FREE*)
SHAWN GORRELL – LEAD ARCHITECT - FRB ATLANTA
Outline About me
Content Security Policy – What is it?
Cross-Site Scripting (XSS)
Defense in Depth
Current industry state of CSP/HTTP Security Headers
Content Security Policy Directives
Content Security Policy Reporting
Other HTTP Security Headers
Code/Configuration Examples (.NET)
CSP Rules of Thumb
CSP Pain Points
PSA: Lessons learned from Penetration Testing
References
About me Lead Architect – FRB Atlanta
20+ years in software development (DoD, Telecom)
14 years with the FRS
C/C++, CF, Java, .NET
Wrote my first XSS blocking code in 2003 (cf_xssblock)
Survivor of countless Pen Tests
Content Security Policy (CSP) Content Security Policy (CSP) provides a standard HTTP header that allows website owners to declare approved sources of content that browsers should be allowed to load on that page —covered types are: JavaScript,
CSS,
HTML frames,
fonts,
Images,
XHR,
and embeddable objects such as Java applets, ActiveX, audio and video files. [1]
TL;DR – Browser based XSS protection mechanism. Least privilege approach that whitelists content you trust. Nothing else will execute. Assumes that inline scripts are bad.
Cross-Site Scripting (XSS) [10, 11]
Occurs when a web application gathers malicious data from a user (untrusted source). The data is usually gathered in the form of a hyperlink or form submission, database, or cookie which contains malicious content within it.
Malicious data is generally in the form of Javascript or HTML
Types are DOM-based, “stored” (persistent) and “reflected” (non-persistent)
Defense in Depth CSP does not replace, nor remove the need for server-side validation or output encoding. It is in addition to those.
Browser support is limited, so don’t count on it. Doesn’t work at all in old browsers.
As a general rule, all of the items in the OWASP Top 10 can be mitigated in multiple ways, so don’t pick one, pick at least two (if it isn’t overly resource intensive)
Never rely on something like a WAF as protection, protect your own apps.
Document and test your defenses (trust, but verify)
CSP 1.0 Browser Support [2]
Current state of CSP [3]
1.1 is current spec, 2.0 is in draft.
1.1 supports all features of 1.0, without breaking backwards compatibility.
Biggest difference in 1.1 is allowing inline scripts with Nonces, and meta tags for headers.
2.0 breaks a couple of things from 1.0/1.1. Be aware. Probably best to let 2.0 mature.
Content Security Policy (CSP) Adoption [4]
Least used security header, but usage has doubled since last year
CSP is the youngest of the security headers, and most difficult to implement, thus the slower adoption than other headers
Last year, half of the sites that implemented CSP did so incorrectly (be sure to test)
Content Security Policy Directives [5,6]
• default-src - sets defaults for script-src, object-src, style-src, img-src, media-src, frame-src, font-src and connect-src. If none of the previous directives exist in the policy the user-agent will enact the rules of the default-src values. (Rule of thumb – always set this and override as necessary)
• script-src - also has two additional settings: • unsafe-inline - allows the resource to execute script code. An example would be code that exists in an HTML element's on* event values, or the text content
of a script element inside the protected resource. (avoid)
• unsafe-eval - allows the resource to execute code dynamically in functions, such as eval, setTimeout, setInterval, new Function etc.(avoid)
• object-src - determines where plugins can be loaded and executed from.
• style-src - determines where CSS or style markup can be loaded from.
• img-src - determines where images can be loaded from.
• media-src - determines where video or audio data can be loaded from.
• frame-src - determines where frames can be embedded from.
• font-src - determines where web fonts can be loaded from.
• connect-src - restricts which resources can be used in XMLHttpRequest, WebSocket and EventSource.
• sandbox - optional directive which specifies a sandbox policy for 'safely' embedding content into a sandbox. (https://html.spec.whatwg.org/multipage/browsers.html#sandboxing-flag-set)
• report-uri – optional directive that specifies where policy violation reports are sent
Content Security Policy Directives Keywords [6]
'none’ matches nothing (use if you don’t want to allow that resource from any domain)
'self' matches the current origin, but not its subdomains
http://content-security-policy.com
CSP Builder - http://cspisawesome.com/
Content Security Policy Reporting [7]
If report-uri directive is used, any time that a request violates the policy, the browser will post the request to that uri with the details of the violation in a JSON structure. You can write your own CSP report receiver.
Using “Report-Only” is a great way to test the impact of your policy before implementing it.
If you roll your own, be mindful not to introduce a DoS vector.
Other HTTP Security Headers [8,9]
X-XSS-Protection (not supported on Firefox) (use it)
X-Content-Type-Options (not supported on Firefox) (use it)
X-Frame-Options (use it, if you use the CSP directive as well, make sure they match)
Strict-Transport-Security (not supported on IE) (use it if you can)
Public-Key-Pins (In draft, so not well supported. Interesting, but wait for it to mature)
Access-Control-Allow-Origin (use it if necessary)
https://www.veracode.com/blog/2014/03/guidelines-for-setting-security-headers
https://xato.net/secure-coding/security-headers/#.VP3IN8Z8NNJ
.NET Code/Configuration ExamplesActionFilterAttributes (allows selective application, but more code to manage)
Web.config (best, if you don’t need to do any inline – club not a scalpel)
IIS (alternative best, let someone else manage it – same comment about inline as web.config)
CSP 1.1 supports use of meta tags for CSP, if you’re going to allow inline, this may be the best approach because it allows you to be flexible. IIS and web.config don’t.
Show the code…
CSP Rules of Thumb Use SSL to prevent tampering of CSP/HTTP Security headers
Always set the default-src, and then override where necessary
Avoid wildcards
Whatever you implement, make sure to test it (incorrect configuration is as bad as doing nothing)
Do something, and refactor when you can do more. Even if you have to start by allowing inline and eval, implement the other parts that you can. Then work towards implementing it all.
Use Report only mode to test your policy before implementing it. Think of it like simulation mode on the WAF. It gives you a chance to see the real world impact of your policy.
Don’t use “limited browser support” as an excuse not to do this. Just do it. Browser support is pretty ok and it will continue to get better.
CSP Pain Points Lemon: No inline scripts or event handlers (onclick, etc). Must externalize scripts and bind event handlers to ids. (syntax example later)
Lemonade: Externalizing scripts draws a nice architectural line between content and code
This can cause issues with packaged UI frameworks (Telerik, Infragistics) – need to test
My testing with KendoUI (Telerik) didn’t surface any showstoppers (will show if I’ve got time)
No warranty is expressed or implied in the previous bullet – you have to test
You need to test – I’ve said it 3 times so you’ll remember
PSA: Lessons Learned from Pen Testing Don’t defensively respond with “prove it”, that takes more time than a fix
Accept the help from Pen Testers if you don’t understand the finding/fix, that’s what they are there for
Share results/remediation across all your teams/projects (a lesson learned that isn’t shared is not a lesson learned)
Even if the risk profile of an app is low, fixes are almost always easy so just do them
Prioritize timing of fixes based on risk and resources
Develop your own testing program (static/dynamic), and do it per iteration – fewer surprises
Referenceshttp://www.cspplayground.com/
http://erlend.oftedal.no/blog/csp/readiness/
http://www.codeproject.com/Articles/877794/Preventing-XSS-in-ASP-NET-Made-Easy
http://discover.cigital.com/l/28332/2014-07-28/3kw1kp
https://www.owasp.org/index.php/Content_Security_Policy
https://www.veracode.com/blog/2014/03/guidelines-for-setting-security-headers
http://www.dotnetnoob.com/2012/09/security-through-http-response-headers.html
Sources1. http://en.wikipedia.org/wiki/Content_Security_Policy
2. http://caniuse.com/#feat=contentsecuritypolicy
3. https://w3c.github.io/webappsec/specs/content-security-policy/
4. https://www.veracode.com/blog/2014/10/security-headers-top-1000000-websites-october-2014-report
5. https://www.veracode.com/blog/2014/03/guidelines-for-setting-security-headers
6. http://content-security-policy.com
7. http://www.html5rocks.com/en/tutorials/security/content-security-policy/#reporting
8. https://www.veracode.com/blog/2014/03/guidelines-for-setting-security-headers
9. https://xato.net/secure-coding/security-headers/#.VP3IN8Z8NNJ
10. https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29
11. http://www.veracode.com/security/xss
Setting Headers through IIS•http://www.iis.net/configreference/system.webserver/httpprotocol/customheaders
What a block looks like in Firebug
Web.config
ActionFilterAttribute
Controller with AFA
View
View
Javascript
Meta header