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
