- From: Adam Barth <w3c@adambarth.com>
- Date: Sat, 13 Jun 2009 14:45:32 -0700
- To: Tyler Close <tyler.close@gmail.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 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. >> 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. > 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. > 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. 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. Adam
Received on Saturday, 13 June 2009 21:46:29 UTC