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

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

From: Anne van Kesteren <annevk@opera.com>
Date: Sun, 23 Nov 2008 22:32:02 +0100
To: "Hallvord R. M. Steen" <hallvord@opera.com>, public-webapps@w3.org
Message-ID: <op.uk3crog264w2qv@annevk-t60.oslo.opera.com>

On Sun, 23 Nov 2008 18:13:41 +0100, Hallvord R. M. Steen  
<hallvord@opera.com> wrote:
> On Fri, 21 Nov 2008 21:14:59 +0100, Anne van Kesteren <annevk@opera.com>  
> 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*. If the script goes on to request  
> content from this domain, the same-origin comparison against the  
> document pointer would pass when it should in fact fail because the  
> script itself is from a different origin.

Once you navigate the original Document is either destroyed or stays  
around. However, it does not suddenly change into the Document of another  

Anne van Kesteren
Received on Sunday, 23 November 2008 21:32:45 UTC

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