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

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

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.


Received on Thursday, 15 January 2009 06:48:41 UTC