242656 - referer http header should not be sent when a new window is opened by javascript code

Status: RESOLVED INVALID

(Core :: Security, enhancement)

Description

[Alessio]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316

The "referer" http header should not be sent when security can be compromised
(rfc2616 - 15.1.3).

Unsecure situations could be:
(http://support.microsoft.com/default.aspx?scid=kb;EN-US;q178066)

"...Internet Explorer will not send the Referer header for each of the following
example hyperlinks from one document URL to another document URL:
1- javascript:somejavascriptcode --> http://example.microsoft.com
2- file://c:\alocalhtmlfile.htm  --> http://example.microsoft.com
3- https://example.microsoft.com --> http://www.microsoft.com..."

Case 1 is not actually supported by Mozilla: if a javascript opens a new window,
ie window.open(someurl), Mozilla sends the referer http header (Internet
Explorer doesn't)
Since the above mentioned RFC paragraph doesn't specify what are "unsecure
situations" (other than passing from https to http, obviously), Mozilla should
provide at least a security toggle switch to allow/unallow referer http header
being sent when some javascript code opens a new url.

Reproducible: Always
Steps to Reproduce:

Comment 1

[Adam Hauner]

WFM 1.7RC1/W2K

Comment 2

[Adam Hauner]

Ignore my previous comment.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Why is that an insecure situation, exactly?

Comment 4

[Christopher Hoess (gone)]

According to the reference (RFC 2616 15.1.3), "Because the source of a link
might be private information or might reveal an otherwise private information
source, it is strongly recommended that the user be able to select whether or
not the Referer field is sent." (e.g., you don't want to publish the location of
a file on your local hard drive, AIUI)

Comment 5

[Boris Zbarsky [:bzbarsky]]

Yes, but we already have a pref to control this, and a file:// referrer will
NEVER get sent to an http:// URI, no matter what the pref setting is.  So the
question remains, why is this a security-sensitive situation any more than any
other window.open() call?  Note that not sending referrer on window.open in
general _will_ break sites.

Comment 6

[Alessio]

(In reply to comment #3)
> Why is that an insecure situation, exactly?

I don't yet know, I'm still thinking about that... we should ask Microsoft ;)

Comment 7

[Boris Zbarsky [:bzbarsky]]

Does IE send referrer if the window.open is just done via an onclick, say, not
via a javascript: url?

Comment 8

[Adam Hauner]

Attachment: links

MSIE 6.0 doesn't send referrer in both cases (onclick event and javascript:
link).

Comment 9

[Boris Zbarsky [:bzbarsky]]

But it sends it on <a href="" target="_blank">?

In short, I just see a bug in IE, not a security issue in Mozilla...

Comment 10

[Alessio]

(In reply to comment #9)
> But it sends it on <a href="" target="_blank">?

yes

> In short, I just see a bug in IE, not a security issue in Mozilla...

it's not a bug since Microsoft documented this here:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q178066
and this behaviour is the same from IE4.x to IE6.x
Microsoft explicitly decided, for security reasons (without specifying exactly
which ones), to not send the referer when a javascript opens an url.

Comment 11

[Boris Zbarsky [:bzbarsky]]

> it's not a bug since Microsoft documented this here:

They don't document onclick there, do they?  So I don't see what this document
has to do withthe discussion.  We're talking about IE not sending referrer for
window.open() in general (whereas in the same exact circumstances, it'll send it
if you set document.location instead of opening a new window).  Hence the bug in
IE -- inconsistent treatment of basically same methods of opening a URI.

We do _exactly_ the sort of protocol filtering they talk about (look it up in
nsHttpChannel:SetReferrer!), but "javascript:foo" is not treated as a separate
"site" (like it apparently is in IE) because it's not -- it's just JS running on
the page in question.  Again, all they "decided" is that they can't tell what
the original URI was so their same-scheme policy blocks it.  That's fine, but
that's not a security decision, it's a bug.

I'm marking this invalid, since I don't believe we need to be emulating the IE
bugs and we already implement a security policy identical to that document,
modulo the aforementioned IE bugs.

Comment 12

[Daniel Veditz [:dveditz]]

*** Bug 283619 has been marked as a duplicate of this bug. ***

Comment 13

[Jesse Ruderman]

*** Bug 359851 has been marked as a duplicate of this bug. ***