Re: [Content Security Policy] A more modular approach

On 31/01/11 22:59, Brandon Sterne wrote:
> 1. Rename allow to default-src.

I think this is better, although it makes me think we should have gone for:

src-default
src-script
src-object

etc.

everything-else-src would still be a more clear name...

> 2. TBD: does default-src mean:
>     a. a specific list of content restrictions, e.g. images,
>        stylesheets, fonts, (potentially modified in future versions of
>        CSP), all of which a browser must implement in order to be said
>        to support default-src
>     b. shorthand for all the content loading directives that a given
>        browser does support, even if it means that the list differs
>        across browsers

I think that if we are to have any sort of incremental implementation, 
it must mean "everything else the browser chooses to restrict which is 
not specified more specifically in the policy".

In other words, if you have a site foo.com and it loads images from 
bar.com, and you do "default-src: 'self'; script-src: baz.com", and it 
happens to still work, you only have yourself to blame if it doesn't 
work in newer browsers which have added images to their internal list of 
restricted load types.

IOW, site owners should be told: "_Assume_ that default-src restricts 
every other external load you do for which you do not have a more 
specific policy." I'd hope at least one browser would implement that 
anyway. :-)

> 3. default-src is no longer required
>     a. browsers are free to implement only the directives they feel are
>        valuable
>     b. sites that want protection in browsers that don't support
>        default-src will need to enumerate the directives that are
>        supported there

So in the absence of default-src, you just restrict what is explicitly 
specified, but if it is present, you also restrict an unknown number of 
other things, possibly up to and including every load you do. Is that 
the idea?

> 4. rename |options inline| to |options permit-xss| or something equally
>     scary

'permit-xss' is OK, but I might go for "options disable-xss-protection". 
It's nice and long, which is also a bit of a deterrent.

And you can imagine the news stories: "this XSS exploit wouldn't have 
worked on their site, but they set 'disable-xss-protection' in their 
Content Security Policy, so it does."

It becomes fairly clear who is at fault ;-)

> 5. TBD: given #3, we need a way to allow browsers not implementing
>     default-src to mitigate XSS via plugins.  Here are a couple of
>     alternatives we could pursue (not an exhaustive list):
>     a. remove script-src and add code-src directive to encompass script
>        loading plus plugin loading

Question: I can see someone wanting to load movies from youtube without 
wanting to load JS, but is that a distinction without a difference? Is 
it in fact security-risk equivalent to allowing both?

>     c. leave script-src and object-src and add new code-src directive
>        that encompasses both

Sounds like the worst of both worlds :-) With the exception of default, 
we should try and avoid loads being covered by more than one directive.

Gerv

Received on Tuesday, 1 February 2011 09:56:30 UTC