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

On 12/6/09 9:04 AM, Maciej Stachowiak wrote:
> 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.

Gecko has used the "parent" origin for data: URIs at least since mozilla 
bug 31818 was fixed in June 2000.

That said "parent" is not the parent document, but whatever triggered 
the load, in the following sense:

1) If the load happens due to a change in the src attribute of a frame
    the origin of that frame's owner document is used.
2) If the load happens due to a window.location manipulation, the
    origin of the script performing said manipulation is used.
3) If a link click or form submission triggered the load, the origin of
    the ownerDocument of the <a> or <form> DOM node is used.
4) In some cases the origin that's used is the origin of whatever was
    loaded in the navigation context before the data: load.  None of
    these cases can be triggered by Web-exposed APIs.

I think that's a more or less complete list; effectively the entity 
performing the load in Gecko code has to indicate what origin should be 
used for the load; the above cases so indicate.  If no origin is 
indicated a nonce origin is used.

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.

-Boris

Received on Sunday, 6 December 2009 21:48:34 UTC