Comments on: CSP - Mozilla content security policy http://www.thespanner.co.uk/2009/06/23/csp-mozilla-content-security-policy/ A tool for designers dealing with programmers dealing with designers... Mon, 15 Mar 2010 10:40:45 +0000 http://wordpress.org/?v=2.6.2 By: Gareth Heyes http://www.thespanner.co.uk/2009/06/23/csp-mozilla-content-security-policy/#comment-1590 Gareth Heyes Tue, 30 Jun 2009 07:47:12 +0000 http://www.thespanner.co.uk/?p=448#comment-1590 @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. @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.

]]> By: Brandon Sterne http://www.thespanner.co.uk/2009/06/23/csp-mozilla-content-security-policy/#comment-1589 Brandon Sterne Mon, 29 Jun 2009 23:00:19 +0000 http://www.thespanner.co.uk/?p=448#comment-1589 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! 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!

]]> By: Gareth Heyes http://www.thespanner.co.uk/2009/06/23/csp-mozilla-content-security-policy/#comment-1586 Gareth Heyes Fri, 26 Jun 2009 14:01:53 +0000 http://www.thespanner.co.uk/?p=448#comment-1586 @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. @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.

]]> By: Wladimir Palant http://www.thespanner.co.uk/2009/06/23/csp-mozilla-content-security-policy/#comment-1585 Wladimir Palant Fri, 26 Jun 2009 13:57:41 +0000 http://www.thespanner.co.uk/?p=448#comment-1585 Should have been "a few pages" rather than "a few sites" above. Should have been “a few pages” rather than “a few sites” above.

]]> By: Wladimir Palant http://www.thespanner.co.uk/2009/06/23/csp-mozilla-content-security-policy/#comment-1584 Wladimir Palant Fri, 26 Jun 2009 13:56:42 +0000 http://www.thespanner.co.uk/?p=448#comment-1584 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. 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.

]]> By: Gareth Heyes http://www.thespanner.co.uk/2009/06/23/csp-mozilla-content-security-policy/#comment-1582 Gareth Heyes Wed, 24 Jun 2009 08:12:28 +0000 http://www.thespanner.co.uk/?p=448#comment-1582 @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 @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

]]> By: ebo http://www.thespanner.co.uk/2009/06/23/csp-mozilla-content-security-policy/#comment-1581 ebo Wed, 24 Jun 2009 08:06:33 +0000 http://www.thespanner.co.uk/?p=448#comment-1581 "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. “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.

]]> By: Gareth Heyes http://www.thespanner.co.uk/2009/06/23/csp-mozilla-content-security-policy/#comment-1580 Gareth Heyes Wed, 24 Jun 2009 07:44:12 +0000 http://www.thespanner.co.uk/?p=448#comment-1580 @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 @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

]]> By: sirdarckcat http://www.thespanner.co.uk/2009/06/23/csp-mozilla-content-security-policy/#comment-1579 sirdarckcat Wed, 24 Jun 2009 05:26:13 +0000 http://www.thespanner.co.uk/?p=448#comment-1579 "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!! “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!!

]]> By: Wladimir Palant http://www.thespanner.co.uk/2009/06/23/csp-mozilla-content-security-policy/#comment-1578 Wladimir Palant Tue, 23 Jun 2009 20:59:54 +0000 http://www.thespanner.co.uk/?p=448#comment-1578 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 <a href="http://adblockplus.org/blog/five-wrong-reasons-to-use-eval-in-an-extension" rel="nofollow">http://adblockplus.org/blog/five-wrong-reasons-to-use-eval-in-an-extension</a>, 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. 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.

]]>