If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED INVALID

Status

()

Core
Security
--
enhancement
RESOLVED INVALID
14 years ago
11 years ago

People

(Reporter: Alessio, Assigned: Mitchell Stoltz (not reading bugmail))

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

309 bytes, text/html
Details
(Reporter)

Description

14 years ago
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

14 years ago
WFM 1.7RC1/W2K

Comment 2

14 years ago
Ignore my previous comment.
Why is that an insecure situation, exactly?
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)
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.
(Reporter)

Comment 6

14 years ago
(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 ;)
Does IE send referrer if the window.open is just done via an onclick, say, not
via a javascript: url?

Comment 8

14 years ago
Created attachment 147795 [details]
links

MSIE 6.0 doesn't send referrer in both cases (onclick event and javascript:
link).
But it sends it on <a href="" target="_blank">?

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

Comment 10

14 years ago
(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.
> 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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → INVALID
*** Bug 283619 has been marked as a duplicate of this bug. ***

Comment 13

11 years ago
*** Bug 359851 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.