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: Mon, 07 Dec 2009 11:03:14 -0800
Cc: Boris Zbarsky <bzbarsky@mit.edu>, Ian Hickson <ian@hixie.ch>, "sird@rckc.at" <sird@rckc.at>, public-web-security@w3.org
Message-id: <61733C23-793B-472A-997D-D3FA3B28EFC2@apple.com>
To: Adam Barth <w3c@adambarth.com>

On Dec 7, 2009, at 9:39 AM, Adam Barth wrote:

> On Mon, Dec 7, 2009 at 2:39 AM, Maciej Stachowiak <mjs@apple.com>  
> wrote:
>> On Dec 6, 2009, at 1:47 PM, Boris Zbarsky wrote:
>>> That said "parent" is not the parent document, but whatever  
>>> triggered the
>>> load, in the following sense:
>>
>> Right, "whatever triggered the load" is secure, but "parent"  
>> literally is
>> not. Note that "about:blank" can literally follow a parent/opener  
>> rule
>> without creating a security problem - it doesn't need to get the  
>> origin of
>> whatever triggered the load.
>
> Ah, I misunderstood your earlier email.  Using "parent" literally is
> of course disaster.  Using the same algorithm WebKit uses for
> "about:blank" (or something similar) is not universal XSS.  It's just
> problematic for folks who are blacklisting javascript URLs.  You can
> say that these folks are foolish, but they certainly exist.

Actually, using the same algorithm WebKit uses for "about:blank"  
*would* be universal XSS, since "about:blank" is same-origin with the  
parent or opener regardless of who initiated the navigation. (The  
reason this is safe for about:blank but not for data: URLs is that the  
attacker cannot put arbitrary contents in an about:blank frame).

Our handling of javascript: URLs is a bit closer to what is desired,  
in that we won't execute javascript: URLs at all cross-origin.  
However, this is done by preventing them from being sent cross-origin  
in the first place. I believe this also violates HTML5 as written -  
HTML5 seems to require executing such JavaScript URLs in an empty  
environment and using their string (although the wording there seems  
kind of vague).


>
>> I do think the Gecko behavior is secure and implementable (I said  
>> so in
>> another message). I think it would be reasonable for HTML5 to spec  
>> it. I
>> think what HTML5 says right now does not obviously mach this rule.  
>> I think
>> it would need to introduce a notion of the origin that initiated a  
>> load or
>> navigation to get this right. I think that may also be necessary for
>> javascript: URIs - the way javascript: URI handling is spec'd right  
>> now is
>> kind of vague on the origin details.
>
> I think that HTML5 already has a notion of the active principal for a
> navigation / resource fetch.  My understanding of Gecko is that data
> URLs get the origin of this active principal.
>
> Personally, I would be very happy to see this lack of interoperability
> resolved.  I would encourage you not to view the issue with a
> black-and-white "secure" or "insecure" perspective.  It's clear that
> the WebKit behavior is more secure than the Gecko behavior (in a way
> we can make precise).  The question is one of balancing the security
> costs with the interoperability/functionality benefits.
>
> If you're sure you want WebKit to adopt the Gecko behavior, I'll be
> the first one in line to write the patch.

I'm not *sure* I want it, I'm just saying that it wasn't a conscious  
decision for WebKit to diverge from Gecko, so it's not quite right to  
label the situation a "standoff".

Personally, I'm happy to go with whatever other browser vendors agree  
to, but perhaps we should discuss the benefits vs. security risks  
(maybe on whatwg or public-html) to make sure we are making a well- 
considered choice. The Gecko policy does have some clear advantages -  
it makes data: URLs much more useful because they can replace the  
cases handled by <iframe src="javascript:'string here'"> or  
document.writing into an about:blank iframe without having to execute  
script to populate the frame. If the security costs can be made  
precise, then let's do so, so that we are making an informed decision.

Regards,
Maciej
Received on Monday, 7 December 2009 19:03:57 GMT

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