Closed
Bug 255107
(dataxss)
Opened 20 years ago
Closed 6 years ago
Prevent data: URLs from being used for XSS
Categories
(Core :: DOM: Security, defect, P3)
Tracking
()
RESOLVED
FIXED
People
(Reporter: jruderman, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: dev-doc-complete, sec-want, site-compat, Whiteboard: [domsecurity-backlog3][sg:want?][wontfix?] cross-browser consistency issue)
Many sites prevent users from linking to javascript: URLs but don't prevent 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. Current: Site A <---> Data: URL from A Site B Proposed: Site A ----> Data: URL from A Site B
Reporter | ||
Comment 1•20 years ago
|
||
data: URLs would also have to be prevented from accessing document.cookie.
Comment 2•20 years ago
|
||
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.
Reporter | ||
Comment 3•18 years ago
|
||
See also bug 296871, "domain of data: URI is domain of container document".
Reporter | ||
Comment 4•18 years ago
|
||
*** Bug 296871 has been marked as a duplicate of this bug. ***
Reporter | ||
Updated•18 years ago
|
Whiteboard: [sg:investigate] cross-browser consistency issue
Comment 5•18 years ago
|
||
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.
Comment 6•18 years ago
|
||
The problem is that the data: protocol is pretty much useless if we follow that behavior.
Reporter | ||
Comment 7•18 years ago
|
||
*** Bug 354056 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 8•18 years ago
|
||
From #webkit about a month ago: <jruderman> it would be good to have safari and gecko agreeing on it one way or the other. it's no fun to have data: urls unsafe in one way in gecko (forums can't allow data: links just like they can't allow javascript: links) and unsafe in another way in safari (sites can't put user-specific data in data: urls because of they're readable by other sites) <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)
Comment 9•18 years ago
|
||
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.
Comment 10•18 years ago
|
||
Perhaps the right solution is to simply allow a site to annotate its <a> and <frame>/<iframe> elements as "trusted" or "not trusted" and only inherit the principal for "trusted" data: and javascript: URIs (and create a null principal otherwise)? Alternately, we could make it a tri-state (trusted/untrusted/unknown) and inherit only for explicitly-trusted data: and all-but-untrusted javascript: (the latter for web compat, the former because data: is rarely used), but that again has mind-print issues for web developers.... but only those who are aware of data:, I guess. Thoughts?
Comment 11•18 years ago
|
||
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.
Comment 12•17 years ago
|
||
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).
Comment 13•17 years ago
|
||
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
Comment 14•17 years ago
|
||
Brendan, our security architecture _can't_ cope. Esp. on branches. In my opinion, of course. ;)
Comment 15•17 years ago
|
||
(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
Comment 16•17 years ago
|
||
> 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.
Comment 17•17 years ago
|
||
(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
Comment 18•17 years ago
|
||
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.
Updated•17 years ago
|
Flags: wanted1.8.1.x+
Flags: wanted1.8.0.x+
Flags: blocking1.9?
Flags: blocking1.8.1.3?
Flags: blocking1.8.0.11?
Flags: blocking1.9? → blocking1.9+
Comment 20•17 years ago
|
||
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.8.1.4?
Flags: blocking1.8.0.12?
Updated•17 years ago
|
Flags: blocking1.9+ → blocking1.9-
Whiteboard: [sg:investigate] cross-browser consistency issue → [sg:investigate] cross-browser consistency issue [wanted-1.9]
Updated•17 years ago
|
QA Contact: toolkit
Updated•16 years ago
|
Flags: wanted1.9+
Whiteboard: [sg:investigate] cross-browser consistency issue [wanted-1.9] → [sg:investigate] cross-browser consistency issue
Reporter | ||
Comment 21•16 years ago
|
||
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.
Comment 22•16 years ago
|
||
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.
Comment 24•15 years ago
|
||
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
Reporter | ||
Updated•14 years ago
|
Whiteboard: [sg:investigate] cross-browser consistency issue → [sg:want?][wontfix?] cross-browser consistency issue
Comment 28•12 years ago
|
||
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?
Updated•8 years ago
|
Alias: dataxss
Updated•8 years ago
|
Keywords: dev-doc-needed
Updated•8 years ago
|
Component: Security → DOM: Security
Priority: -- → P3
Whiteboard: [sg:want?][wontfix?] cross-browser consistency issue → [domsecurity-backlog3][sg:want?][wontfix?] cross-browser consistency issue
Updated•8 years ago
|
Keywords: site-compat
Updated•8 years ago
|
Severity: enhancement → normal
Comment 47•6 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.
Comment 48•6 years ago
|
||
Chris, do you think there's any need to keep this open? :)
Flags: needinfo?(ckerschb)
Comment 49•6 years ago
|
||
I am fine with closing this one: All the required work happened within Bug 1324406.
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(ckerschb)
Resolution: --- → FIXED
Comment 50•6 years ago
|
||
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.
Description
•