Re: [cors] Review

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

Developers how care about CSRF will have to worry about CSRF.  Nothing
we do with CORS will change that.

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

The site could do this if it knew which zip I cared about, but that's
the widget's job to remember that.

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

This is a dangerous road to walk.  It leads to introducing security
vulnerabilities in sites that we don't happen to know about.

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

Why do you assume my router has a private IP address?  It seems
fragile and magical to hang our hat on that for security.

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

I'm not sure I agree with this.  We shouldn't introduce
vulnerabilities into sites.  You argument appears to come down to
this:

1) We can't remove all the credentials from HTTP requests.
2) The credentials we can't remove don't matter because they aren't widely used.
3) Without examples of sites we're making vulnerable, we should assume
they don't exist / aren't important.

That doesn't seem like a sound approach to security.

Adam

Received on Monday, 22 June 2009 21:50:09 UTC