Cross-domain XHR will destroy the internet


Ok, maybe “destroy the internet” is a little harsh. But let’s take a look the impact that implementation of the current W3C working draft for cross domain access would have on browser security. Some people might argue that there’s no more risk from cross-domain XHR than there is from cross-domain Flash or Silverlight, but they would be wrong, for two reasons.

First is a simple matter of increased attack surface. Flash and Silverlight support only the HTTP methods GET and POST. But attacks can be made with methods other than these, and XHR supports any arbitrary method. Attackers could send TRACE requests to probe for cross-site tracing vulnerabilities that defeat HttpOnly cookie protections. Or they could send PUT or DELETE requests to attack WebDAV sites or RESTful web services.

In the second place, cross-domain XHR would increase the potential damage of a successful XSS. Arguably the worst, most damaging types of XSS attacks are the self-propagating XSS web worms. At Microsoft, any “wormable” vulnerability automatically gets our highest security bulletin rating. But for the most part, XSS web worms are confined to a single domain because of the constraints of the same origin policy. Now single-domain worms are bad enough – just ask MySpace – but cross-domain XHR would allow worms to spread across multiple domains, potentially infecting any site with both a stored XSS vulnerability and a permissive cross-domain policy.

Billy Hoffman and John Terrill presented some excellent material on cross-domain web worms at Black Hat last year, but their approach relied on using blind GETs and POSTs to propagate across domains. An attack based on cross-domain XHR would not be limited in this way; the worm could read responses from the targets and vary its attacks accordingly. It could even include logic to defeat multiple-step submission processes like CAPTCHA checks.

I know the cross-domain genie is out of the bottle now with pretty much every browser and RIA framework providing its own cross-domain request mechanism, but let’s try to kill this proposal and nip a future security nightmare in the bud.

As an alternative to the W3C XHR proposal, I like IE8’s XDomainRequest (XDR). XDR only allows GET and POST requests, which is a good reduction in attack surface, but even better is the fact that XDR won’t ever send cookies. This is going to make exploitation of XSRF vulnerabilities via XDR impossible in most cases. Theoretically the web worm issue is still possible, but an attacker would have to find sites that:

a.       Have persistent XSS vulnerabilities,

b.      Have permissive cross-domain policies, and

c.       Don’t use any kind of authentication or session cookies.

Even assuming that any sites like this actually exist, the no-cookies restriction definitely limits the effectiveness of XDR as an attack vector compared to the W3C proposed standard.

Comments (5)

  1.…internet.aspx Ein interessanter Text über die Gefahren von XHR. Ich persönlich stimme diesen nicht zu, da ich der Meinung bin, dass die Vorteile dieser Technologie überwiegen und damit ein Abfragen fremde

  2. kuza55 says:

    I think you’re completely overblowing this issue.

    The cross-domain XHR you mention is opt-in and better than Flash’s system since it does a GET request before doing any non-GET requests to check that they are allowed; even POST, there may be bugs if people accidentally implement something which forgets to check what type of request the user wants to make (e.g. allowing trace requests when they only wanted to allow post by forgetting to check the request type). And there are some issues with the need to restrict headers a bit more than is currently happening, but that’s about it.

    If you can come up with an attack scenario that cross-domain XHR would help that doesn’t involve tampering with headers, I’ll be very surprised.

    So while IE8’s XDomainRequest is nice since it doesn’t seem to affect objects such as cookie (maybe the cache too?), I don’t think the cookie issue is much of a benefit.

    In fact I would say we need to give content developers the right tools rather than trying to lock things down, because developers are going to work around what we want in the end, so it’s better to give them a secure way to do so. Maybe the people who implemented this found that 99% of mashup authors don’t need cookies cross-domain, in which case I’d be kind of surprised, but would see the reasoning behind this choice, otherwise this seems like just another proprietary idea that will hopefully die.

  3. bryansul says:

    kuza55: It’s not header tampering I’m concerned about as much as sites actually setting their Access-Control headers to overly permissive settings like "allow <>" or "allow <.com>". This is exactly what happened (and still does happen) with Flash crossdomain.xml files: developers find that it’s easiest just to set <allow-access-from domain="*"/>.

    Now the same thing can happen with XDR – the application can be written to always respond with a XDomainRequestAllowed:1 header – but the no-cookies nature of XDR helps to keep apps like these from being exploited by XSRF attacks. This is the key difference between XDR and the W3C proposal.

  4. kuza55 says:

    So essentially we’re going to hold people’s hands so that they can’t screw this up too badly; I guess that makes sense, kind of. I’m still interested in whether you asked web developers whether they would prefer XDR over the W3C proposal though, because if people want to share data between sites on a specific user, rather than just generic site data this’ll lead to people trying to subvert the cross-domain policy and probably making mistakes.

    So the question here is; is it really worth protecting people who won’t help themselves (and probably have a huge amount of XSS holes in their sites anyway) in exchange for not giving people who will protect themselves something useful? I’m not entirely convinced (on the other hand if you’ve got some data to show that web developers don’t want/need cookies to be sent then this definitely makes sense)

  5. REST and XSRF, Part One Hi everyone. In case you missed my talk at Black Hat , “REST for the Wicked”,