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:30:41 +0000
Message-ID: <4D468141.4070302@mozilla.org>
To: Brandon Sterne <bsterne@mozilla.com>
CC: gaz Heyes <gazheyes@gmail.com>, public-web-security@w3.org
On 28/01/11 22:58, Brandon Sterne wrote:
> Okay, now we're getting somewhere.  In your example, as soon as the
> <iframe>  navigates the page, that would cause the page to be reloaded,
> which in our use case, would result in a new script nonce being
> delivered in the policy.
> In other words, yes, you can steal the script token using this
> technique, but if the token is being properly rotated, then the token
> would be invalid as soon as you reload the page with your new injected
> payload.
> Do I have this right?

Yes. Gaz was demonstrating to me why every page needs a new key.


Question is: is a script-key-based approach therefore infeasible because 
no-one will adopt it because it makes caching impossible?

I guess external script could still be cached if we defined something 
like the following as being permitted:

<script src="external.js">/* KEY_HERE */</script>

because external.js does not contain the key.


Received on Monday, 31 January 2011 09:31:17 UTC

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