Last Comment Bug 255107 - (dataxss) Prevent data: URLs from being used for XSS
(dataxss)
: Prevent data: URLs from being used for XSS
Status: NEW
[domsecurity-backlog3][sg:want?][wont...
: dev-doc-needed, sec-want, site-compat
Product: Core
Classification: Components
Component: DOM: Security (show other bugs)
: Trunk
: x86 Windows XP
: P3 normal with 8 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
: 296871 354056 368221 418198 654016 667332 723246 907105 919213 1146922 1225524 1227681 1229161 1238498 1253322 1278631 1284804 1292485 1297385 1303039 (view as bug list)
Depends on: 1018872
Blocks: 354493 xss 1225524
  Show dependency treegraph
 
Reported: 2004-08-10 16:58 PDT by Jesse Ruderman
Modified: 2016-09-16 02:46 PDT (History)
66 users (show)
mconnor: blocking1.9-
reed: wanted1.9+
dveditz: wanted1.8.1.x+
dveditz: wanted1.8.0.x+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Jesse Ruderman 2004-08-10 16:58:05 PDT
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
Comment 1 Jesse Ruderman 2004-08-10 16:59:18 PDT
data: URLs would also have to be prevented from accessing document.cookie.
Comment 2 Hixie (not reading bugmail) 2004-08-11 01:45:35 PDT
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.
Comment 3 Jesse Ruderman 2006-01-26 23:22:00 PST
See also bug 296871, "domain of data: URI is domain of container document".
Comment 4 Jesse Ruderman 2006-05-06 00:31:25 PDT
*** Bug 296871 has been marked as a duplicate of this bug. ***
Comment 5 Scott MacVicar 2006-09-05 03:40:25 PDT
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 Boris Zbarsky [:bz] (still a bit busy) 2006-09-05 08:22:49 PDT
The problem is that the data: protocol is pretty much useless if we follow that behavior.
Comment 7 Jesse Ruderman 2006-09-24 22:41:35 PDT
*** Bug 354056 has been marked as a duplicate of this bug. ***
Comment 8 Jesse Ruderman 2006-12-15 07:37:53 PST
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 Boris Zbarsky [:bz] (still a bit busy) 2006-12-15 08:35:33 PST
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 Boris Zbarsky [:bz] (still a bit busy) 2006-12-15 09:13:25 PST
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 Hixie (not reading bugmail) 2006-12-15 10:27:47 PST
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 Boris Zbarsky [:bz] (still a bit busy) 2007-01-22 20:40:17 PST
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 Brendan Eich [:brendan] 2007-01-23 09:40:13 PST
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 Boris Zbarsky [:bz] (still a bit busy) 2007-01-23 10:00:26 PST
Brendan, our security architecture _can't_ cope.  Esp. on branches.  In my opinion, of course.  ;)
Comment 15 Brendan Eich [:brendan] 2007-01-23 19:03:24 PST
(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

Comment 16 Boris Zbarsky [:bz] (still a bit busy) 2007-01-23 19:42:34 PST
> 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 Brendan Eich [:brendan] 2007-01-23 21:40:50 PST
(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 Boris Zbarsky [:bz] (still a bit busy) 2007-01-23 21:49:13 PST
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.
Comment 19 Daniel Veditz [:dveditz] 2007-01-25 14:34:02 PST
*** Bug 368221 has been marked as a duplicate of this bug. ***
Comment 20 Daniel Veditz [:dveditz] 2007-03-26 15:10:10 PDT
Not realistic to fix until we have a well-tested trunk solution, since we know this will break sites relying on the current behavior.
Comment 21 Jesse Ruderman 2008-01-23 21:37:05 PST
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 Hixie (not reading bugmail) 2008-01-30 16:10:40 PST
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 23 Jesse Ruderman 2008-02-18 12:37:58 PST
*** Bug 418198 has been marked as a duplicate of this bug. ***
Comment 24 Brendan Eich [:brendan] 2009-07-16 13:38:08 PDT
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
Comment 25 Thomas Ahlblom 2011-05-13 08:20:36 PDT
*** Bug 654016 has been marked as a duplicate of this bug. ***
Comment 26 Daniel Veditz [:dveditz] 2011-06-27 12:14:28 PDT
*** Bug 667332 has been marked as a duplicate of this bug. ***
Comment 27 Matthias Versen [:Matti] 2012-02-02 05:45:24 PST
*** Bug 723246 has been marked as a duplicate of this bug. ***
Comment 28 Jacob 2012-08-15 17:08:22 PDT
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?
Comment 29 Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]] 2013-08-20 07:01:29 PDT
*** Bug 907105 has been marked as a duplicate of this bug. ***
Comment 30 Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]] 2013-09-23 05:53:58 PDT
*** Bug 919213 has been marked as a duplicate of this bug. ***
Comment 31 Benjamin Smedberg [:bsmedberg] 2015-03-24 09:10:46 PDT
*** Bug 1146922 has been marked as a duplicate of this bug. ***
Comment 32 Daniel Veditz [:dveditz] 2015-11-24 13:45:58 PST
*** Bug 1227681 has been marked as a duplicate of this bug. ***
Comment 33 :Gijs Kruitbosch 2015-11-30 14:06:44 PST
*** Bug 1229161 has been marked as a duplicate of this bug. ***
Comment 34 :Gijs Kruitbosch 2016-03-03 09:25:01 PST
*** Bug 1253322 has been marked as a duplicate of this bug. ***
Comment 35 Daniel Veditz [:dveditz] 2016-06-30 13:53:29 PDT
*** Bug 1278631 has been marked as a duplicate of this bug. ***
Comment 36 Daniel Veditz [:dveditz] 2016-06-30 13:56:14 PDT
*** Bug 1238498 has been marked as a duplicate of this bug. ***
Comment 37 Benjamin Smedberg [:bsmedberg] 2016-07-07 09:57:57 PDT
*** Bug 1284804 has been marked as a duplicate of this bug. ***
Comment 38 Daniel Veditz [:dveditz] 2016-07-18 22:35:16 PDT
*** Bug 1225524 has been marked as a duplicate of this bug. ***
Comment 39 Daniel Veditz [:dveditz] 2016-08-10 17:53:19 PDT
*** Bug 1292485 has been marked as a duplicate of this bug. ***
Comment 40 Daniel Veditz [:dveditz] 2016-08-29 22:19:06 PDT
*** Bug 1297385 has been marked as a duplicate of this bug. ***
Comment 41 Christoph Kerschbaumer [:ckerschb] 2016-09-16 01:25:13 PDT
*** Bug 1303039 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.