Closed Bug 226548 Opened 17 years ago Closed 15 years ago

Wrong http_referer sent when middle-clicking link from sidebar


(Firefox :: General, defect, P2)






(Reporter: ct-nebergall, Assigned: jruderman)



(Keywords: fixed1.8, privacy)


(2 obsolete files)

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.
Severity: normal → major
Keywords: privacy
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).
Severity: major → normal
OS: Windows XP → All
Hardware: PC → All
Summary: Wrong Referrer sent when middle clicking link in web panel → Wrong http_referer sent when following link from sidebar

Sorry I didn't realise that you set this to major. Am reverting back my change.
Sorry for bugspam.
Severity: normal → major
The code seems forked from Seamonkey.
-> NEW
Assignee: blake → noririty
Depends on: 137342
Ever confirmed: true
Has there been any progress on this? I agree <a
href="">with Garoo</a> that
this is a big privacy issue. I don't think the sidebar should send referer
headers at all.
Priority: -- → P2
Target Milestone: --- → Firefox1.0beta
Blocks: referer
Flags: blocking1.0?
Flags: blocking1.0? → blocking1.0+
Assignee: noririty → varga
Attached patch hacky patch (obsolete) — Splinter Review
This patch just describes the problem.
How does this fix the bug?
would need a good, well tested fix to take this for 1.0 at this point. 
renominate if one appears
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
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.
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.

Flags: blocking-aviary1.1?
Flags: blocking-aviary1.0.5?
Target Milestone: Firefox1.0beta → ---
Version: unspecified → Trunk
mine says unknown referer

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050606 Firefox/1.0+
I'm not seeing the sidebar send referrer in 1.0.4 or trunk. WFM? Can anyone
reproduce, and if so how?
Whiteboard: wfm?
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
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050605 
plussing to investigate, I think I know where this breaks based on the last comment
Assignee: jan → mconnor
Flags: blocking-aviary1.1? → blocking-aviary1.1+
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.
Flags: blocking-aviary1.0.6?
Flags: blocking-aviary1.0.5?
Flags: blocking-aviary1.0.5-
Whiteboard: wfm?
Attached patch patch (obsolete) — Splinter Review
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,
Attachment #152948 - Attachment is obsolete: true
Attachment #186456 - Flags: review?(dveditz)
Comment on attachment 186456 [details] [diff] [review]

Attachment #186456 - Flags: review?(dveditz) → review+
I fixed this bug without knowing it when I fixed bug 303181 :)
Assignee: mconnor → jruderman
Summary: Wrong http_referer sent when following link from sidebar → Wrong http_referer sent when middle-clicking link from sidebar
Attachment #186456 - Attachment is obsolete: true
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.
Closed: 15 years ago
Depends on: 303181
Keywords: fixed1.8
Resolution: --- → FIXED
Flags: blocking-aviary1.0.8? → blocking-aviary1.0.8-
You need to log in before you can comment on or make changes to this bug.