On Wed, 2010-03-31 at 18:48 +0300, Eddy Nigg wrote: > On 03/31/2010 04:45 PM, Kai Engert: > > ====== snip quote begin ====== > > E.g., the attacker would send: > > > > GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1 > > X-Ignore-This: > > > > And the server uses the victim's account to send a pizza to the attacker. > > ======= snip quote end ======= > > This attack is highly theoretical beyond believe, specially the > X-Ignore-This-and-That headers. Is has no real and practical value > whatsoever.
There's nothing theoretical about ignoring unrecognized headers. > Here some interesting observations and opinion by others: > http://blogs.technet.com/srd/archive/2010/02/09/details-on-the-new-tls-advisory.aspx To condense the point made there: The attacker cannot inject POST parameters if he wants the client's Cookie header to be recognized as such. Servers that perform unsafe actions in response to unauthenticated GET requests are already vulnerable to browser-based XSRF. Thus, the only configurations vulnerable specifically to the renegotiation attack are those that have attackable parameters in the URL and are authenticated with the Referer or a token in POST data. Such configurations are uncommon, but they are not intrinsically unreasonable. Sites that put parameters in URI path components are likely to keep the same approach for their write requests. For example, but for Launchpad's refusal of client-initiated renegotiation, it would be vulnerable to a request to subscribe to one bug being changed to a different bug. (Note that they use the Referer, not a token for XSRF protection.) I'll admit this is not a very serious compromise, but it illustrates the point. It's totally unfair to expect web developers to have anticipated that this configuration might be a bad idea. Hence I think the level of concern about the attack is merited. -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
