Re: [access-control] Access-Control-Allow-Origin: * and ascii-origin in IE8

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, 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.


> 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.


> 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.



- Bil

Received on Thursday, 15 January 2009 15:25:05 UTC