Introduction:
Content Security Policy (CSP) is a good safety net against Cross Site Scripting (XSS). In fact, it’s the best one and I would recommend it to anyone building new sites.
For existing sites, implementing CSP can be a challenge because CSP introduces some restrictions by default and, if the code was written without these restrictions in mind, work will be required. Also, working around these issues can negate the benefits of applying a policy in the first place. In particular, inline scripts require thought; they’re commonly used and, if they’re allowed by your policy, the major benefit of CSP no longer applies. The only option available to make effective use of CSP, in the past, was to re-write the code to remove any existing inline scripts or styles.
Applying CSP to existing site might seem overwhelming at first but, considering the security benefit, the effort is well worth it. Fortunately, doing this has become much easier with CSP 2.
Some CSP 2 features:
CSP 2 provides some features that can really help; hash-source and nonce-source. These both provide a way of using inline scripts and styles without giving attackers free reign to inject things.
So how do they work? We’ll look at nonce-source first.
A CSP with a nonce-source might look like this:
content-security-policy: default-src 'self'; script-src 'nonce-2726c7f26c'
And the corresponding document might contain a script element that looks like this:
<script nonce="2726c7f26c">
alert(123);
</script>
There are 2 things to note here; firstly, it’s important that the nonce changes for each response (I’ve seen an example where it doesn’t!) and, secondly, it’s important that the nonce is sufficiently hard to predict.
Now, because the nonce changes in a way that isn’t predictable, the attacker doesn’t know what to inject and so, by only allowing script (or style) elements with valid nonce attributes, we can be sure that injections will fail.
And what about hash-source? Well, this is similar in that, again, a source in the CSP is used to ensure that a script or style element in the body is supposed to be there but the mechanism used differs. Rather than relying on an attribute on the script element in the document, hash-source provides a hash, in the CSP, of the script elements that are to be allowed in the document.
So for a script element like this:
<script>
alert(123);
</script>
You’d have a CSP containing a hash-source a bit like this:
content-security-policy: script-src 'sha256-cLuU6nVzrYJlo7rUa6TMmz3nylPFrPQrEUpOHllb5ic='
Obviously, you’d need to add a hash-source for each script or style you wanted to include in your document.
Which to use (and when):
So you may be wondering why there are two mechanisms (when both are designed to allow inline scripts and styles) and when you should use one rather than the other.
You should resist the temptation to use these mechanisms everywhere; these techniques are only intended for cases where removing inline scripts is not an option.
Nonce-source will be most useful in most cases because it is simpler. You only need to include a single source in your policy to cover a number of inline elements. The downside is that, since a nonce must only be used once, you need to generate a new header (and a new document) for each page load. This makes nonce-source a good option for dynamically generated pages, but completely unsuitable for static content.
Hash-source is more complicated; you have to generate hashes for each and every element you want to allow…. but, because it doesn’t rely on a value being unknown to an attacker, the CSP and the script element can remain the same. This makes hash-source a useful mechanism for protecting content that is served statically.
Words of warning:
Please be careful when using either of these mechanisms in dynamically generated content; if an attacker can inject content into something you’ve set a nonce attribute on (or something you generate a hash-source from) then you may have created a free bypass for an attacker.
Limitations:
The inline script restrictions imposed by CSP include script valued attributes (commonly used for DOM Level 0 event handlers, e.g. onclick); hash-source and nonce-source cannot help you with these. Currently CSP does not provide mechanisms to apply directives to such script valued attributes but let’s see what the future brings!
