W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: XHR without user credentials

From: Adam Barth <w3c@adambarth.com>
Date: Sat, 13 Jun 2009 16:20:06 -0700
Message-ID: <7789133a0906131620pca8c4f1i1e15bf34af5b9277@mail.gmail.com>
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 3:49 PM, Tyler Close<tyler.close@gmail.com> wrote:
> On Sat, Jun 13, 2009 at 2:45 PM, Adam Barth<w3c@adambarth.com> wrote:
>> 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?

Here's what I said:

On Fri, Jun 12, 2009 at 10:36 PM, Adam Barth<w3c@adambarth.com> wrote:
> 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.

That appears to be overly strong.  I would change the last sentence to
say "Now, an attacker might be able to mount a CSRF attack against the

> 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.

That's unclear.  Here's what the spec says:

"The Access-Control-Allow-Origin header indicates which origin a
resource it is specified for can be shared with."

This tells me Access-Control-Allow-Origin is only about the
confidentiality of the resource.  We're interested in the integrity of
the resource (e.g., how the server might change state in response to
the request).

>> 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?

We must be contemplating a world where Origin is used as a credential,
otherwise you wouldn't be interested in removing it from requests.

>> 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.

And there might be reasons for them to make use of the 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.

It's hard for me to comment on this point without examples.

> We're accomplishing a few things here: studying the GuestXHR proposal,
> in response to your claims of vulnerabilities;

 I was simply pointing out that the GuestXHR proposal violated the
draft-abarth-origin proposal and the cost of being compatible with
that proposal was zero.  You have still not addressed this point.

Received on Saturday, 13 June 2009 23:20:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:54 UTC