- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sun, 06 Dec 2009 16:47:53 -0500
- To: Maciej Stachowiak <mjs@apple.com>
- CC: Ian Hickson <ian@hixie.ch>, "sird@rckc.at" <sird@rckc.at>, public-web-security@w3.org
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