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: Fri, 28 Jan 2011 10:48:44 +0000
Message-ID: <4D429F0C.4090503@mozilla.org>
To: gaz Heyes <gazheyes@gmail.com>
CC: Brandon Sterne <bsterne@mozilla.com>, public-web-security@w3.org
On 28/01/11 10:41, gaz Heyes wrote:
> On 28 January 2011 10:33, Gervase Markham <gerv@mozilla.org
> <mailto:gerv@mozilla.org>> wrote:
>
>     How would you steal all tokens if you couldn't run any script
>     because you didn't have the token?
>
> HTML5 makes that nice and easy for us, form-action, form-target,
> <textarea>, css styles width:100%;height:100%; there a lots of ways and
> HTML5 increases them.

You have to a) inject a form, b) find a way for the form to include the 
data you need, and c) get it submitted.

Without script, c) requires explicit user action.

Then, after you have the session token, you have to match it up with the 
user you stole it from, and persuade them to again click on some sort of 
link you control which has an XSS vector with the new token embedded, so 
you can finally start executing malicious script in their page.

[If the token is, in itself, valuable (e.g. it's a pure SessionID) then 
you could start to do impersonation. So I agree (thank you for helping 
me see this) it's not good to have them the same - it should be a hash 
of the sessionID.]

But I still think all the above is hard enough that some sites will want 
to take the improved caching possibilities of having a script key which 
is not unique to each request, rather than the increase in security from 
having a new one every time. Security is trade-offs. Paypal may rotate 
their script keys for every request; a standard web framework may 
default to a a per-user approach.

Gerv
Received on Friday, 28 January 2011 10:49:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 28 January 2011 10:49:25 GMT