users from linking to data: URLs. To prevent data: URLs from being used for XSS
exploits, we should make scripts from data: URLs unable to access other content
from the domain they're in. Scripts from data: URLs should still have a
protocol/hostname/port associated with them, but they should be restricted to
reading/writing within the same page and other pages they create.
Site A <---> Data: URL from A Site B
Site A ----> Data: URL from A Site B
data: URLs would also have to be prevented from accessing document.cookie.
Most moderately complex use cases of data: involve talking back and forth with
the page that created the data: URI.
Blocking just the "unsafe" stuff is always a bad strategy. As we all know, the
correct way to do things like this is to only let in valid data, which means if
you're going to let in an attribute containing a URI, you only let it in if it
is a safe URI.
You could just as easily argue that sites might allow users to upload HTML files
to their server and might then let them link to them and so we shouldn't allow
pages on the same domain to access other pages on the same domain.
IMHO this should be a WONTFIX.
See also bug 296871, "domain of data: URI is domain of container document".
*** Bug 296871 has been marked as a duplicate of this bug. ***
We received a report about this XSS today within our product, after a few tests it appears that only Gecko has an issue. Both Safari and Opera use a different security context, it would be nice if Gecko followed thsi behaviour since it seems a shame to disable the data protocol.
The problem is that the data: protocol is pretty much useless if we follow that behavior.
*** Bug 354056 has been marked as a duplicate of this bug. ***
From #webkit about a month ago:
<othermaciej> given that, I'd be inclined to restrict data: URLs both ways (no readability except to parent/opener, but they in turn have no access to anything)
That implies an asymmetric security model where principal A can read principal B but not vice versa. This is pretty hard to get right across the board, and even then doesn't work that well. e.g. if I access some node in the data: document and then call its toString, but that's been overridden, I'm possibly running data: code with my permissions. Or if I take a node from the data: and try to put it into my document, same thing.
It's a _very_ hard model for developers to work with -- witness the problems we've had with chrome (which has this exact same setup) to the point where we had to implement XPCNativeWrapper.
I have no good solution to this, but I encourage you to discuss this with the Opera and Safari guys and let me know what your decision is so I can spec it.
The other option is to disable script execution in data: documents altogether (but still place them in the same security context as the document they're loaded from).
Let's not just break scripts in data: because we think our security architecture can't cope. Let's do what Hixie encourages. Who will take up the task of mailing Opera and Apple folks? I happen to have access to one Opera and one ex-Opera hacker who are in town, so I will see what they say and report back.
Brendan, our security architecture _can't_ cope. Esp. on branches. In my opinion, of course. ;)
(In reply to comment #14)
> Brendan, our security architecture _can't_ cope. Esp. on branches. In my
> opinion, of course. ;)
I recall landing nsIPrincipal::subsumes on the 1.8 branch: http://lxr.mozilla.org/mozilla1.8/source/caps/idl/nsIPrincipal.idl
This stuff has to work already, or closed bugs should be reopened.
> I recall landing nsIPrincipal::subsumes on the 1.8 branch:
There are exactly two callers; most places are just doing a same-origin check when they should be doing subsumes checks in one direction or the other (imo).
I suspect a number of places that need to do so don't necessarily know which direction is which either.
(In reply to comment #16)
> > I recall landing nsIPrincipal::subsumes on the 1.8 branch:
> There are exactly two callers; most places are just doing a same-origin check
> when they should be doing subsumes checks in one direction or the other (imo).
> I suspect a number of places that need to do so don't necessarily know which
> direction is which either.
Aren't the two arguments, in order, source and target (subject and object)? If so, then instead of source == target we would want >= (== is same origin, >= is subsumes).
Sadly, "source and target" is not the same thing as "subject and object" in some cases. And some of our code doesn't really know which is which even for "source and target", as I recall.
*** Bug 368221 has been marked as a duplicate of this bug. ***
Not realistic to fix until we have a well-tested trunk solution, since we know this will break sites relying on the current behavior.
The current version of Acid 3 encourages other browser vendors to match Firefox's behavior here. See http://bugs.webkit.org/show_bug.cgi?id=16968.
Acid3 has changed to not longer rely on this. However, I do think we should do something like what Firefox did. More thoughts on the WHATWG list or in the HTML5 spec in due course.
*** Bug 418198 has been marked as a duplicate of this bug. ***
I'm a bad owner, without time to work on this, and out of date on HTML5 thinking. Throwing back in pool, inviting someone with time and expertise to take.
*** Bug 654016 has been marked as a duplicate of this bug. ***
*** Bug 667332 has been marked as a duplicate of this bug. ***
*** Bug 723246 has been marked as a duplicate of this bug. ***
Reading through this bug, in context of http://blog.kotowicz.net/2011/10/sad-state-of-dom-security-or-how-we-all.html.
It looks like Boris' objection to adopting the Safari/Opera/Chrome model of a different security context was that it removes the usefulness of data: URIs. However, we now have postMessage(), which allows safe communication with data: URIs even if they're in a different context.
Does that make it more useful to adopt the separate-context model now?
*** Bug 907105 has been marked as a duplicate of this bug. ***
*** Bug 919213 has been marked as a duplicate of this bug. ***
*** Bug 1146922 has been marked as a duplicate of this bug. ***
*** Bug 1227681 has been marked as a duplicate of this bug. ***
*** Bug 1229161 has been marked as a duplicate of this bug. ***
*** Bug 1253322 has been marked as a duplicate of this bug. ***