W3C home > Mailing lists > Public > public-web-security@w3.org > December 2009

Re: Sandboxed iframes (was Re: Seamless iframes + CSS3 selectors = bad idea)

From: Maciej Stachowiak <mjs@apple.com>
Date: Sun, 06 Dec 2009 06:04:08 -0800
Cc: "sird@rckc.at" <sird@rckc.at>, public-web-security@w3.org
Message-id: <1895BA1A-DAF5-4F01-A53A-77D7DF796E86@apple.com>
To: Ian Hickson <ian@hixie.ch>

On Dec 6, 2009, at 2:30 AM, Ian Hickson wrote:

> On Sun, 6 Dec 2009, Maciej Stachowiak wrote:
>> On Dec 6, 2009, at 1:38 AM, Ian Hickson wrote:
>>> On Sun, 6 Dec 2009, sird@rckc.at wrote:
>>>>
>>>> ian, isnt allow-same-origin confusing? since if its same origin  
>>>> what
>>>> stops you from linking it and bypassing those protections.
>>>
>>> allow-same-origin is only really intended to be used with the
>>> aforementioned doc="" attribute idea (eventually) and data: URIs (in
>>> the meantime). The example you mention is indeed misleading.
>>
>> It seems like a data: URI would not do the trick, since it already  
>> has a
>> unique origin, so allow-same-origin would not do what it is  
>> intended to.
>> I believe you would have to document.write() into the iframe's  
>> content
>> document (after loading about:blank), or load it with a javascript:  
>> URI
>> containing a constant string.
>
> The origin of a data: Document is the same as its parent browsing
> context's Document's origin.

It does look like HTML5 says something like that.

WebKit uses unique origins for data: URIs, which I think Gecko used to  
do as well, but it looks like they have changed. It's a security hole  
to use the parent's origin, if you can cause navigation to a data: URI  
in a frame in a different-origin parent.

What HTML5 actually says is somewhat different from what you stated  
above:

"If a Document or image was generated from a data: URL found in  
another Document or in a script
     The origin is the origin of the Document or script in which the  
data: URL was found."

Taken literally this rule does not seem practically implementable. UAs  
would have change their JavaScript implementations to tag every  
JavaScript string value with an origin, to keep track of where it was  
found if it gets passed cross-origin (e.g. via postMessage). It's also  
possible for data: URLs not to be found in any script or document, if  
they are created by script in appending multiple strings or taking  
user input.

What Firefox seems to do is give a data: URL frame the same origin as  
the frame that initiated navigating it to that data: URL. That seems  
like a secure and implementable rule.

Regards,
Maciej
Received on Sunday, 6 December 2009 14:04:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 19 December 2010 00:16:01 GMT