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

Re: [cors] Review

From: Adam Barth <w3c@adambarth.com>
Date: Mon, 22 Jun 2009 14:01:41 -0700
Message-ID: <7789133a0906221401s31abe460s2af4724695977be5@mail.gmail.com>
To: Tyler Close <tyler.close@gmail.com>
Cc: Ian Hickson <ian@hixie.ch>, Anne van Kesteren <annevk@opera.com>, Mark Nottingham <mnot@mnot.net>, public-webapps@w3.org
On Mon, Jun 22, 2009 at 1:16 PM, Tyler Close<tyler.close@gmail.com> wrote:
> On Mon, Jun 22, 2009 at 12:33 PM, Adam Barth<w3c@adambarth.com> wrote:
>> 1) We can't strip all the credential information from cross-origin requests.
>> 2) There's a large amount of value is supporting all the normal
>> credentials associated with HTTP requests.
>> 3) Given (1), we have to deal with the credential issue.  Given (2),
>> we get a large benefit from from supporting all kinds of credentials.
>> 4) Given (3), some folks have made a judgement call that value of
>> supporting credentials is worth the complexity.
> Perhaps that is the reasoning of the authors, I don't know. Ian
> Hickson's email seemed to suggest that IP-based authentication was the
> primary reason to not consider the simpler approach I outlined. In
> either case, we know that the value of (2) is illusory since CSRF
> vulnerabilities prevent its use (unless all the sites in the scenario
> are trusted).

Why is this the case?  Suppose I have a weather widget that wants to
remember for which ZIP codes I want to see the weather.  It seems
easiest to store the zip code information in a cookie and fetch the
weather report via CORS.  Alternatively, the weather widget might want
to let me pick a personalized theme for the widget and store the
choice on its server (via a POST request).  Somehow, I don't think the
weather widget cares about CSRF.

> For (1), I think it's worth investigating exactly what
> sites rely on. For example, if sites are only relying on IP-based
> authentication to ensure a response is delivered to that IP address,
> then we're in good shape, since we can easily implement this by
> checking for the absence of a cross-domain enabled header.

I don't see why IP authenticated services would only care about
confidentiality.  They might well care about integrity also.  For
example, suppose my home router exposed a RESTful interface for
configuring port forwarding.  On reasonable design is to accept PUT
requests to add new forwarding configuration.  If you open the world
to "credential-less" GuestXHR, then any random web site can add port
forwarding configurations to my router by hijacking my connectivity

> So I just did some poking around on the ACM digital library site (I
> believe my company also has a site license). Only GET requests are
> made when fetching a paper, so this use-case is not relevant to this
> discussion. CORS also allows GET requests to be sent without
> restriction.

Perhaps you have an all-you-can-eat subscription?  In any case, I
don't see why they wouldn't use POST requests for other features.

Received on Monday, 22 June 2009 21:02:33 UTC

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