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
