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*
