On Sat, Jun 13, 2009 at 12:20 PM, Tyler Close<[email protected]> wrote: > On Sat, Jun 13, 2009 at 10:23 AM, Adam Barth<[email protected]> 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
