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

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect, P5)

Description

[karl155]

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

Comment 1

[Matthias Versen [:Matti]]

Can you please provide a complete testcase or detailed Steps to reproduce ?

Comment 2

[karl155]

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.

Comment 3

[karl155]

At least this change was not backported to 17.0.3esr, so using this is an alternative without security risk.

Comment 4

[karl155]

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

[Loic]

My guess goes to suspected bug:
Bobby Holley — Bug 809290 - Fix nsLocation::CheckURL. r=bz

Comment 6

[Matthias Versen [:Matti]]

I guess that this is from bug 809290

Comment 7

[Boris Zbarsky [:bzbarsky]]

Hmm.  Why is touching location from chrome ending up with a content script entry point?  Bobby, is this Location weirdness?

Comment 8

[Bobby Holley (:bholley)]

Attachment: Test boilerplate. Doesn't reproduce the issue.

Comment 9

[Bobby Holley (:bholley)]

(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.

Comment 10

[karl155]

Attachment: Minimalistic testcase to reproduce the issue

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?

Comment 11

[Boris Zbarsky [:bzbarsky]]

> Is there any workaround

Use window.setTimeout instead of safeWin.setTimeout?  Or is there a particular reason safeWin.setTimeout is being used?

Comment 12

[Boris Zbarsky [:bzbarsky]]

Note that chances are bug 810644 would also fix this, by the way.

Comment 13

[Bobby Holley (:bholley)]

(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.

Comment 14

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 15

[karl155]

(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);
}

Comment 16

[Firefox Bug Husbandry Bot]

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.

Comment 17

[Andrew McCreight [:mccr8]]

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

Comment 18

[Boris Zbarsky [: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.