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

• Anonymous
  April 04, 2008
  http://blogs.msdn.com/bryansul/...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
• Anonymous
  April 07, 2008
  The comment has been removed
• Anonymous
  April 14, 2008
  The comment has been removed
• Anonymous
  April 14, 2008
  The comment has been removed
• Anonymous
  August 15, 2008
  REST and XSRF, Part One Hi everyone. In case you missed my talk at Black Hat , “REST for the Wicked”,