Re: [cors] Review

On Mon, Jun 22, 2009 at 2:01 PM, Adam Barth<w3c@adambarth.com> wrote:
> 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.

Is your argument that CSRF is not an issue when you don't care about
CSRF? If so, I'll concede that point. ;) I think it would be good to
provide a cross-site request API that doesn't lead developers into
CSRF vulnerabilities, so that when then should care about it, they
haven't been lead astray.

As for simplicity of development, it seems just as easy for the widget
to remember the zip code and explicitly put it in the request URI,
perhaps as a query string argument. Many of the popular AJAX APIs I've
seen use this approach: arguments are sent in the URI, not in cookies.
I suspect they're doing it this way for the simplicity.

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

They might, but do they, and exactly how? Can we protect them without
requiring pre-flight requests and other additional complexity?

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

My proposal defends your home router by prohibiting requests to
servers with a private IP address. See:

http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1011.html

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

We're looking for the how and for what. We would like to accommodate
these resources without the restrictions of CORS. I don't think we
should take on the complexity and limitations of CORS, for an
unexamined hypothetical.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Received on Monday, 22 June 2009 21:26:59 UTC