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: Sun, 6 Dec 2009 08:31:24 -0800
Message-ID: <7789133a0912060831w52caf8c4mb7b867b45d1b9911@mail.gmail.com>
To: "sird@rckc.at" <sird@rckc.at>
Cc: Maciej Stachowiak <mjs@apple.com>, Ian Hickson <ian@hixie.ch>, public-web-security@w3.org
On Sun, Dec 6, 2009 at 7:06 AM, sird@rckc.at <sird@rckc.at> wrote:
> Anyway, maybe I misunderstood what he said, I thought he meant in chrome it
> was a new and exclusive origin (different from the parent one) and my tests
> sort of confirmed that.

WebKit-based browser (Safari, Chrome, etc) use a unique origin for
data URLs.  This is out-of-spec with HTML5, but Maciej and other think
the spec's behavior is a security vulnerability.

> On firefox for example, the origin is something a little weird (that is
> probably the same maciej just explained). where you have a different origin
> but access to parent/opener..

Firefox inherits the origin from the parent / opener, just like for about:blank.

IE had dodged the issue by carefully ensuring that you can't use data
URLs in any situation where you could tell their security context.

IMHO, as long as we have this stand-off about the security context of
data URLs, we won't be able to reap the benefits of having them
inherit their origin and we will be saddled with the security costs
(at least in Firefox).  Game theoretically, that means data URLs will
end up getting a unique origin unless the use cases for inherited
origin are so compelling that developers are willing to have their
site not work in Safari and IE (which doesn't seem to have happened
yet).

Adam
Received on Sunday, 6 December 2009 16:32:17 GMT

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