Re: XHR without user credentials

A few comments:

On Sat, Jun 13, 2009 at 5:39 AM, Tyler Close<tyler.close@gmail.com> wrote:
> On Fri, Jun 12, 2009 at 10:36 PM, Adam Barth<w3c@adambarth.com> wrote:
>>> Isn't your answer above only about client (user agent) behavior? I'd still
>>> like understand what the recommended/expected difference in server behavior
>>> should/might be depending of whether Origin is absent or null. Thanks.
>>
>> Suppose GuestXHR doesn't send an Origin header for any requests and a
>> server uses the algorithm in draft-abarth-origin to mitigate CSRF
>> attacks.  Now, an attacker can mount a CSRF attack against the server.
>
> Could you provide a bit more detail here? I don't understand how an
> attacker could mount a CSRF attack using GuestXHR, if there are no
> user credentials in a GuestXHR request.

User A is sitting inside a corporate firewall. Server B is also
located inside this firewall. Server C is located on the public
internet, outside the firewall. The firewall prevents server C from
making HTTP connections with server B, however both A and B can make
HTTP connections with C.

(This is a very common setup on corporate intranets)

Server B uses Caja or a similar technology to pull in a 3rd party JS
library, D, from server C, while still preventing D from using
XMLHttpRequest.

(This I believe is less common since Caja and similar technologies has
not yet been widely deployed. But as I understand it, this is the
environment where GuestXMLHttpRequest is intended to work. Please let
me know if this is not correct)

B now decides to allow D to create network connections using
GuestXMLHttpRequest.

Because of this, server C now gains the ability to make HTTP
connections to B, something that it was previously not able to do.
Meanwhile, B has previously not had to rely on any authentication
mechanisms since only users inside the corporate firewall was able to
connect to it. For example it could be supporting REST and allow users
to upload HTML files using PUT commands which are immediately hosted
and served from B.

This is similar to the IP authentication that Adam mentioned, but here
the server simply relies on that anyone that can connect to it, is a
trusted party. At least beyond the standard set of cross-site
connections that all browsers can do today (GET/HEAD/POST).

I believe this is a quite common thing to rely on. After all,
corporations wouldn't bother hosting things inside corporate firewalls
and demand that users had to use VPN in order to get access, if they
weren't relying on the firewalls for protection.

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.

In mozillas implementation of "credential less channels", used to
implement credential-less CORS requests, even if the remote server
sets a cookie and sends "Access-Control-Allow-Origin: *", we won't
store that cookie. The request is essentially completely separated
from the rest of the user session, no cookies or other auth tokens are
read or saved, and no cache entries are read or saved.

I'm pretty sure the CORS spec requires this behavior.

If I recall correctly, we don't even reuse a keep-alive channel that
has been used to send credentials. Though the CORS spec does not
demand this.

So I don't think GuestXMLHttpRequest can be used to mount login CSRF attacks.

On Sat, Jun 13, 2009 at 3:49 PM, Tyler Close<tyler.close@gmail.com> wrote:
>> 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?

Of course. Any new spec is not going to have any users until there are
implementations. And very few users until there are many
implementations. Likewise, GuestXMLHttpRequest doesn't have users
right now, yet we are discussing deploying it, right?

/ Jonas

Received on Sunday, 14 June 2009 09:17:56 UTC