Closed Bug 226548 Opened 17 years ago Closed 15 years ago
_referer sent when middle-clicking link from sidebar
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.
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
Jesse, 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
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.
17 years ago
Priority: -- → P2
Target Milestone: --- → Firefox1.0beta
Flags: blocking1.0? → blocking1.0+
16 years ago
Assignee: noririty → varga
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. blocking-aviary1.1?
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?
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
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.
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 on attachment 186456 [details] [diff] [review] patch r=dveditz
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
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.
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.