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