W3C home > Mailing lists > Public > public-webapi@w3.org > May 2008

Re: IE Team's Proposal for Cross Site Requests

From: Arun Ranganathan <@mozilla.com>
Date: Fri, 23 May 2008 17:05:13 -0700
To: Ian Hickson <ian@hixie.ch>, Chris Wilson <Chris.Wilson@microsoft.com>
CC: "public-webapi@w3.org" <public-webapi@w3.org>, "public-appformats@w3.org" <public-appformats@w3.org>
Message-Id: <20080524000514.1DB7C8240E2@dm-mail02.mozilla.org>

On Thu, 22 May 2008, Chris Wilson wrote:
>> In both XHR2+AC and Flash's policy file approach, the "allow 
>> credentials" and the actual access to data occur in separate network 
>> transactions, and likely (but not guaranteed, of course) separate 
>> network connections.  
<snip />

And Ian responded:
> In both XDR _and_ XHR/AC, the response is checked for the correct magic 
> bits before any data is returned to the client. The security check is 
> still done on the response, the data from the original OPTIONS request 
> isn't used to determine whether or not to return data to the client.
>
>   
<snip />

I think that if the uber point that Chris makes with respect to Access 
Control is that we should try and economize on header exchanges (and 
thus the possibility of different connections), I think that's a valid 
point. 

But architecturally, I'm not sure it's a *bad* thing that we engage in 
two-point request negotiations in the situations that we do this  -- 
asking first for permission, and then sending the request.  Seems like 
this is a sticky point with you w.r.t. Access Control in general, and 
this is a hard point to evolve in a way that addresses your concerns.  
On the one hand, we're engaging in a layer of diligence to ensure that 
both parties agree on the data that is to be exchanged (credentialed?) 
and methods to use (OPTIONS: and Allow:), and on the other hand we have 
to weigh the scenario that you cite that in a multipart request-response 
negotiation, the connection can be hijacked. 

I still think that the vector of attacks you cite are open, difficult 
problems that exist outside the scope of AC.  I mean, standard requests 
for HTML documents often are multipart requests today on the web, and 
thus are prone to similar attack vectors (in your example, replace the 
notion of XS-XHR with requests for pages and add "attacker can insert 
themselves into the stream...").   But thinking about economizing on 
headers or connections in general is a good thing; I'm just not sure I 
have a straw person yet as to where this can be done (right now I'm 
grasping at straws like Keep-Alive :-) ).

Thank you for sharing your security concern here.  I worry that this 
will become a bit of an intractable debate about direction, but the 
concerns are definitely worth thinking about, and I'm glad we're airing 
them.

In the simplest case of GET, XHR2+AC and XDR resemble each other closely 
enough.  Our divergence stems from wanting to evolve more capabilities, 
including methods and credentials.  For instance, do you think you might 
want to introduce more HTTP methods into the system?  Let's assume that 
you want to treat POST like XDR does.  For other methods, shouldn't 
there be a determination request?  Or do you think such things should 
not be allowed at all?

-- A*
Received on Saturday, 24 May 2008 00:05:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 24 May 2008 00:06:00 GMT