Last Comment Bug 145579 - (future_referer) Website can see url of page visited after it (document referer used when loading images with javascript is incorrect while loading a new page)
(future_referer)
: Website can see url of page visited after it (document referer used when load...
Status: VERIFIED FIXED
[adt1] [ETA 09/19]
: privacy, topembed+
Product: Core
Classification: Components
Component: Document Navigation (show other bugs)
: Trunk
: All All
: P1 critical with 17 votes (vote)
: mozilla1.0.2
Assigned To: rpotts (gone)
: Adam Lock
: Andrew Overholt [:overholt]
Mentors:
Depends on:
Blocks: referer 1.2b
  Show dependency treegraph
 
Reported: 2002-05-19 05:03 PDT by Mappy
Modified: 2005-05-26 10:49 PDT (History)
88 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch to explicitly provide a referring URI when loading images... (13.90 KB, patch)
2002-09-16 21:46 PDT, rpotts (gone)
jst: review+
darin.moz: superreview+
Details | Diff | Splinter Review
same patch for the MOZILLA_1_0 branch... (14.00 KB, patch)
2002-09-17 14:56 PDT, rpotts (gone)
darin.moz: review+
jst: superreview+
Details | Diff | Splinter Review

Description Mappy 2002-05-19 05:03:08 PDT
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'
Comment 1 Darin Fisher 2002-05-20 09:53:49 PDT
-> docshell
Comment 2 Adam Lock 2002-05-20 12:42:53 PDT
-> Rick
Comment 3 Sven Neuhaus 2002-06-07 05:03:22 PDT
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.
Comment 4 Sven Neuhaus 2002-06-07 05:11:05 PDT
This bug seems to be platform independent.
Comment 5 Daniel Glazman (:glazou) 2002-06-12 03:03:56 PDT
Raising radar indicators for this bug ; yes we have a privacy issue here.
Comment 6 Ben Bucksch (:BenB) 2002-06-12 07:12:20 PDT
Yup, serious. There might be other fun ways to exploit this, e.g. in mail.
Comment 7 Mitchell Stoltz (not reading bugmail) 2002-08-07 11:02:48 PDT
Adding nsbeta1 - let's get this fixed before our (Netscape's) next release.
Adding security-sensitive flag.
Comment 8 Ben Bucksch (:BenB) 2002-08-07 11:11:23 PDT
This has been reported open and was open for 2 months, please keep it that way.
Comment 9 Jesse Ruderman 2002-08-16 13:53:15 PDT
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.
Comment 10 Sven Neuhaus 2002-08-27 01:28:03 PDT
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...
Comment 11 Sven Neuhaus 2002-09-11 06:55:17 PDT
Demonstration URL:

http://members.ping.de/~sven/mozbug/refcook.html
Comment 12 Jesse Ruderman 2002-09-14 13:32:37 PDT
Publicly known (http://mozillazine.org/talkback.html?article=2467), removing 
security-sensitive flag.
Comment 13 Mike Young 2002-09-14 13:45:23 PDT
1.0.1 is out the door. moving to 1.0.2
Comment 14 Sven Neuhaus 2002-09-14 17:13:16 PDT
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.
Comment 15 Ben Bucksch (:BenB) 2002-09-14 17:19:25 PDT
Bug does not exist in Beonex Communicator's default config, removing dep.
Comment 16 David Baron :dbaron: ⌚️UTC-8 2002-09-15 19:39:31 PDT
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).)
Comment 17 Jesse Ruderman 2002-09-15 21:00:38 PDT
> 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).
Comment 18 Henri Sivonen (:hsivonen) 2002-09-16 00:21:23 PDT
user_pref("network.http.sendRefererHeader", 0); 
seems to be a valid workaround.
Comment 19 John A. 2002-09-16 09:07:39 PDT
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!
Comment 20 David G King 2002-09-16 09:41:40 PDT
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.
Comment 21 Jason Chambers 2002-09-16 19:59:23 PDT
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?
Comment 22 Rob Johnson 2002-09-16 20:24:28 PDT
testcase: http://www.script-source.net/km/moz_referer_bug/
Comment 23 Rob Johnson 2002-09-16 20:33:08 PDT
testcase: http://www.script-source.net/km/moz_referer_bug/
Comment 24 rpotts (gone) 2002-09-16 21:46:47 PDT
Created attachment 99468 [details] [diff] [review]
patch to explicitly provide a referring URI when loading images...
Comment 25 Jacek Piskozub 2002-09-16 21:58:31 PDT
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 26 Darin Fisher 2002-09-16 22:15:49 PDT
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 ;)
Comment 27 Johnny Stenback (:jst, jst@mozilla.com) 2002-09-16 22:26:28 PDT
Comment on attachment 99468 [details] [diff] [review]
patch to explicitly provide a referring URI when loading images...

r/sr=jst
Comment 28 rpotts (gone) 2002-09-17 12:09:56 PDT
patch is checked into the trunk...

branch patch to follow :-)

-- rick

Comment 29 rpotts (gone) 2002-09-17 14:56:32 PDT
Created attachment 99565 [details] [diff] [review]
same patch for the MOZILLA_1_0 branch...
Comment 30 Darin Fisher 2002-09-17 15:03:39 PDT
Comment on attachment 99565 [details] [diff] [review]
same patch for the MOZILLA_1_0 branch...

r/sr=darin
Comment 31 Jaime Rodriguez, Jr. 2002-09-17 15:51:08 PDT
Nominating as adt1.0.2 and mozilla1.0.2 for inclusion on the 1.0 branch.
Comment 32 Judson Valeski 2002-09-17 16:02:39 PDT
 please checkin to the MOZILLA_1_0_BRANCH branch. once there, remove the
"mozilla1.0.2+" keyword and add the "fixed1.0.2" keyword. 
Comment 33 Johnny Stenback (:jst, jst@mozilla.com) 2002-09-17 16:19:21 PDT
Comment on attachment 99565 [details] [diff] [review]
same patch for the MOZILLA_1_0 branch...

r/sr=jst
Comment 34 rpotts (gone) 2002-09-17 17:27:39 PDT
checked into the MOZILLA_1_0 branch.

adding the fixed1.0.2 keyword ;-)
Comment 35 rpotts (gone) 2002-09-17 19:02:38 PDT
removing mozilla1.0.2+ and marking fixed...

-- rick
Comment 36 Jacek Piskozub 2002-09-17 19:24:54 PDT
Doing what rpotts intended. My pleasure :-)
Comment 37 Jaime Rodriguez, Jr. 2002-09-17 20:01:01 PDT
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?
Comment 38 Adam Lock 2002-09-19 09:21:18 PDT
Verifying fixed in 1.0.2.
Comment 39 Jaime Rodriguez, Jr. 2002-09-19 23:25:49 PDT
posthumus adt1.0.2+.
Comment 40 Sven Neuhaus 2002-09-23 02:48:21 PDT
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?
Comment 41 Heikki Toivonen (remove -bugzilla when emailing directly) 2002-09-23 10:38:50 PDT
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).
Comment 42 Sven Neuhaus 2002-09-23 14:53:17 PDT
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?

Note You need to log in before you can comment on or make changes to this bug.