Closed Bug 145579 (future_referer) Opened 22 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: