Re: [cors] Review

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

Ah ha! See that's not true. CSRF requires ambient authority
(credentials automatically added to a request). Even login CSRF
requires the ability to set ambient state (the login cookie). If we
provide an API without ambient authority, we eliminate CSRF. That's
the big prize here.

>> 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 was unable to parse this comment.

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

That's a good general principle. But every principle has its price and
in this case, I suspect the actual vulnerability can be made trivial,
while the costs of CORS are large.

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

Because it does?

>  It seems fragile and magical to hang our hat on that for security.

No more fragile and magical than a home router hanging its hat on
connectivity 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.

That's not an accurate portrayal of my argument. Try again.

--Tyler

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

Received on Monday, 22 June 2009 22:10:20 UTC