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

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

From: Adam Barth <w3c@adambarth.com>
Date: Mon, 7 Dec 2009 09:39:38 -0800
Message-ID: <7789133a0912070939r1370718cud3d766e097847b80@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, Ian Hickson <ian@hixie.ch>, "sird@rckc.at" <sird@rckc.at>, public-web-security@w3.org
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.

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

Received on Monday, 7 December 2009 17:40:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:23 UTC