Re: [access-control] Access-Control-Allow-Origin: * and ascii-origin in IE8
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. - Bil
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. Regards, Maciej
Re: [access-control] Access-Control-Allow-Origin: * and ascii-origin in IE8
Maciej Stachowiak wrote on 1/16/2009 4:40 PM: 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. Ha, well, mea culpa. I was imaging it from the endpoint receiving an Origin header, then how it could be deceptive in the case of a redirect. If anything, I guess my scenario would be an argument against sending Origin for non-Access-Control GET requests. Thanks for keeping me straight. As for the hotlinking, I wasn't implying that Origin should (or can) be used to combat it. I saw it as an example of how the Origin header may have the side-effect of being used for other purposes simply by being present in the request. - Bil
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
Re: [access-control] Access-Control-Allow-Origin: * and ascii-origin in IE8
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
Re: [access-control] Access-Control-Allow-Origin: * and ascii-origin in IE8
Hixie said the position I expressed was a little unclear, so I'd like to clarify briefly: 1) FACT: The HTML5 version of the CSRF-defense header (currently called 'XXX-Origin' as a temporary measure) is specified not to be sent for GET requests. 1.a) FACT: As a result, it does not provide any protection against CSRF attacks on GET-based forms. 1.b) OPINION: I think this is an OK choice and I do not propose changing it. It strikes a decent balance between security and privacy. 2) FACT: Hyperlinks or GET-based forms (which are commonly submitted cross-site) cannot redirect to POST-based forms. 2.a) OPINION: Specially marking Origin in the case of redirects is not necessary to secure a site's off-site links and GET-based forms against CSRF attacks on POST-based forms. 3) FACT: Cross-site form POSTs to untrusted sites are quite rare; and furthermore a man-in-the middle attacker redirecting such a request cannot change the body of the submission. 3.a) OPINION: Defending against CSRF in this rare case is not worth the cost of a second different Origin header, and can be done in any case by the site making such bodies readily distinguishable from its own form post bodies. 4) FACT: Sites vulnerable to XSS could be vulnerable to a man-in-the- middle CSRF as in point 3, but they are owned anyway. 4.a) OPINION: It's not worthwhile to defend XSS-vulnerable sites against CSRF, as no meaningful protection is provided. 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. Regards, Maciej
[access-control] Access-Control-Allow-Origin: * and ascii-origin in IE8
I wanted to let the WG members know that we have completed our support for Access-Control in IE8 for the Simple Cross-Site Access Request. We support the Access-Control-Allow-Origin: * wildcard as we did in Beta 2 but in the next public release of IE8, our Release Candidate, we have also added support for the string comparison to the ascii-origin. I want to thank the members of this group who gave us feedback about making this change. Making changes to our implementation now will be costly and I'd prefer if this part of the draft didn't have to change significantly. On the subject of renaming the Origin header, we'd prefer the option to keep it as is and have the name for CSRF changed in HTML 5 as Ian raised [1] if possible. Cheers, Adrian. [1] http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0060.html -- Adrian Bateman Program Manager - Internet Explorer - Microsoft Corporation Phone: +1 (425) 538 5111 E-mail: mailto:adria...@microsoft.com
Re: [access-control] Access-Control-Allow-Origin: * and ascii-origin in IE8
On Wed, 14 Jan 2009 19:53:42 +0100, Jonas Sicking jo...@sicking.cc wrote: What do other people think? If we really think they should be different (and at least Adam Barth suggests that might not be needed) I would really like to rename this header to make it consistent with the rest of the API. (Of course, the semantics would be identical to what they are now.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [access-control] Access-Control-Allow-Origin: * and ascii-origin in IE8
On Wed, 14 Jan 2009 20:36:12 +0100, Bil Corry b...@corry.biz wrote: Jonas Sicking wrote on 1/14/2009 12:53 PM: The problem I think is that the current name, 'Origin', is extremely generic and so it's likely to cause confusion once we get other headers containing origins. That said, I do understand that this is a very late change for you guys. Developers will code to what works, so as long as things work the same across browsers, with regards to this and the CSRF protection header, things should be mostly ok. What do other people think? I liked your suggestion that would marry the two: Jonas Sicking wrote on 1/12/2009 7:22 PM: That said, here is a solution that might work for both Access-Control and CSRF protection: Site A makes a request to site B, the UA adds the header Origin: A Site B redirects the request to site C, the UA adds the header Origin: A, B This would mean significant changes to the draft which would not work well for Microsoft. Renaming I would like to consider, changing the semantics drastically seems out of order at this point. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [access-control] Access-Control-Allow-Origin: * and ascii-origin in IE8
On Wed, Jan 14, 2009 at 11:45 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 14 Jan 2009 20:36:12 +0100, Bil Corry b...@corry.biz wrote: Jonas Sicking wrote on 1/14/2009 12:53 PM: The problem I think is that the current name, 'Origin', is extremely generic and so it's likely to cause confusion once we get other headers containing origins. That said, I do understand that this is a very late change for you guys. Developers will code to what works, so as long as things work the same across browsers, with regards to this and the CSRF protection header, things should be mostly ok. What do other people think? I liked your suggestion that would marry the two: Jonas Sicking wrote on 1/12/2009 7:22 PM: That said, here is a solution that might work for both Access-Control and CSRF protection: Site A makes a request to site B, the UA adds the header Origin: A Site B redirects the request to site C, the UA adds the header Origin: A, B This would mean significant changes to the draft which would not work well for Microsoft. Renaming I would like to consider, changing the semantics drastically seems out of order at this point. Yup, I agree. / Jonas
RE: [access-control] Access-Control-Allow-Origin: * and ascii-origin in IE8
On January 14, 2009 11:45 AM, Anne van Kesteren [mailto:ann...@opera.com] wrote: On Wed, 14 Jan 2009 20:36:12 +0100, Bil Corry b...@corry.biz wrote: Jonas Sicking wrote on 1/14/2009 12:53 PM: The problem I think is that the current name, 'Origin', is extremely generic and so it's likely to cause confusion once we get other headers containing origins. What do other people think? I liked your suggestion that would marry the two: Jonas Sicking wrote on 1/12/2009 7:22 PM: That said, here is a solution that might work for both Access- Control and CSRF protection: Site A makes a request to site B, the UA adds the header Origin: A Site B redirects the request to site C, the UA adds the header Origin: A, B This would mean significant changes to the draft which would not work well for Microsoft. Renaming I would like to consider, changing the semantics drastically seems out of order at this point. Changing the semantics would unfortunately likely mean that IE8 would ship with behaviour that would be different to the spec. We probably won't be able to make that kind of change. I actually don't think that the generic name is a problem as long as the CSRF solution uses a different name for a different meaning. The value really is an Origin and could potentially be used for more than just participation in the Access Control negotiation. It could still be meaningful in other scenarios in future which would otherwise now have to define a new header with the same meaning. If the header name does change then we will cost out the work to make this change to see if we can do it. Clearly changing the strings used in the browser is a relatively constrained change but I'm concerned about the amount of churn in our test automation infrastructure that would be required and the risks involved. Cheers, Adrian.
Re: [access-control] Access-Control-Allow-Origin: * and ascii-origin in IE8
On Jan 14, 2009, at 3:45 PM, Bil Corry wrote: Adrian Bateman wrote on 1/14/2009 3:18 PM: I actually don't think that the generic name is a problem as long as the CSRF solution uses a different name for a different meaning. The value really is an Origin and could potentially be used for more than just participation in the Access Control negotiation. It could still be meaningful in other scenarios in future which would otherwise now have to define a new header with the same meaning. I'm thinking out loud here, making sure I have the distinction between the two correct: With Access Control, Origin represents the initial request, which survives through a redirect. So as Adrian points out, it really is an Origin. With CSRF mitigation, Origin represents the immediately-preceding request, which for obvious reasons does not survive through a redirect. That's why I liked the idea of just including the chain of requests within Origin, you can then easily find the one you want. But since that isn't on the table, I'm attracted to renaming the CSRF Origin to something like Request-Origin. Whatever name is chosen, it then has to be added to the XHR spec as a header that can not modified/created via XHR. Given this behavior, it sounds to me like the Access Control related header is more deserving of the term Origin, since it represents the true origin of the request. I am not sure what the other header could be called to make the difference clear. Perhaps Redirect-Origin? Why does the CSRF defense header need to change on redirect? Regards, Maciej
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. http://crypto.stanford.edu/websec/specs/origin-header/ - 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. Regards, Maciej
