Current referer sent when pressing shift-enter in location field

RESOLVED FIXED in seamonkey1.0alpha

Status

P1
normal
RESOLVED FIXED
15 years ago
11 years ago

People

(Reporter: bugzilla.mozilla-sp, Assigned: Biesinger)

Tracking

({privacy})

Trunk
seamonkey1.0alpha
privacy
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:nse])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040704 Debian/1.4-2 StumbleUpon/1.76
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040704 Debian/1.4-2 StumbleUpon/1.76

Mozilla sends the last URL that was generated by the sidebar as Referer when
entering another URL in the location field and pressing Shift-Enter (for download).

Reproducible: Always
Steps to Reproduce:
1. Open sidebar
2. Use google-search in sidebar, look for "testing"
3. Type http://server.whose.access.log.i.can.read/foobar in the location field
and press shift-enter

Actual Results:  
access.log on the server: Referer will be set to
"http://www.google.com/search?q=testing&sourceid=mozilla&start=0&start=0&ie=utf-8&oe=utf-8"

Expected Results:  
Referer should have been empty
(Reporter)

Comment 1

15 years ago
I also have seen this bug when using
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko
/20040803
so it's not Linux- or Debian- related, I guess.
Keywords: privacy
> Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803

did you install any extensions on that build?
(Reporter)

Comment 3

15 years ago
No extensions were installed on the Windows-build at that time.
Privacy issue, but not an exploit: clearing security flag.

Has nothing to do with sidebar, it appears to be whatever happens to be in the
content window is sent when you shift-enter (download/save) the location bar
url. It should not send the referrer, just as we don't if you type into the
location bar and load it into the browser window.

Could be embarassing :-)

0[263f18]: http request [
0[263f18]:   HEAD / HTTP/1.1
0[263f18]:   Host: www.mozilla.org
...
0[263f18]:   Referer:
http://www.google.com/search?hl=en&ie=UTF-8&q=bedwetting&btnG=Google+Search
0[263f18]: ]
Group: security
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: sidebar-URL is sent as referer when pressing shift-enter in location field → Current referer sent when pressing shift-enter in location field
Whiteboard: [sg:nse]
This might explain why I get a lot of bogus referrers from Firefox UAs on my
blog, although I don't understand why people would be saving my page...
this is entirely in frontend code, fixing component. taking, but I'll wait with
fixing this until bug 160454 gets checked in, which is rewriting the involved code.

see the unchecked usages of getReferrer in contentAreaUtils.js for the involved
code.

this could be called a regression, because for a while we sent no referrer...
Assignee: darin → cbiesinger
Component: Networking: HTTP → XP Apps: GUI Features
OS: Linux → All
Hardware: PC → All

Updated

15 years ago
QA Contact: core.networking.http → nobody
Posted patch patch (obsolete) — Splinter Review
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.8alpha5
Attachment #163321 - Flags: superreview?(bzbarsky)
Attachment #163321 - Flags: review?(neil.parkwaycc.co.uk)
Comment on attachment 163321 [details] [diff] [review]
patch

so, why are you putting aReferrer before aChosenData when we're not actually
using aChosenData yet?
neil: hm, no real reason. I can change it if you want (I'd prefer not to add a
new patch just to switch the order of the two params, though)
Comment on attachment 163321 [details] [diff] [review]
patch

>+  var referrer = null;
>+  if (aDocument.referrer)
>+    referrer = makeURI(aDocument.referrer, aDocument.characterSet);
>+
>   if (aDocument)
Need to null check aDocument more here.

I noticed a couple of places where you could have used makeURI.
Comment on attachment 163321 [details] [diff] [review]
patch

Cancelling due to bitrot.
Attachment #163321 - Flags: superreview?(bzbarsky)
Attachment #163321 - Flags: review?(neil.parkwaycc.co.uk)
Product: Core → Mozilla Application Suite
(for my reference: bug 239472)
Priority: -- → P1
Posted patch updated patchSplinter Review
Attachment #163321 - Attachment is obsolete: true
Attachment #181720 - Flags: review?(neil.parkwaycc.co.uk)
Target Milestone: mozilla1.8alpha5 → Seamonkey1.0alpha
Comment on attachment 181720 [details] [diff] [review]
updated patch

What about the changes to pageInfo.js saveMedia() and contentAreaUtils.js
getReferrer() [note that the old change looks inaccurate] and saveDocument()
[which was also incorrect]?

>+          saveURL(href, linkNode ? gatherTextUnder(linkNode) : "",
>+                  "SaveLinkTitle", false, getReferrer(document));
Sorry that I missed this in the previous review, but "false" is not documented
as a legal value for aChosenData. I told you you should have put aReferrer
first :-P
(In reply to comment #14)
> (From update of attachment 181720 [details] [diff] [review] [edit])
> What about the changes to pageInfo.js saveMedia() and contentAreaUtils.js
> getReferrer() [note that the old change looks inaccurate] and saveDocument()
> [which was also incorrect]?

pageInfo now does pass a referrer (bug 239472)

contentAreaUtils.js - you mean the charset passing? how does it look incorrect?

> Sorry that I missed this in the previous review, but "false" is not documented
> as a legal value for aChosenData. I told you you should have put aReferrer
> first :-P

That's not untrue, but saveURL does not have an aChosenData argument?
http://lxr.mozilla.org/seamonkey/source/xpfe/communicator/resources/content/contentAreaUtils.js#219

Comment on attachment 181720 [details] [diff] [review]
updated patch

OK, so you lost the getReferrer() charset change, but I don't think that was
correct anyway. Note to self: do reviews during daylight hours!
Attachment #181720 - Flags: review?(neil.parkwaycc.co.uk) → review+
Attachment #181720 - Flags: superreview?(jag)

Updated

14 years ago
Attachment #181720 - Flags: superreview?(jag) → superreview+
Comment on attachment 181720 [details] [diff] [review]
updated patch

fixes a privacy problem, only affects seamonkey
Attachment #181720 - Flags: approval1.8b2?
Comment on attachment 181720 [details] [diff] [review]
updated patch

a=dveditz
Attachment #181720 - Flags: approval1.8b2? → approval1.8b2+
Checking in xpfe/communicator/resources/content/contentAreaClick.js;
/cvsroot/mozilla/xpfe/communicator/resources/content/contentAreaClick.js,v  <--
 contentAreaClick.js
new revision: 1.44; previous revision: 1.43
done
Checking in xpfe/communicator/resources/content/contentAreaUtils.js;
/cvsroot/mozilla/xpfe/communicator/resources/content/contentAreaUtils.js,v  <--
 contentAreaUtils.js
new revision: 1.129; previous revision: 1.128
done
Checking in xpfe/communicator/resources/content/nsContextMenu.js;
/cvsroot/mozilla/xpfe/communicator/resources/content/nsContextMenu.js,v  <-- 
nsContextMenu.js
new revision: 1.101; previous revision: 1.100
done
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Updated

11 years ago
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.