- From: Tyler Close <tyler.close@gmail.com>
- Date: Sat, 13 Jun 2009 15:49:00 -0700
- To: Adam Barth <w3c@adambarth.com>
- Cc: "Mark S. Miller" <erights@google.com>, Anne van Kesteren <annevk@opera.com>, public-webapps <public-webapps@w3.org>
On Sat, Jun 13, 2009 at 2:45 PM, Adam Barth<w3c@adambarth.com> wrote: > On Sat, Jun 13, 2009 at 12:20 PM, Tyler Close<tyler.close@gmail.com> wrote: >> On Sat, Jun 13, 2009 at 10:23 AM, Adam Barth<w3c@adambarth.com> wrote: >>> For example, GuestXHR could be used to mount a login CSRF attack. >> >> Are you sure about that? Since the response won't carry the >> Access-Control-Allow-Origin header, the browser shouldn't set any >> cookies. I don't see how this attack works. > > Why do you assume the response won't carry the header > "Access-Control-Allow-Origin: *" ? That just means the content of the > response is public, which might well be true. Based on your initial assertion of attack, I didn't realize you were only talking about a login CSRF attack against a public resource (that somehow still requires a login) and has been marked safe for cross-origin access. Was this clear in your original statement? Even for this peculiar scenario, I think the problem is marking the resource safe for cross-origin access, when it is not. The problem is not the absence of the Origin header, as you have claimed. >>> Alternatively, if the server is using IP-based authenication, it could >>> be used to mount a CSRF attack (e.g., inflate the bill at the ACM >>> digital library, which uses IP-based authentication). >> >> Since such servers aren't currently looking for the Origin header, >> adding the header still won't protect them. > > Which is why we're discussing servers that act use the Origin header > as a CSRF defense, as described in draft-abarth-origin. Ignoring the non-existence of such servers? >> I'm also not sure they would block on the header if they did know about it. > > That's what the spec tells them to do. Uh huh. >> If they think >> IP-based authentication is good enough, are they really going to >> reject a request with "Origin: null"? > > IP-based authentication works great for the ACM digital library. I > don't know of any other authentication technology that better suits > their use case. I wouldn't assume they're clueless about security. I wasn't assuming they're clueless. I was thinking there might be good reasons for them to not make use of the Origin header. I was hoping you had done a thorough analysis that you could summarize or link to. Parts of this discussion have made me suspicious that not all your claims have been well thought out. > In any case, this whole discussion is a bit silly. You haven't > advanced any reason not to send Origin: null. We can continue this > discussion at a later time when GuestXHR is further along the > standardization process. We're accomplishing a few things here: studying the GuestXHR proposal, in response to your claims of vulnerabilities; and studying the utility of the Origin proposal. So far, this discussion has resulted in a demand by the WG for a fix to the Origin proposal, and some further clarity on the applicability and utility of the proposal. I suspect there's still more to be learned about the Origin proposal. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Received on Saturday, 13 June 2009 22:49:31 UTC