Presentation covers Content Security Policy and other HTTP Security Headers.

1. CSP and HTTP Security Headers
ANOTHER LAYER OF DEFENSE IN DEPTH (FOR FREE*)
SHAWN GORRELL – LEAD ARCHITECT - FRB ATLANTA

2. 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

3. 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

4. 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.

5. 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)

6. 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)

7. CSP 1.0 Browser Support [2]

8. 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.

9. 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)

10. 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

11. 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/

12. 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.

13. 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

14. .NET Code/Configuration Examples
ActionFilterAttributes (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…

15. 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.

16. 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

17. 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

18. References
http://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

19. Sources
1. 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

20. Setting Headers through IIS
•http://www.iis.net/configreference/system.webserver/httpprotocol/customheaders

21. What a block looks like in Firebug

22. Web.config

23. ActionFilterAttribute

24. Controller with AFA

25. View

26. View

27. Javascript

28. Meta header