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)

x86
Windows XP
defect

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
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.
Blocks: xss
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. ***
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)
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.
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?
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: 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+
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?
Flags: blocking1.9+ → blocking1.9-
Whiteboard: [sg:investigate] cross-browser consistency issue → [sg:investigate] cross-browser consistency issue [wanted-1.9]
QA Contact: toolkit
Flags: wanted1.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
Blocks: 354493
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?
Depends on: 1018872
Blocks: 1225524
Alias: dataxss
Component: Security → DOM: Security
Priority: -- → P3
Whiteboard: [sg:want?][wontfix?] cross-browser consistency issue → [domsecurity-backlog3][sg:want?][wontfix?] cross-browser consistency issue
Keywords: site-compat
Severity: enhancement → normal
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? :)
Flags: needinfo?(ckerschb)
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
Required doc updates were done for bug 1324406.
You need to log in before you can comment on or make changes to this bug.