226548 - Wrong http_referer sent when middle-clicking link from sidebar

Status: RESOLVED FIXED

(Firefox :: General, defect, P2)

Description

[Chris Nebergall ([e-mail])]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031121 Firebird/0.7+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031121 Firebird/0.7+

Firebird sends the wrong referrer when middle clicking a link in a web panel.

Reproducible: Always

Steps to Reproduce:
1.  Open a url
2.  Click on bookmark which has the "Load this bookmark in a sidebar" option checked
3. Middle click a link in the web panel window (A left click works correctly)
4. Select the tab where the page was loaded
5. Open Page Info


Actual Results:  
The the referrer is set to the main page, not the page in the web panel.

Expected Results:  
Send the referrer of the panel page, not the page in the main window.

Comment 1

[Ali Ebrahim]

This appears to be a dupe of bug 137342 (SeaMonkey). But I'm not sure if
Firebird inherits the SeaMonkey code for this or not. Hence, this may actually
be a valid bug in Firebird (separate from SeaMonkey).

Having said this, I can confirm this behaviour on Win32/Linux.

When following a link normally from the sidebar, the link shows no referer. When
opening in a new tab, it shows the wrong referer (from the other open tab).

Comment 2

[Ali Ebrahim]

Jesse,

Sorry I didn't realise that you set this to major. Am reverting back my change.
Sorry for bugspam.

Comment 3

[noririty]

The code seems forked from Seamonkey.
-> NEW

Comment 4

[Keith Devens]

Has there been any progress on this? I agree <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=137342#c2">with Garoo</a> that
this is a big privacy issue. I don't think the sidebar should send referer
headers at all.

Comment 5

[Ben Goodger (use ben at mozilla dot org for email)]

+ing. 

Comment 6

[Jan Varga [:janv]]

Attachment: hacky patch

This patch just describes the problem.

Comment 7

[Ben Goodger (use ben at mozilla dot org for email)]

How does this fix the bug?

Comment 8

[chris hofmann]

would need a good, well tested fix to take this for 1.0 at this point. 
renominate if one appears

Comment 9

[Jan Varga [:janv]]

The problem is that isContentFrame() returns false in getContentFrameURI()
then it returns URI of the main content window instead of the sidebar.
The patch should fix this special case, but it's not a general fix, it fixes
only this special case. At the time, I didn't spend too much time on this bug, I
just wanted to know what's happening there.

Comment 10

[u115577]

This bug could contribute to security problems.

If sidebar links send correct referer, bug 284627 and bug 294074 (cross-site
scripting and/or arbitrary code execution) may be prevented.

blocking-aviary1.1?

Comment 11

[Ava3ar]

mine says unknown referer

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050606 Firefox/1.0+

Comment 12

[Daniel Veditz [:dveditz]]

I'm not seeing the sidebar send referrer in 1.0.4 or trunk. WFM? Can anyone
reproduce, and if so how?

Comment 13

[Christopher Nebergall]

I can still reproduce this on firefox trunk builds.  I built a binary from the
trunk a few days ago. The steps to reproduce still work.  The referrer is either
equal to the first tab, or NULL.  Null happens when one of the sites is SSL or
you left click rather than middle click. Only middle clicking seems to send a
referrer.
 
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050605 

Comment 14

[Mike Connor [:mconnor]]

plussing to investigate, I think I know where this breaks based on the last comment

Comment 15

[Daniel Veditz [:dveditz]]

I was seeing no referrer sent because my initial page was bugzilla (d'oh!). If
the tab is showing a non-ssl page then when I open a link in a new tab I do get
the initial content page as the referrer rather than the panel's URI. Doesn't
matter if I Ctrl-click, middle-click, or use the context menu.

If I left-click then I get no referrer regardless of whether the content page
being replaced is SSL or not.

Arguments could be made for sending no referrer (sidebar panels are an extension
of bookmarks, which send no referrer), or for sending the panel's URI (if it's
http only; never for https:, file:, or anything else as usual) because some
sites might require it. I don't care personally as long as both click and
ctrl-click do the same thing, and neither sends the incorrect referrer from the
open content page.

This isn't going to block a 1.0.5 release (minor privacy leak, easily worked
around by opening a blank tab first) but we'd probably approve a safe patch.

Comment 16

[Mike Connor [:mconnor]]

Attachment: patch

gets location.href from the linkNode's ownerDocument in the same way as we do
for the sidebar security checks.  This should be safe without the wrappers now,
iiuc.

Comment 17

[Daniel Veditz [:dveditz]]

Comment on attachment 186456 [details] [diff] [review]
patch

r=dveditz

Comment 18

[Jesse Ruderman]

I fixed this bug without knowing it when I fixed bug 303181 :)

Comment 19

[Jesse Ruderman]

This was fixed on trunk and 1.8 in bug 303181.  I'm not sure what I should do
with the blocking-aviary1.0.7 nomination.