W3C home > Mailing lists > Public > public-web-security@w3.org > July 2011

Re: Using CSP

From: Adam Barth <w3c@adambarth.com>
Date: Tue, 19 Jul 2011 22:35:49 -0700
Message-ID: <CAJE5ia_LHWkeu+jRE2im3+vBzgXExgNGhJZoXv=uLubPU3GhAA@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: public-web-security@w3.org
On Tue, Jul 19, 2011 at 9:27 PM, Mark Nottingham <mnot@mnot.net> wrote:
> I just spent a small amount of time putting CSP onto my private site, <http://www.mnot.net/>.
>
> A few quick impressions, FWIW (yes, I realise it's still very much a work-in-progress):
>
> - Based on how the spec is written, I expected to be able to use multiple HTTP headers to refine policy; e.g., have a 'base' policy of "allow 'self'", and then in subdirectories add options, etc. as appropriate. However, in practice, this didn't seem to work; weird errors kept on coming up in the console (FF5 and Aurora), so I had to put the entire policy in one header, leading to lots of repetition.

WebKit doesn't implement policy refinement either.  It uses the simple
"first policy wins" approach.

> - An example of the 'options ...' syntax in the spec would help; I had to look at the BNF before I realised I couldn't just put a bare 'inline-script' directive in the header.

The "options" syntax got removed at some point.  I think Brandon is
updating the Firefox implementation to the new syntax.

> - I allowed script-src and img-src to load the Flickr image on the front page. This blocks the bug to geo.yahoo.com:
>
>> Warning: CSP: Directive "img-src http://www.mnot.net *.static.flickr.com" violated by http://geo.yahoo.com/p?s=792600102&t=cddd05d22e803ae993c87a7b2bbef800&r=http%3A%2F%2Fwww.mnot.net%2F&fl_ev=0&lang=en&intl=au
>
> Which is perhaps an interesting unintended (?) use of CSP. Personally, this is kind of cool, as Collusion previously showed my users as being tracked, even though I didn't intend it.

CSP does give you more control over content you integrate from third parties.

> One follow-up to that; I haven't enabled reporting yet, but if I did, I'd be flooded by reports of this. Having some mechanism to squelch a particular warning would be nice.

Any suggestions on how to accomplish that?  In some sense, it's not
that much extra traffic.  You'd get just as much extra traffic by
including one additional image on your page.  You can always filter at
the server.

> - Delicious.com badges (on the blog entries) use lots of eval(), so I'm not letting them execute. I suspect lots of services are going to have to tighten up their .JS to become more CSP-friendly.
>
> - Likewise, Moveable Type (locally installed) had lots of issues. I ended up allowing inline-script on it, although I'm not happy about that. I suppose in the long term, this is an "evangelisation" issue.
>
> - jQuery had some issues, but upgrading to 1.6 solved it. Cool.
>
> - I was a little surprised that external scripts that write script into the document will trigger inline script warnings; this makes sense, but it's going to cause problems with *lots* of things, so it's probably worth pointing out a little more prominently.

These scripts shouldn't use document.write anyway.  That prevents them
from being loaded asynchronously and from being used in XML documents.

> - I tried adding a X-WebKit-CSP header with the same policy on the front page, but Chrome behaved differently; e.g., it didn't want to load a local .js, even though that's allowed by the policy.

If you send me a reduced test case of the issue you're running into,
I'd be happy to fix it.

> - It'd probably be good to link from the Mozilla spec to the W3C-hosted one; Google skews towards the Moz one, so people may not find the more recent version.
>
> Next step is to integrate it into <http://redbot.org> -- both serving CSP on the site, and checking CSP header syntax.

Thanks for letting us know about your experience!

Adam
Received on Wednesday, 20 July 2011 05:36:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 20 July 2011 05:36:49 GMT