Closed Bug 145579 (future_referer) Opened 23 years ago Closed 22 years ago

Website can see url of page visited after it (document referer used when loading images with javascript is incorrect while loading a new page)

Categories

(Core :: DOM: Navigation, defect, P1)

Product:
Core
Component:
DOM: Navigation
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0.2

People

(Reporter: bugzilla, Assigned: rpotts)

References

Details

(Keywords: privacy, topembed+, Whiteboard: [adt1] [ETA 09/19])

Attachments

(2 files)

patch to explicitly provide a referring URI when loading images...
(deleted), patch
jst
: review+
darin.moz
: superreview+
Details | Diff | Splinter Review
same patch for the MOZILLA_1_0 branch...
(deleted), patch
darin.moz
: review+
jst
: superreview+
Details | Diff | Splinter Review
If a new url is entered into the address bar (and enter or go is pressed) the browser starts to look up this address. When a javascript script loads a new image by a setTimeout-triggered event on the current page while the browser is looking up the new address, the image has a document referer of http://new page/ instead of http://current page/ Reproducable: always, easier on slow connections or when the server on the other end is down. Platform/OS/build: tested on PC/win98/1.0rc2 Refers to: bug 61660 --- code example: <html> <head> <script type="text/javascript"> function load_image { document.images["bla"].src="bla2.jpg"; } </script> </head> <body onload="setTimeout('load_image()',10000)"> <img name="bla" src="bla.jpg"> </body> </html> For bla2.jpg I used a php-generated image that shows the document referer as the image. --- How to reproduce using the above code and by replacing bla2 with an image that shows the document referer: - load the html page - within the 10 second timeout enter a new url (preferably an unreachable server that would cause a timeout) in your address bar and press enter - while Mozilla tries to load the new url the javascript is triggered - the javascript loads bla2.jpg using 'new url' as a document referer. - Mozilla gives an error: 'new url' not reachable (or if you used a server that does work it continues loading 'new url'
-> docshell
Assignee: darin → adamlock
Component: Networking: HTTP → Embedding: Docshell
QA Contact: tever → adamlock
-> Rick
Assignee: adamlock → rpotts
This is a SERIOUS PRIVACY ISSUE. It is also (reliably!) triggered on pages that load images using the window.onunload handler. This bug lets a webmaster find out what page you visited next (including pages who's URLs were entered manually). I.e.: Add a window.onunload handler to the page. Your handler loads an image. The referer for the image in your access_log will be the NEW page that gets loaded over the current one!! example for handler that loads an image on unload: ======================================8<========================== <script> function good_bye() { var x = new Image(); x.src="pixel.gif"; } window.onunload = good_bye; </script> ======================================8<========================== When you visit this page, then go to another URL your HTTP server log will show the request for "pixel.gif" with the referer of the other URL you visited after this page. I noticed this bug when I looked in my http server logfile. The user visiting was using mozilla 1.0 I reproduced the bug with galeon 1.2.3 (mozilla 1.0rc3) on Linux - I don't have mozilla 1.0 installed yet because of galeon issues. FWIW, MS IE 6.0 doesn't seem to have this bug. Please get this bug fixed before 1.0.1 ships.
This bug seems to be platform independent.
OS: Windows 98 → All
Hardware: PC → All
Severity: normal → critical
Raising radar indicators for this bug ; yes we have a privacy issue here.
Keywords: nsbranch, privacy
Priority: -- → P1
Target Milestone: --- → mozilla1.0.1
Blocks: 61660
Yup, serious. There might be other fun ways to exploit this, e.g. in mail.
Blocks: Beonex
Summary: document referer used when loading images with javascript is incorrect while loading a new page → Website can see url of page visited after it (document referer used when loading images with javascript is incorrect while loading a new page)
Adding nsbeta1 - let's get this fixed before our (Netscape's) next release. Adding security-sensitive flag.
Group: security?
Keywords: nsbeta1
This has been reported open and was open for 2 months, please keep it that way.
See also: bug 79840 document.referrer is incorrect in a situation that involves frames bug 84749 [FIXED] onUnload JavaScript gets wrong value for location.href bug 141274 If I navigate away from my webpage before it loads, the page I'm going to comes up in the referrer list in my site stats.
This bug is still present in the Mozilla 1.1 release :-( I think I will make this bug public by the end of the week. hopefully that will get it fixed. It's been 3 months...
Keywords: topembed
Whiteboard: [adt1] [ETA Needed]
Publicly known (http://mozillazine.org/talkback.html?article=2467), removing security-sensitive flag.
Group: security?
1.0.1 is out the door. moving to 1.0.2
Target Milestone: mozilla1.0.1 → mozilla1.0.2
Target Milestone: mozilla1.0.2 → mozilla1.0.1
Blocks: 1.2b
I found a good workaround in a comment at Mozillazine: Add the line user_pref("capability.policy.default.Window.onunload", "noAccess"); to your user.js file. For information about the user.js file, read the documentation at http://www.mozilla.org/start/1.0/faq/general.html#1.5 Other workaround: use a proxy that filters the http referer header.
Alias: future_referer
Target Milestone: mozilla1.0.1 → mozilla1.0.2
Bug does not exist in Beonex Communicator's default config, removing dep.
No longer blocks: Beonex
It seems the problem is that imgLoader::LoadImage uses the load group as the source for the Referer, but nsDocShell recycles the same load group for all the documents loaded in a given docshell. (Is the document URL really the correct thing to send as the referrer if the image is loaded from script that lives in a separate file? Shouldn't we send the URL of the script? The HTTP spec (RFC 2616) says the referer should be "the address (URI) of the resource from which the Request-URI was obtained". We probably have the same bug with stylesheets (and probably others, for imported stylesheets).)
> Is the document URL really the correct thing to send as the referrer if the > image is loaded from script that lives in a separate file? I think the document URL is the correct referrer for images loaded by scripts. It's often possible for a page to trick an external script into doing something it wasn't intended to do, so the page should take responsibility for whatever the script does. Someone looking at the page can figure out why it loaded a given image, while someone looking at just the script can't. If script urls were sent as referrers, site A could mask its referrer to site B by loading a script from site C and messing with the script (getters/setters, etc).
user_pref("network.http.sendRefererHeader", 0); seems to be a valid workaround.
As a commercial web site owner, I urge you to stress that the workaround listed in comment #14 is the preferred workaround. Where visitors go after they leave us is none of our business. Knowing who referred them to us helps us focus our advertising budget on people who are actually interested in our products, and bug the other folks less. :) Thanks!
As a follow-up to comment #19, is it possible to put the line in user.js as defined in Comment #14 as a temporary measure until a proper fix is implemented? By temp measure, I mean, put the patch in for tomorrows nightlies, and then fix it properly for 1.2b. I say this because it is a privacy issue, and even a temp fix would hold off any negative press.
I'm very surprised that this bug has been open for this long to be thwarted. Our last publicly announced bug < bug 141061 and http://www.mozillazine.org/talkback.html?article=2201 > only took 2 days to patch. What gives here?
The workaround from commant 14 does not work (checked with the testcase) as the pref is not registered (checked with the about:config). Probably adding it to all.js would work. However, the workaround from comment 19 does work when applied to user.js (testcase proven).
Comment on attachment 99468 [details] [diff] [review] patch to explicitly provide a referring URI when loading images... r/sr=darin this looks great. everything else that sets a referrer (e.g., CSS, JS, xmlHttpRequest) seem to likewise get the referrer from the document, but this should of course be double checked ;)
Attachment #99468 - Flags: superreview+
Comment on attachment 99468 [details] [diff] [review] patch to explicitly provide a referring URI when loading images... r/sr=jst
Attachment #99468 - Flags: review+
Blocks: majorbugs
patch is checked into the trunk... branch patch to follow :-) -- rick
Comment on attachment 99565 [details] [diff] [review] same patch for the MOZILLA_1_0 branch... r/sr=darin
Attachment #99565 - Flags: review+
Nominating as adt1.0.2 and mozilla1.0.2 for inclusion on the 1.0 branch.
Keywords: nsbranch, topembed → adt1.0.2, approval, mozilla1.0.2, topembed+
Whiteboard: [adt1] [ETA Needed] → [adt1] [ETA 09/19]
please checkin to the MOZILLA_1_0_BRANCH branch. once there, remove the "mozilla1.0.2+" keyword and add the "fixed1.0.2" keyword.
Keywords: mozilla1.0.2 → mozilla1.0.2+
Attachment #99565 - Flags: superreview+
Comment on attachment 99565 [details] [diff] [review] same patch for the MOZILLA_1_0 branch... r/sr=jst
checked into the MOZILLA_1_0 branch. adding the fixed1.0.2 keyword ;-)
Keywords: fixed1.0.2
removing mozilla1.0.2+ and marking fixed... -- rick
Keywords: mozilla1.0.2+
Doing what rpotts intended. My pleasure :-)
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.0.2 → ---
adamlock: can you pls verify this as fixed on the 1.0 branch, then replace "fixed1.0.2" with "verified1.0.2". thanks! is adam the right person for the QA Contact, and to be verifying this as fixed?
Target Milestone: --- → mozilla1.0.2
Verifying fixed in 1.0.2.
Status: RESOLVED → VERIFIED
Keywords: fixed1.0.2 → verified1.0.2
posthumus adt1.0.2+.
Keywords: adt1.0.2 → adt1.0.2+
I did some more testing as requested in Darin's commment 26 with a nightly build ("Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20020922"). Results: * CSS loaded by setting the href property of a HTMLLinkElement yields the correct referer. Yay! * A XMLHTTPRequest gets no referer at all (this is a bug, isn't it?) * Setting the src property of a HTMLScriptElement does not trigger a HTTP Request - what's the correct way to do this?
Sven, you need to create the whole script tag dynamically and attach it to the document (this was changed some time back to avoid multiple loads).
OK. Did that and it triggers a request. It seems the referer for the <script> was already ok in 1.1 (without the fix). Code used for testing: ... <HEAD ID="dh1"> ... <SCRIPT> function good_bye () { var sc = document.createElement("script"); sc.src="refcook.cgi"; document.getElementById("dh1").appendChild(sc); } window.onunload = good_bye; </SCRIPT> ... Is it worth it testing frames loading also perhaps?
No longer blocks: majorbugs
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: