On Jan 15, 2009, at 7:24 AM, Bil Corry wrote:
Maciej Stachowiak wrote on 1/15/2009 12:47 AM:
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.
Using XSS, an attacker could change the target of a login form to a
MitM site,
If the site has an XSS vulnerability, then there is no need to stage a
CSRF attack using a man-in-the-middle server. The injected script
could perform the equivalent of the CSRF attack directly (for example
by altering form values and programatically submitting the form).
Thus, I do not believe it makes sense to defend against this scenario,
since by assumption the victim site is already owned.
then redirect back to the original target, hiding the attack from
the user. If we use Access Control Origin exclusively, then the
Origin would be the original log-in page, not the attacker's MitM
site (or NULL), so the attack would be invisible to the site too.
The same would be true just by exploiting the site directly via the
XSS vulnerability.
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.
I disagree with the implementation within HTML5; I think it should
be sent when the GET is going back to the same Origin, so a site can
confirm that the request came from itself. I have other ideas about
redirects, but that's another discussion.
Well, the current HTML5 spec doesn't behave that way, so I think it is
still the case that it provides practically no benefit. I don't think
a redirect-tracking Origin on GET requests would have much benefit
either, since in theory and by HTTP spec, GET-based forms should not
have dangerous side effects. I realize that this is not true for some
sites, but it would be easier for a thoughtful site to fix this by
using POST than to do so by checking Origin on the server side.
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.
The Origin header (as defined in Access Control) will always be the
page that made the initial request; redirects would be invisible.
That in itself effectively neuters the CSRF protections. The only
way to combine them isn't an option (per this list), so we now need
two headers to address the specific requirements of each.
The CSRF protections are only defeated in the GET case (where
currently the CSRF-protection header is specified not to be sent), and
in the case where the site has hostile content injected via XSS (in
which case as far as I can tell it is already owned). CSRF protection
remains effective in the non-XSS non-GET case, which it seems to me is
arguably the most important case for protection.
Regards,
Maciej
