On Sun, 23 Nov 2008 22:32:02 +0100, Anne van Kesteren <[EMAIL PROTECTED]>
wrote:
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.
Why would the SECURITY_ERR exception not be thrown during the open()
method invocation as the specification requires?
Because when you call "new xhrConstructor()" the document pointer is
initialized *but at that point the document of the associated window
originates from attackee.example.com*.
Once you navigate the original Document is either destroyed or stays
around. However, it does not suddenly change into the Document of
another domain.
The point is that there *is* no document pointer until you call the
constructur - per the spec. And once that script calls the constructor and
the document pointer is created, the associated window has a different
document in it from a different origin. Hence the document pointer will
reference a document from a different origin than the script itself has,
and same-origin comparisons will pass when they should fail and vice versa.
If you still don't get it please read carefully because I don't know how
to explain it clearer than that :-p. Besides, I'm on vacation and will try
not to read E-mail ;)
--
Hallvord R. M. Steen
Core JavaScript tester, Opera Software
http://www.opera.com/
Opera - simply the best Internet experience
