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 13:59:40 -0800
Message-ID: <7789133a0912061359l13c7bb99v6596b4acae0b0793@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Maciej Stachowiak <mjs@apple.com>, Ian Hickson <ian@hixie.ch>, "sird@rckc.at" <sird@rckc.at>, public-web-security@w3.org
On Sun, Dec 6, 2009 at 1:47 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> Gecko has used the "parent" origin for data: URIs at least since mozilla bug
> 31818 was fixed in June 2000.
> [...]
> We do happen to think that this behavior is secure, and reasonably
> implementable.  It does have a gotcha for website developers, however: if
> they allow user-contributed <iframe> or <object> elements and don't vet the
> "src" and "data" attribute, respectively, it allows the user to inject
> scriptable content into the page's origin...  I happen to think that not
> vetting @src and @data is a problem in any case, but apparently some people
> don't do it.

In some sense, a site needs to vet all URLs for javascript URLs, but
this behavior means that every time you see "javascript:" in an XSS
filter, they're probably insecure unless you also see "data:" right
next door.  (By the way, I'd imagine data URLs in a@href is a more
common XSS hole than iframe@src.)

I don't think anyone would argue that javascript URLs impose large
security costs, they just happen to be very, very useful.  The
question is whether inheriting the security context for data URLs is
sufficiently useful to justify the security costs.

The sad part is that the standoff restrains sites from realizing the
benefits of privilege inheritance because they can't rely on it
working on Safari, but Firefox users continue to bear the security

Received on Sunday, 6 December 2009 22:06:12 UTC

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