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

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

From: Adam Barth <w3c@adambarth.com>
Date: Mon, 31 Jan 2011 09:03:03 -0800
Message-ID: <AANLkTimja09ext_wSXOfX=FvirJU9pY-r9pVBa8bjn-=@mail.gmail.com>
To: Gervase Markham <gerv@mozilla.org>
Cc: Lucas Adamski <ladamski@mozilla.com>, public-web-security@w3.org
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.


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:25 UTC