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

Re: XHR without user credentials

From: Tyler Close <tyler.close@gmail.com>
Date: Sat, 13 Jun 2009 15:49:00 -0700
Message-ID: <5691356f0906131549y2d01e957l3b3ce099cc2f2d67@mail.gmail.com>
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.


"Waterken News: Capability security on the Web"
Received on Saturday, 13 June 2009 22:49:31 UTC

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