The HTML 5 spec lays out the details for cross domain XHR. I’ve written about my dislike of the idea before (details of the access control spec can be found here; I like how they justify sending cookies via XHR because you send them with img requests. In other news, if you don’t need seatbelts on a motorcycle you don’t need them in a car because obviously they are exactly the same scenarios), specifically why passing cookies is a VERY BAD IDEA.

Today I am going to focus on the other side of things, not from the user’s perspective, but from the perspective of the third party host (3PH) that is now getting requests from the client. To allow a 3PH to make discriminating decisions the source origin of the request (not the client, but the originator host of the call, though because of POORLY WRITTEN AND LAID OUT SPECS I am unable to tell if a page loaded from somesite.com that loads a script from someothersite.com that makes the actual call would consider the source origin somesite or someothersite) is passed in the origin field of the request. This origin is based off of what the browser thinks is the origin, rather than the actual origin. Thus any tricks that would fool a browser into loading a malicious site under a safe url would also fool the 3PH. ARP spoofing (for various reasons I have been exposed to techniques to do this with Ettercap recently, and it makes this very easy), DNS poisoning, and other similar techniques could be employed quite effectively for even bigger payout (not only do you fool the user into disclosing credentials or other sensitive information for website A, you also get all sorts of sensitive information from 3PH via cross domain XHR).

To some extent they could mitigate this. The origin field could also contain the DNS and ARP information the client *thinks* belongs to the origin, and this could be independently verified by the 3PH. Granted, the spec doesn’t call for this, but it *could* be made safer. From the perspective of the 3PH though, even if you can verify that the origin really is the website you expect, there is NO assurance of the integrity of the website. How many sites have XSS or SQL injection? Are you confident that the origin does not? Security is only as strong as the weakest link, and by exposing your customer’s data to the origin through cross domain XHR, that weakest link may be the origin rather than your.

Any data exposed through cross domain XHR should be considered public as soon as it is exposed, regardless of the origin field, since you can’t really verify who really is reading it. Because of that, does it really matter what the origin field says? I think the best bet for cross domain XHR is to explicitly let each user opt in to making certain information available to the world through scripting, with no assurance that only “trusted parties” would be able to script against it (since you can’t make that assurance in good conscience). All data exposed this way may be user specific in nature, but should be of trivial value since it will be effectively unprotected. 3PH should also recognize that this is the easy way of exposing data, but by no means the safe or right way. This whole proposal was introduced by scripters that wanted one more snazzy feature regardless of security implication, because having a federated webservice strategy smacks of effort.

Oh, one last thing to consider 3PH, you need to kill that timeout you put on your session to get all of this to work, which is considered BAD PRACTICE. You open yourself up to all sorts of concerns if your sessions don’t time out, and just because Google follows that bad practice doesn’t mean you should. It is good to make users log in periodically.

~ Joshbw