Re: [Content Security Policy] Proposal to move the debate forward

On Mon, Jan 31, 2011 at 1:45 AM, Gervase Markham <gerv@mozilla.org> wrote:
> On 31/01/11 06:26, Adam Barth wrote:
>>
>> As a starting point, I would like to be able to mitigate script
>> injection without coupling that with controlling how fonts are loaded.
>
> Or to put it slightly differently: you want to control how script is loaded
> without coupling that with how fonts are loaded.
>
> Which seems fair enough, if it were not actually quite difficult to define a
> mechanism which controls how scripts are loaded, implement it and deploy it,
> and then add to that mechanism something which controls how fonts and other
> resources are loaded, in a way which does not:
>
>  a) alter the deployed script mechanism in a backwardly-incompatible way
>  or
>  b) lead to much greater policy complexity than if everything had been
>    considered up-front.
>
> If you have a proposal for a policy syntax and mechanism which doesn't have
> this problem, let's hear it :-)

The "minimal edit distance" proposal from CSP would be to let folks
use the "script-src" directive without using the "allow" directive.
For example, we could make the following a valid policy:

Content-Security-Policy: script-src example.com

We could then later decide that "allow" was a valid directive.  Now,
I'm not sure that's the optimum path (and there are some details
w.r.t. plug-ins), but it at least plausibly proves the concept.

Adam


>> I don't really understand that paragraph.  I agree that we should
>> provide a policy framework that we can re-use for more things in the
>> future.  Today, however, I'm interested in mitigating scripting
>> injection.
>
> See above.
>
>>> Is it just extensibility?  It seems like you are perhaps fundamentally
>>> objecting to the default "allow:" policy, insofar that it is implicitly
>>> coupled to all of the other defined directives.
>>
>> Yes.  The "allow" construct is the worst offender of coupling concerns
>> I don't care about (e.g., font loading) with concerns I do care about
>> (e.g., script injection).
>
> My assertion is that if you don't start with something which specifies a
> general 'allow', you will later have to do either a) or b) above, neither of
> which is desirable.
>
>> Sure it can:
>>
>> script-whitelist="example.com *.akami.net"
>
> Or 'script-src', even? :-)
>
>> With suitable semantics, that sort of policy goes a long way towards
>> mitigating XSS.  Now, does it get every corner case of non-script
>> injection?  No.  Does it provide a lot of value at a reasonable cost?
>> Yes.  Sign me up.
>
> But then where do we go? If we implemented and deployed just the above, how
> would we achieve the other goals without doing either a) or b)?
>
> This is a genuine question - I'm not asserting it can't be done, but I'll
> need to be shown how it can.
>
> Gerv
>

Received on Monday, 31 January 2011 17:10:21 UTC