W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2008

[XHR] security issue with spec's "same-origin" and the Document pointer

From: Hallvord R. M. Steen <hallvord@opera.com>
Date: Fri, 21 Nov 2008 17:28:34 +0100
To: public-webapps@w3.org
Message-ID: <op.uky9dwc7a3v5gv@hr-opera.oslo.opera.com>

http://www.w3.org/TR/XMLHttpRequest/#document-pointer says

> When the XMLHttpRequest() constructor is invoked a persistent pointer to  
> the
> associated Document object is stored on the newly created object. This  
> is the
> Document pointer. The associated Document object is the one returned by  
> the
> document attribute from the object on which the XMLHttpRequest()  
> constructor
> was invoked (a Window object). The pointer can become "null" if the  
> object is
> destroyed.

http://www.w3.org/TR/XMLHttpRequest/#open , point 11 says

> If stored url is not of the same-origin as the origin of the Document  
> pointerthe user agent should raise a SECURITY_ERR exception and  
> terminate these steps.

When the XMLHttpRequest() constructor is *invoked*, the window.document  
property might point to a document from a different origin. For example,  
given a document with an iframe from the same origin and a script that does

var xhrConstructor = iframe.contentWindow.XMLHttpRequest;
var xhr = new xhrConstructor();

When the constructor is invoked here, the associated document of its  
associated window object is not safe to do same-origin comparisons  
against. I've tested this in the main 4 engines, and they all protect  
against this exploit but as far as I can see someone implementing the spec  
as it's written would end up vulnerable.

(I tested this scenario with to-same-origin and to-different-origin  
redirects - i.e. not quite what the sample code above does but it should  
be equivalent. IE 8 throws on invoking the constructor if the document has  
changed - even if the new document is from the same origin. Firefox, Opera  
and Safari allow requests if the new document is same-origin but not if  
it's from a different origin. Spec-wise, requiring what IE does seems  
safer - perhaps what happens is that the variable refers to the actual  
window.XMLHttpRequest object and that object is destroyed by navigation.  
Keeping a pointer to an "associated original window location" with a  
random variable that happens to point to an XHR constructor would be very  
non-ECMAScript-y, at least according to my gut feeling. Given that I don't  
know how one could spec what the other browsers do..).

Hallvord R. M. Steen
Core JavaScript tester, Opera Software
Opera - simply the best Internet experience
Received on Friday, 21 November 2008 16:29:10 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:12 UTC