The default bug view has changed. See this FAQ.
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)

VERIFIED FIXED in mozilla1.0.2

Status

()

Core
Document Navigation
P1
critical
VERIFIED FIXED
15 years ago
12 years ago

People

(Reporter: Mappy, Assigned: rpotts (gone))

Tracking

({privacy, topembed+})

Trunk
mozilla1.0.2
privacy, topembed+
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt1] [ETA 09/19])

Attachments

(2 attachments)

(Reporter)

Description

15 years ago
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

15 years ago
-> docshell
Assignee: darin → adamlock
Component: Networking: HTTP → Embedding: Docshell
QA Contact: tever → adamlock

Comment 2

15 years ago
-> Rick
Assignee: adamlock → rpotts

Comment 3

15 years ago
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

15 years ago
This bug seems to be platform independent.
OS: Windows 98 → All
Hardware: PC → All

Updated

15 years ago
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
(Reporter)

Updated

15 years ago
Blocks: 61660

Comment 6

15 years ago
Yup, serious. There might be other fun ways to exploit this, e.g. in mail.
Blocks: 54184
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

Comment 8

15 years ago
This has been reported open and was open for 2 months, please keep it that way.

Comment 9

15 years ago
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

15 years ago
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

15 years ago
Demonstration URL:

http://members.ping.de/~sven/mozbug/refcook.html
Keywords: nsbeta1 → nsbeta1+

Updated

15 years ago
Keywords: topembed
Whiteboard: [adt1] [ETA Needed]

Comment 12

15 years ago
Publicly known (http://mozillazine.org/talkback.html?article=2467), removing 
security-sensitive flag.
Group: security?

Comment 13

15 years ago
1.0.1 is out the door. moving to 1.0.2
Target Milestone: mozilla1.0.1 → mozilla1.0.2

Updated

15 years ago
Target Milestone: mozilla1.0.2 → mozilla1.0.1
Blocks: 168066

Comment 14

15 years ago
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

Comment 15

15 years ago
Bug does not exist in Beonex Communicator's default config, removing dep.
No longer blocks: 54184
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

15 years ago
> 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.

Comment 19

15 years ago
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

15 years ago
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

15 years ago
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

15 years ago
testcase: http://www.script-source.net/km/moz_referer_bug/

Comment 23

15 years ago
testcase: http://www.script-source.net/km/moz_referer_bug/
(Assignee)

Comment 24

15 years ago
Created attachment 99468 [details] [diff] [review]
patch to explicitly provide a referring URI when loading images...

Comment 25

15 years ago
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

15 years ago
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+

Updated

15 years ago
Blocks: 163993
(Assignee)

Comment 28

15 years ago
patch is checked into the trunk...

branch patch to follow :-)

-- rick

(Assignee)

Comment 29

15 years ago
Created attachment 99565 [details] [diff] [review]
same patch for the MOZILLA_1_0 branch...

Comment 30

15 years ago
Comment on attachment 99565 [details] [diff] [review]
same patch for the MOZILLA_1_0 branch...

r/sr=darin
Attachment #99565 - Flags: review+

Comment 31

15 years ago
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]

Comment 32

15 years ago
 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+

Updated

15 years ago
Attachment #99565 - Flags: superreview+
Comment on attachment 99565 [details] [diff] [review]
same patch for the MOZILLA_1_0 branch...

r/sr=jst
(Assignee)

Comment 34

15 years ago
checked into the MOZILLA_1_0 branch.

adding the fixed1.0.2 keyword ;-)
Keywords: fixed1.0.2
(Assignee)

Comment 35

15 years ago
removing mozilla1.0.2+ and marking fixed...

-- rick
Keywords: mozilla1.0.2+

Comment 36

15 years ago
Doing what rpotts intended. My pleasure :-)
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.0.2 → ---

Comment 37

15 years ago
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

Comment 38

15 years ago
Verifying fixed in 1.0.2.
Status: RESOLVED → VERIFIED
Keywords: fixed1.0.2 → verified1.0.2

Comment 39

15 years ago
posthumus adt1.0.2+.
Keywords: adt1.0.2 → adt1.0.2+

Comment 40

15 years ago
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).

Comment 42

15 years ago
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?

Updated

12 years ago
No longer blocks: 163993
You need to log in before you can comment on or make changes to this bug.