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