263216 - links opened into new tab from ChatZilla pass the URL of the current tab as the http Referer

Status: RESOLVED FIXED

(Firefox :: Tabbed Browser, defect, P4)

Description

[Rob Marshall [tH]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-gb; rv:1.7.3) Gecko/20041002 Firefox/0.10
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-gb; rv:1.7.3) Gecko/20041002 Firefox/0.10

Chatzilla 0.9.65 [Mozilla rv:1.7.3/20041002]

When I click a link in ChatZilla, the Referer: header passed to the new page
includes the URL of my active tab.

Reproducible: Always
Steps to Reproduce:
1. Open a page, for example, http://www.mozilla.org/ .
2. Leaving that page as the current tab, open ChatZilla.
3. Say "http://rdmsoft.com/bugs/showreferrer.php" in a channel and click the link.

Actual Results:  
The php page (<?php echo $_SERVER['HTTP_REFERER']; ?>) is able to see the
address of the tab that was active when you clicked the link in ChatZilla.

Expected Results:  
No referrer information should be passed, the script on my server shouldn't know
what was on your active tab.

Comment 1

[James Ross]

However I open the URL, it works here (i.e. it's entirely blank).

It would most likely be a Mozilla bug anyway, should the referrer be leaking.

Comment 2

[Pawel Worach]

I see this also, firefox 1.0+ and cz 0.9.66

Reproduced using this text in chatzilla.
"click this link http://slashdot.org/favicon.ico then this link bug 268629 makes
bz say Ook!"

Even the first link has the referrer of the firefox start page (google.com/firefox).

The LiveHttpHeaders extension says:

http://slashdot.org/favicon.ico

GET /favicon.ico HTTP/1.1
Host: slashdot.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
Gecko/20041109 Firefox/1.0
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer:
http://www.google.com/firefox?client=firefox-a&rls=org.mozilla:en-US:official
If-Modified-Since: Thu, 04 Nov 2004 15:47:00 GMT
If-None-Match: "1f81e5-13e-418a4ef4"
Cache-Control: max-age=0

HTTP/1.x 304 Not Modified
Date: Tue, 09 Nov 2004 19:00:41 GMT
Server: Apache/1.3.29 (Unix) mod_gzip/1.3.26.1a mod_perl/1.29
Connection: close
Etag: "1f81e5-13e-418a4ef4"
----------------------------------------------------------
https://bugzilla.mozilla.org/show_bug.cgi?id=268629

GET /show_bug.cgi?id=268629 HTTP/1.1
Host: bugzilla.mozilla.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
Gecko/20041109 Firefox/1.0
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://slashdot.org/favicon.ico

HTTP/1.x 302 Found
Date: Tue, 09 Nov 2004 19:00:30 GMT
Server: Apache/1.3.27 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.12 OpenSSL/0.9.6b
DAV/1.0.3 PHP/4.1.2 mod_perl/1.26
Location: https://bugzilla.mozilla.org/slashdot/index.html?id=268629
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
----------------------------------------------------------

Comment 3

[Tuukka Tolvanen (sp3000)]

confirmed linux fx 1.0 + cz 0.9.66

This only happens when opening into a new tab; open in same tab and open in new
window are not affected. cf bug 258185

Comment 4

[James Ross]

This is not a ChatZilla bug, it's a Firefox bug. Firefox's openNewTabWith
function does not give any options on referrer - it always sends it. In Mozilla,
the function gives us the choice - and ChatZilla says "no thanks" to the referrer.

Compare
http://lxr.mozilla.org/mozilla/source/xpfe/communicator/resources/content/contentAreaUtils.js#118
to http://lxr.mozilla.org/mozilla/source/browser/base/content/contentAreaUtils.js#6

However, I don't know what to do with this bug... 

I really really object to the idea of copying and re-writing the code in
openNewTabWith to ChatZilla, as that breaks the whole encaptulation thing.

I'm actually leaning on WONTFIX for this, as there's nothing sensible ChatZilla
can do about this Firefox bug that I can see/find.

Comment 5

[Steffen Wilberg]

-> Firefox.

Comment 6

[James Ross]

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

Comment 7

[James Ross]

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

Comment 8

[:Gavin Sharp [email: [e-mail]]]

This is only a problem with Chatzilla's use of the internal openNewTabWith
function, right? In that case, lets just add the parameter for whether or not to
send referer data like Seamonkey, and have Chatzilla use it correctly.

Comment 9

[:Gavin Sharp [email: [e-mail]]]

Attachment: Patch

Like this?

Comment 10

[:Gavin Sharp [email: [e-mail]]]

Attachment: Patch for chatzilla

And for Chatzilla...

Comment 11

[James Ross]

It is not exactly an /internal/ function, but yes, the problem is simply its
lack of override on the referrer.

Comment 12

[James Ross]

Comment on attachment 176527 [details] [diff] [review]
Patch for chatzilla

>Index: extensions/irc/xul/content/commands.js
>         if (client.host == "Mozilla") {
>-            window.openNewTabWith(e.url, false, false);
>+            window.openNewTabWith(e.url, false, false, null, null, false);

Why did you change this? Mozilla's version of the function is this:
  openNewTabWith(url, sendReferrer, reverseBackgroundPref)

Comment 13

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #11)
> It is not exactly an /internal/ function

Right, internal was a bad word to use.

And after looking at it more, I assume that the first hunk of the Chatzilla
patch isn't necessary.

Comment 14

[:Gavin Sharp [email: [e-mail]]]

Attachment: Patch for chatzilla (Checked in)

Thanks for pointing that out, James.

Comment 15

[James Ross]

Comment on attachment 176529 [details] [diff] [review]
Patch for chatzilla (Checked in)

r=[e-mail]

Looks good to me, just need the Firefox half in.

Comment 16

[:Gavin Sharp [email: [e-mail]]]

Attachment: Patch v2

Modified patch per comments from mconnor.

Comment 17

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 176529 [details] [diff] [review]
Patch for chatzilla (Checked in)

The argument needs to be true now, not false.

Comment 18

[:Gavin Sharp [email: [e-mail]]]

Attachment: Patch v3

Comment 19

[:Gavin Sharp [email: [e-mail]]]

The last patch should use "document", not "doc", but otherwise should work.

4 broken patches in 1.5 hours might be my record.

Comment 20

[:Gavin Sharp [email: [e-mail]]]

Attachment: Patch v4 (checked in)

Comment 21

[Asaf Romano (gone)]

I checked in the Firefox part:
Checking in contentAreaUtils.js;
/cvsroot/mozilla/browser/base/content/contentAreaUtils.js,v  <-- 
contentAreaUtils.js
new revision: 1.65; previous revision: 1.64
done

please close as fixed if the chatzilla part is in.

Comment 22

[Ian Neal]

Comment on attachment 176529 [details] [diff] [review]
Patch for chatzilla (Checked in)

Checking in commands.js;
/cvsroot/mozilla/extensions/irc/xul/content/commands.js,v  <--	commands.js
new revision: 1.60; previous revision: 1.59
done

Comment 23

[:Gavin Sharp [email: [e-mail]]]

Marking fixed, can someone verify?