Re: [Content Security Policy] A more modular approach

Thanks Brandon.  I'm going to try implementing script-src in WebKit as
a starting point.  I'll report back with my implementation experience.

(more comments inline)

On Tue, Feb 1, 2011 at 1:55 AM, Gervase Markham <gerv@mozilla.org> wrote:
> 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. :-)

The main risk with that approach is that default-src means something
different in each implementation.  To be sure you're not breaking
things, you need to test in every browser.  That said, I don't feel
that strongly about it.

>> 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 ;-)

disable-xss-protection sounds good to me.

>> 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?

Yeah, the more I think about it, the more I think it makes sense to
lump these together.  The distinctions are pretty subtle.  If we want
to give authors more control over plug-ins, the ability to control
which plugins are loaded seems more useful.

>>    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.

Adam

Received on Tuesday, 1 February 2011 18:48:36 UTC