- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 14 Jan 2009 22:47:59 -0800
- To: Bil Corry <bil@corry.biz>
- Cc: Adrian Bateman <adrianba@microsoft.com>, Anne van Kesteren <annevk@opera.com>, Jonas Sicking <jonas@sicking.cc>, "public-webapps@w3.org" <public-webapps@w3.org>
On Jan 14, 2009, at 5:32 PM, Bil Corry wrote: > > Maciej Stachowiak wrote on 1/14/2009 6:14 PM: >> Why does the CSRF defense header need to change on redirect? > > Because to the site on the far end, it would appear the request came > from somewhere it didn't, effectively hiding the real source of the > request. This probably explains it better: > > ----- > When an honest site initiates a request to a dishonest site (for > example because the user followed a hyperlink), the dishonest site > can redirect the request back to the honest site. If the redirected > request carries the same Origin header as the original request, the > request will implicate the honest site as generating the request. To > protect the honest site, the user agent replaces the Origin header > with null, so a conforming server will not modify state in response > to a redirect. > > http://crypto.stanford.edu/websec/specs/origin-header/ > ----- So one thing to keep in mind is that any POST-based form would not be vulnerable to this kind of attack unless the victim site actually submits a form to an untrusted site. There is no way for a GET request to be redirected to a POST, and it seems to me the practice of Site A submitting a form to untrusted site B is likely to be quite rare and easily avoidable. Furthermore, HTML5 specifies that the XXX-Origin (or whatever it might get renamed to) header should not be sent for GET requests, the only kind of request where it would plausibly help anything. Thus, the difference in behavior of the CSRF-prevention Origin does not do any good, and so we may as well use just one Origin header. Regards, Maciej
Received on Thursday, 15 January 2009 06:48:41 UTC