W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 15 Jan 2009 19:40:55 -0800
Cc: Adrian Bateman <adrianba@microsoft.com>, Anne van Kesteren <annevk@opera.com>, Jonas Sicking <jonas@sicking.cc>, "public-webapps@w3.org" <public-webapps@w3.org>
Message-id: <DFE806BA-60A7-4812-9C6C-035406B9D607@apple.com>
To: Bil Corry <bil@corry.biz>

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.

Received on Friday, 16 January 2009 03:41:41 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:13 UTC