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

On Jan 16, 2009, at 9:02 AM, Bil Corry wrote:

> Maciej Stachowiak wrote on 1/15/2009 10:40 PM:
>> CONCLUSION: We should use a single Origin header with the name and
>> semantics of the Access-Control Origin header for both its
>> Access-Control purpose and for redirect defense. The differences in  
>> the
>> HTML5 version are not worth the cost of a very similar but subtly
>> different header. And if we ever find the attack in case 3 is more  
>> than
>> theoretical, we could add a 'Redirected-Via' header to provide full
>> information.
> Thank you for the extended explanation.  I do now see your point,  
> and agree it's probably the best course of action.  It will,  
> however, still leave open some odd side-effects from not identifying  
> the redirect source, but maybe they're unlikely to be common.  For  
> example, Site A allows the users to specify a remote location for  
> their avatar image; the user points to Site B, which in turn then  
> redirects to Site C.  Site C doesn't like its images being used  
> remotely and checks the Origin header and identifies Site A.  Site C  
> then complains to Site A about the hotlinking; Site A checks it's  
> avatar URLs and doesn't find Site C listed.  So now you have Site C  
> being hotlinked from Site A, but Site A has no way to discover how  
> it's happening other than to crawl all outbound URLs.

Such hotlinking is probably using a GET request, so no Origin header  
would be sent. I believe it is also outside the scope of the CSRF  
protection and cross-origin data sharing goals of Origin. The Referer  
header is still usable for hotlinking prevention in this scenario, the  
only downside being that it is apparently often filtered by sites or  
users for privacy reasons.


Received on Friday, 16 January 2009 22:41:20 UTC