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

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

From: Gervase Markham <gerv@mozilla.org>
Date: Mon, 31 Jan 2011 09:45:16 +0000
Message-ID: <4D4684AC.6060900@mozilla.org>
To: Adam Barth <w3c@adambarth.com>
CC: Lucas Adamski <ladamski@mozilla.com>, public-web-security@w3.org
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
  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 :-)

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

Received on Monday, 31 January 2011 09:45:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:18 UTC