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  
domain.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
Received on Sunday, 23 November 2008 21:32:45 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:28 GMT