CSP – Mozilla content security policy

This is my cup of tea, a whole new way to prevent XSS and related attacks. I’ve been looking at the specification and I like the core of the policy preventing external scripts, eval etc. But reading it I started to think of ways around it because it’s fun :)

Meta tag

The meta tag seems like a bad idea to me, if a site enforced the policy from a http header then a attacker controlled meta tag could merge policy data with an attacker’s evil policy.

Code will not be created from strings

I’m not sure what this is meant to prevent as the allowed section states it allows setTimeout, setInterval with functions as an argument. So you can do this:- setTimeout(function(){alert(1);//any code}); Or redefine existing functions, I’m not sure that preventing tainted javascript will work this way as there are many ways to obfuscate and execute code.

Abusing the whitelist

Finally my other idea was injecting javascript onto itself using a HTML page. This assumes the CSP policy allows scripts to be executed from it’s own domain. The attack also relies on the fact that you can control the output of the entire page or the output is in quirks mode with any E4X breaking code. So the vectors would work like so:-

The script is commented out when the HTML is executed because it references itself as javascript.

alert(1)//

Here the script injects itself and the resulting javascript ignores the script tag as inline e4x:-

alert(1);;

Demo’s of the vectors are available here:-
CSP1 without E4X
CSP2 with E4X

Update…

I’ve updated the vectors and made the e4x one more realistic. Here is a Firefox 3.5 version which gets round the “whole program” error by splitting the HTML and inserting a Javascript statement:-

CSP3 with e4x FF 3.5

Of course these attacks are theoretical because I’ve not actually had chance to test CSP, is there a beta? Anyway these vectors could easily be protected by enforcing script content to have the correct headers and not allow HTML data.

10 Responses to “CSP – Mozilla content security policy”

  1. Wladimir Palant writes:

    Concerning “code will not be created from strings” – converting a string to code is a common source of vulnerabilities, websites who use it are often careless about what they take as input (e.g. they would eval cookie values). I wrote about this in http://adblockplus.org/blog/five-wrong-reasons-to-use-eval-in-an-extension, only difference for websites is that some alternatives to eval() are not available. However, this is a bad coding pattern that comes from ignorance – disallowing it however means that the web developer is aware of this being a bad choice and knows a better way. So the only case where I can imagine this feature being used is some (knowledgeable) architect making sure his (far less experienced) code monkeys don’t use this pattern.

  2. sirdarckcat writes:

    “code will not be created from strings”
    is to avoid dom based xss attacks, anyway Im not sure how they’ll try to assess that being that a lot of people uses eval/setTimeout/setInterval/location=”javascript:”/etc..

    Anyway, I ‘ve been planning to can create something similar to CSP that is cross browser, more flexible and more secure (yay!!) :).

    I’ll be reviewing the details with a couple of people before releasing the specs.

    Greetz!!

  3. Gareth Heyes writes:

    @Wladimir

    Good point that’s the only way it would be of any use.

    @sirdarckcat

    DOM based attacks wouldn’t be useful here because CSP disallows inline script tags. JSON attacks or injection within external scripts would but like I say there are ways of executing code without eval etc. like I’m sure we all know.

    BTW I’ve updated the e4x example to be more realistic

  4. ebo writes:

    “meta tag could merge policy” If a http header X-Content-Security-Policy is already set, you can’t merge the policy with your meta tag. In according to the spec, a new policy will be created from the intersection of the two policies.

  5. Gareth Heyes writes:

    @ebo

    I think the more sensible option would be for the http header to take priority when used and ignore an attacker supplied meta tag

  6. Wladimir Palant writes:

    Gareth, the meta tag is in fact not problematic since it can only make the policy stricter – this is of no use to the attacker. But I really wonder how a situation can happen where both the headers and the meta tag can be specified. Probably a server with a generically strict policy (all content served with the same headers) where a few sites want an even stricter policy.

  7. Wladimir Palant writes:

    Should have been “a few pages” rather than “a few sites” above.

  8. Gareth Heyes writes:

    @Wladimir

    If you can only make the policy stricter this is still no good because you are giving the attacker control over the page. Should an attacker be able to remove the eval function from a page? Or maybe disable images from an external site, yeah it’s not as serious as modifying the policy by adding it but it is still an issue IMHO.

  9. Brandon Sterne writes:

    Great post, Gareth. I’d like to respond to a few of the points you brought up.

    1. The E4X trick is a good one. I have updated the spec to require that external scripts be served with a valid MIME type for JavaScript. Great catch!

    2. With regard to “no code from strings”, Wladimir’s post pretty much covers it. eval provides too much rope for developers to hang themselves with, so CSP turns it off by default. Of course, sites that absolutely need to use those APIs can turn this restriction off.

    3. Regarding <meta> policy, I think you and Wladimir raised all the relevant points. There’s no specific security risk that an injected <meta> policy introduces, but it could cause bustage for the page. In fact Sid, one of the developers implementing CSP, has proposed removing it from the design:
    http://blog.sidstamm.com/2009/06/csp-with-or-without-meta.html
    I don’t feel strongly in favor of keeping it, but I do know that some users aren’t able to set HTTP headers in their environment. This is a risk vs. reward that will have to be considered.

    Thanks again for the great feedback and I can’t wait to see what you’ll produce when you get a nightly build in your hands with a working implementation!

  10. Gareth Heyes writes:

    @Brandon

    No probs I’ll look forward to testing the beta :)

    Regards the meta tag, when http header is used the meta should be ignored IMHO. If the strict rules are followed as in the spec. like the meta follows the head tag then it will be fine.