dev-doc-complete, sec-want, site-compat
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. ***
Whiteboard: [sg:investigate] cross-browser consistency issue
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. ***
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. /be
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. /be
Assignee: dveditz → brendan
> 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). Precisely. > 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). /be
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.
Flags: blocking1.9? → blocking1.9+
Not realistic to fix until we have a well-tested trunk solution, since we know this will break sites relying on the current behavior.
Flags: blocking1.9+ → blocking1.9-
Whiteboard: [sg:investigate] cross-browser consistency issue → [sg:investigate] cross-browser consistency issue [wanted-1.9]
Whiteboard: [sg:investigate] cross-browser consistency issue [wanted-1.9] → [sg:investigate] cross-browser consistency issue
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.
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. /be
Assignee: brendan → nobody
Whiteboard: [sg:investigate] cross-browser consistency issue → [sg:want?][wontfix?] cross-browser consistency issue
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?
Duplicate of this bug: 907105
Duplicate of this bug: 919213
Component: Security → DOM: Security
Priority: -- → P3
Whiteboard: [sg:want?][wontfix?] cross-browser consistency issue → [domsecurity-backlog3][sg:want?][wontfix?] cross-browser consistency issue
3 years ago
It looks like this 14 year old bug can now be closed! The spec itself has been brought into alignment: https://github.com/whatwg/html/commit/00769464e80149368672b894b50881134da4602f And 1018872 is resolved.
Chris, do you think there's any need to keep this open? :)
I am fine with closing this one: All the required work happened within Bug 1324406.
Status: NEW → RESOLVED
Last Resolved: 11 months ago
Resolution: --- → FIXED
Required doc updates were done for bug 1324406.
Keywords: dev-doc-needed → dev-doc-complete
You need to log in before you can comment on or make changes to this bug.