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

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;
iframe.src='http://attackee.example.com/';
.
.
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
http://www.opera.com/
Opera - simply the best Internet experience

Received on Friday, 21 November 2008 16:29:10 UTC