Web Application Security

Content Security Policy

What is it and why should I care?

Content Security Policy (CSP) is a new(ish) technology put together by Mozilla that Web apps can use as an additional layer of protection against Cross-Site Scripting (XSS). This protection against XSS is the primary goal of CSP technology. A secondary goal is to protect against clickjacking.

XSS is a complex issue, as is evident by the recommendations in the OWASP prevention “cheat sheets” for XSS in general and DOM based XSS. Overall, CSP does several things to help app developers deal with XSS.

Whitelist Content Locations

One reason XSS is quite harmful is that browsers implicitly trust the content received from the server, even if that content has been manipulated and is loading from an unintended location. This is where CSP provides protection from XSS: CSP allows app developers to declare a whitelist of trusted locations for content. Browsers that understand CSP will then respect that list, load only content from there, and ignore content that references locations outside the list.

No Inline Scripts

XSS is able to add scripts inline to content, because browsers have no way of knowing whether the site actually sent that content, or if an attacker added the script to the site content. CSP entirely prevents this by forcing the separation of content and code (great design!). However, this means that you must move all of your scripts to external files, which will require work for most apps − although it can be done. The upside of needing to follow this procedure is that in order for an attack to be successful with CSP, an attacker must be able to:

Step 1.  Inject a script tag at the head of your page

Step 2.  Make that script tag load from a trusted site within your whitelist

Step 3.  Control the referenced script at that trusted site

Thus, CSP makes an XSS attack significantly more difficult.

Note: One question that consistently comes up is what about event handling? Yes, CSP still allows event handling through the onXXX handlers or the addEventListener mechanism.

No Code from Strings (eval dies)

Another welcome addition to CSP is the blacklisting of functions that create code from strings. This means that usage of the evil eval is eliminated (along with a few other evals). Creating code from strings is a popular attack technique − and is rather difficult to trace − so the removal of all such functions is actually quite helpful.

Another common question stemming from the use of CSP is how to deal with JSON parsing. From a security perspective, the right way to do this has always been to actually parse the JSON instead of doing an eval anyway; and because this functionality is still available, nothing needs to change in this regard.

Policy Violation Reporting

A rather cool feature of CSP is that you can configure your site to have a violation reporting handler, which then lets you have that data available whether you run in either report-only mode or enforcing mode. In report-only mode, you can get reports of locations in your site where execution will be prevented when you enable CSP (a nice way to test). In enforcing mode, you will also get this data; while in production, you can also use this method as a simple XSS detection mechanism (resulting in “bad guy tried XSS and it didn’t run”).

What should I do about the availability of CSP?

Well, you should use it! Actually, CSP seems to be free from having any downside. It’s there to make your site safer, and even if a client’s browser does not support it, it is entirely backwards-compatible, so your site will not break for the client.

In general, I think the basic approach with CSP should be:

Step 1.  Solve XSS through your standard security development practices (you should already be doing this)

Step 2.  Learn about CSP – read the specs thoroughly

Step 3.  Make the changes to your site; then test and re-test (normal dev process)

Step 4.  Run in report-only mode and monitor any violations in order to find areas you still need to fix (this step can be skipped if you have a fully functional test suite that you can execute against your app in testing – good for you, if you do!)

Step 5. After you’re confident that your site is working properly, turn it on to the enforcing mode

As for how you actually implement CSP, you have two basic options: (1) an HTTP header, and (2) a META tag. The header option is preferred, and an example is listed below:

Content-Security-Policy: default-src ‘self’;

img-src *;

object-src media1.example.com media2.example.com *.cdn.example.com;

script-src trustedscripts.example.com;

report-uri http://example.com/post-csp-report

The example above says the following:

Line 1: By default, only allow content from ‘self’ or from the site represented by the current url

Line 2: Allow images from anywhere

Line 3: Allow objects from only the listed urls

Line 4: Allow scripts from only the listed url

Line 5: Use the listed url to report any violations of the specified policy

In summary, CSP is a very interesting and useful new technology to help battle XSS. It’s definitely a useful tool to add to your arsenal.















Tags: Cross Site Scripting, XSS
  • Josh

    CSP does have some downsides. For existing websites that have not separated content from script it is a major amount of refactoring, for a technology that is not terribly ubiquitous. In general it’s lack of support means that using security to justify a switch to a separation of content from functionality is not a winning sale.

    That said, what I like most about CSP is actually not the security aspect but that the separation enforces a very useful discipline in coding. I have long been a proponent that isolation of scripts into a distinct file improves the overall maintainability of a website, allowing for much more legibility of the overall project. I think it leads to better engineering, which is a quality that I think too few organizations truly appreciate.