Closed Bug 242656 Opened 21 years ago Closed 21 years ago

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

Categories

(Core :: Security, enhancement)

x86
Windows XP
enhancement
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: io, Assigned: security-bugs)

References

()

Details

Attachments

(1 file)

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:
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.
(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?
Attached file 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...
(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
Closed: 21 years ago
Resolution: --- → INVALID
*** Bug 283619 has been marked as a duplicate of this bug. ***
*** 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.

Attachment

General

Creator:
Created:
Updated:
Size: