W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: CORS Background slides

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 04 Nov 2009 20:53:42 -0800
Cc: WebApps WG <public-webapps@w3.org>
Message-id: <C0DC7158-74CC-4052-987E-1ECD44FDEFA7@apple.com>
To: Tyler Close <tyler.close@gmail.com>

On Nov 4, 2009, at 8:20 PM, Tyler Close wrote:

> Hi Maciej,
> Thanks for the many responses. I'll try to get to them all shortly,
> but I'd like to start by clarifying one point...

Sorry that there were so many - I thought of a number of additional  
points after sending my initial response. I also discussed your  
protocol and my comments with Adam Barth.

> On Wed, Nov 4, 2009 at 5:57 PM, Maciej Stachowiak <mjs@apple.com>  
> wrote:
>> On Nov 4, 2009, at 4:51 PM, Tyler Close wrote:
>> 2) I strongly disagree with the final sentence on that page: "As  
>> discussed
>> at Tuesday's TPAC meeting, Maciej's solution is vulnerable to a  
>> CSRF-like
>> attack by Server A on Server B if the "add event" URL provided by  
>> Server A
>> actually refers to a resource on Server B." The scenario I posted  
>> does *not*
>> involve Server A providing a URL to Server B and does not have a
>> vulnerability.
> How does Server B get the URL if not from Server A? The URL is
> supposed to refer to a resource on Server A, so only Server A can
> provide its value. Somehow, Server B must get the URL from Server A.
> That communication, however it is done, is vulnerable to a CSRF-like
> attack.

1) Server B can have a list of URLs for the most popular servers that  
provide Server-A-like services (this is what happens most commonly in  
practice). In this case the URL is provided by the operator of Server B.

2) Server B can allow the user to input an additional URL that's not  
on its list. This can be as simple as accepting a domain name and  
having a convention for where on that host the service lives. In this  
case, the URL is provided by the user (possibly in abbreviated form).  
Server B could in addition sanity check this URL to verify that it  
doesn't refer to itself.

I don't believe these methods are vulnerable to a CSRF-like attack.  
Certainly not method 1. Method 2 could be if the user has to copy a  
full URL from Server A and does not take note of the host in this URL.  
But even that could be avoided if the user only types a hostname.

Received on Thursday, 5 November 2009 04:54:23 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:20 UTC