Re: CORS Background slides

On Nov 4, 2009, at 9:01 PM, Jonas Sicking wrote:

> On Wed, Nov 4, 2009 at 5:57 PM, Maciej Stachowiak <mjs@apple.com>  
> wrote:
>> [1] To recap the DBAD discipline:
>>
>> Either:
>> A) Never make a request to a site on behalf of a different site; OR
>> B) Guarantee that all requests you make on behalf of a third-party  
>> site are
>> syntactically different from any request you make on your own behalf.
>>
>> In this discipline, "on behalf of" does not necessary imply that the
>> third-party site initiated the deputizing interaction; it may include
>> requesting information from a third-party site and then  
>> constructing a
>> request to a different site based on it without proper checking.  
>> (In general
>> proper checking may not be possible, but making third-party  
>> requests look
>> different can always be provided for by the protocol.)
>
> One simple way of allowing websites to do B would be to provide a
> GuestXHR object (I'm not exited about the name, but I won't suggest
> alternatives right now in order to avoid bikeshed discussions). I.e.
> if browsers provided a GuestXHR object, then sites could use that
> whenever they acted as a deputy. This would be my recommendation at
> this stage.
>
> This would also allow sites to choose between two security models, one
> based on principal information being added to the request, one based
> on secret tokens passed around.
>
> The requirements on the GuestXHR object would be:
> 1. Never include any information identifying either the user or the
> site making the request. I.e. no Origin, referrer, cookies, http-auth,
> client side certs, etc.
> 2. If the request is cross site, the target site has to opt in to
> allowing the result to be returned to the requester. This is in order
> to protect data behind firewalls.

I do think that a way to do an anonymous XHR is justified (I think  
AnonXMLHttpRequest would be a better name than GuestXMLHttpRequest).  
At the very least it is useful for a page hosting untrusted guest code  
that's been processed with a tool like Caja.

It's not required to do (B), and I'm not sure it's always the best way  
to do (B). It depends on the particulars of the situation. In some  
cases, you can simply name the commands for cross-domain access  
differently and then the Origin and Cookie are useful additional  
information to help provide defense in depth. This email includes a  
worked example: <http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0491.html 
 >. I believe in the example I gave, Origin+Cookie provide defense in  
depth because they simplify the process of obtaining one-time secret  
tokens, and mitigate the risk inherent to maintaining a long-term  
shared secret.

I don't think we need to debate whether to provide anonymous cross- 
site XHR (with sufficient defenses). I think the question is whether  
we should also abandon CORS and remove the existing implementations. I  
continue to think the answer to that latter question is "no".

Regards,
Maciej

Received on Thursday, 5 November 2009 05:41:24 UTC