(Regression) Data leak: HTTP-Referer sent when it should not be sent

RESOLVED WORKSFORME

Status

()

defect
P5
normal
RESOLVED WORKSFORME
6 years ago
a month ago

People

(Reporter: karl156, Unassigned)

Tracking

({regression})

19 Branch
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Firefox/17.0
Build ID: 20130201065344

Steps to reproduce:

Using defaultView.location.href = xy from chrome code previously did not generate any HTTP-Referer. Now a referrer is sent, leaking private information.

Last working: Firefox 18.0.2
First broken: Firefox 19.0

Updated

6 years ago
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
Can you please provide a complete testcase or detailed Steps to reproduce ?
Flags: needinfo?(karl156)
(Reporter)

Comment 2

6 years ago
Sorry, no testcase.

In browser.xul when an event is fired, use
"event.target.defaultView.location.href = newurl;"

In Firefox 18.0.2 and older no referrer is sent.
In Firefox 19.0 a referrer of the currently loaded document is sent.

The extension using that code is navigating to a completely unrelated website. So having a referrer is a major information leak.
Flags: needinfo?(karl156)
(Reporter)

Comment 3

6 years ago
At least this change was not backported to 17.0.3esr, so using this is an alternative without security risk.
(Reporter)

Comment 4

6 years ago
Last good nightly: 2012-11-08
First bad nightly: 2012-11-09

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=36e99ea02c05&tochange=90cea19e27e2

Comment 5

6 years ago
My guess goes to suspected bug:
Bobby Holley — Bug 809290 - Fix nsLocation::CheckURL. r=bz
I guess that this is from bug 809290
Blocks: 809290
Component: Networking: HTTP → DOM
Hmm.  Why is touching location from chrome ending up with a content script entry point?  Bobby, is this Location weirdness?
Flags: needinfo?(bobbyholley+bmo)
Flags: needinfo?(bobbyholley+bmo)
(In reply to Boris Zbarsky (:bz) from comment #7)
> Hmm.  Why is touching location from chrome ending up with a content script
> entry point?  Bobby, is this Location weirdness?

It's not really clear to me what the issue in this bug is. My guess is that the content script might actually be the script entry point here. In particular, if the content somehow calls into an addon, and the addon navigates another page, then the original page would appear as the script entry point. It's not totally clear to me how we'd fix that.

karl, is that the issue you're seeing? If not, it'd be helpful if you could play with the attached testcase boilerplate to make it reproduce the issue.
Flags: needinfo?(karl156)
(Reporter)

Comment 10

6 years ago
I wrote a minimalistic extension to reproduce this issue. Looks like it is a bit more complicated than I originally thought. It is all chrome code, but I think setTimeout triggers the script entry point you meant.

Is there any workaround to navigate to another page inside the setTimeout without sending a referrer?
Flags: needinfo?(karl156)
Attachment #722224 - Attachment mime type: application/octet-stream → application/zip
> Is there any workaround

Use window.setTimeout instead of safeWin.setTimeout?  Or is there a particular reason safeWin.setTimeout is being used?
Note that chances are bug 810644 would also fix this, by the way.
(In reply to Boris Zbarsky (:bz) from comment #11)
> > Is there any workaround
> 
> Use window.setTimeout instead of safeWin.setTimeout?  Or is there a
> particular reason safeWin.setTimeout is being used?

Yes, it sounds like that would cause this.

(In reply to Boris Zbarsky (:bz) from comment #12)
> Note that chances are bug 810644 would also fix this, by the way.

Can you explain? Will setTimeout cause us to push the right cx?

In general, it's not clear to me if there's anything we can do for the general case of code calling through an addon to a cross-origin frame. I'm open to suggestions, though.
> Can you explain? Will setTimeout cause us to push the right cx?

WebIDL callbacks run on the cx of the callee, which in this case would be the chrome function.
(Reporter)

Comment 15

6 years ago
(In reply to Boris Zbarsky (:bz) from comment #11)
> > Is there any workaround
> 
> Use window.setTimeout instead of safeWin.setTimeout?  Or is there a
> particular reason safeWin.setTimeout is being used?

I think this could be used on all events to change the script entry point back to chrome. So this sounds like a good workaround for everything.

function navigateWithoutReferrer(url)
{
 browserWin.setTimeout(function(){safeWin.location.href = url;},0);
}
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5

Boris, can this be closed? It sounds like you expected WebIDLization of setTimeout to fix this issue.

Flags: needinfo?(bzbarsky)

I did, but that code is ... complicated. At the very least, this needs to be retested.

That said, I just tested with the following steps:

  1. Start a brand-new nightly.
  2. Open about:config
  3. Toggle "devtools.debugger.remote-enabled" to true.
  4. Toggle "devtools.chrome.enabled" to true.
  5. Load http://example.com.
  6. Open the browser content toolbox.
  7. Evaluate:
tabs[0].content.setTimeout(function() { tabs[0].content.location.href = 'http://software.hixie.ch/utilities/cgi/test-tools/echo'; }, 1000)

The resulting page shows no referrer header being sent. So looks good.

For the sake of comparison, if instead I evaluate:

tabs[0].content.setTimeout("location.href = 'http://software.hixie.ch/utilities/cgi/test-tools/echo';", 1000)

then I do get HTTP_REFERER = http://example.com/ in the echo output.

Status: UNCONFIRMED → RESOLVED
Last Resolved: a month ago
Flags: needinfo?(bzbarsky)
Resolution: --- → WORKSFORME
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.