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
updated Widgets Signature and properties
Begin forwarded message: From: Frederick Hirsch frederick.hir...@nokia.com Date: January 16, 2009 12:04:43 PM EST To: XMLSec WG Public List public-xml...@w3.org Cc: Frederick Hirsch frederick.hir...@nokia.com Subject: updated Widgets Signature and properties I've updated the Widgets Signature [1] and Signature Properties [2] drafts based on feedback during the XML Security WG F2F. Thank you very much for the review and comment. Please indicate any additional corrections on the public list - in particular are the processing rules in the signature properties draft clear and appropriate? Thanks regards, Frederick Frederick Hirsch Nokia [1] http://dev.w3.org/2006/waf/widgets-digsig/ [2] http://www.w3.org/2008/xmlsec/Drafts/xmldsig-properties/Overview.html
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
