1426702 - rel=noreferrer is ignored in <a target="_blank"> leading to referer leakage

Status: RESOLVED DUPLICATE of bug 1420702

(Core :: DOM: Security, defect)

Description

[Veronika]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36

Steps to reproduce:

I have a page with element:
<a class="link" href="https://www.mozilla.org/ru/firefox" target="_blank" rel="noreferrer noopener nofollow"><img src="/img/firefox.png" width="100" height="100" alt=""><h3 class="plain-title">Firefox</h3></a>

Firefox version 57.0.1 Mac os 64-bit
javascript is disabled in config


Actual results:

I intercept the request while opening the link from the element with burp, excepting there will be no referer in request, but it is there.


Expected results:

There will be no referer header in request. The referer in my case contains sensitive information that should not be passed to other domains.

Comment 1

[:Gijs (he/him)]

Seems the target="_blank" is required for this to be broken, but obviously removing that has other side-effects so it's not really an easy workaround.

Have you tried if the <meta referrer> tag helps you here, or is that also broken? (To be clear, not saying the behaviour is not an issue if the meta tag works, but that would provide you with a short-term "fix", and presumably if the URL contains sensitive information then it shouldn't be leaked for *any* referring (non-same-origin) sites, which you can set up using the <meta> tag.)

Comment 2

[:Gijs (he/him)]

mozregression points to this commit in the 56 timeframe:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1fc1e9d7f1fc60f6280408bbc704f551659d016c&tochange=eb24bfe4f969df1cbf05782164d5143a29b20bdf

We have tests for referrers, and I don't really understand why those didn't catch this.

:mystor, can you take a look?

Comment 3

[Nika Layzell [:nika] (ni? for response)]

Attachment: simple test case

I am having trouble reproducing this locally with my simple test case. From what I can tell the referrer seems to be omitted correctly in that situation. Clicking on the links in the test case I don't get a referrer when clicking the first link, but do for the 2nd and 3rd, which is what I would expect.

Comment 4

[:Gijs (he/him)]

(In reply to Nika Layzell [:mystor] from comment #3)
> Created attachment 8938506 [details]
> simple test case
> 
> I am having trouble reproducing this locally with my simple test case. From
> what I can tell the referrer seems to be omitted correctly in that
> situation. Clicking on the links in the test case I don't get a referrer
> when clicking the first link, but do for the 2nd and 3rd, which is what I
> would expect.

Seems that this is broken on 58 beta but not (anymore, apparently) on Nightly. I didn't realize this before because after reproducing on 58, I ran mozregression with --bad 57 (which matches the reporter) and just found a regression window. It didn't occur to me this could have been fixed in the last few weeks of nightly... I'll see if I can find a fix range.

Comment 5

[:Gijs (he/him)]

fixed window: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ace59c114b1df0a2b2876d03129abdff29c57ddd&tochange=0f6ee76c53931458b43a32f62adff085d9fe0cb7

Thomas, how risky would it be to take your patches to 58 - perhaps you could request uplift? It seems things weren't just broken in pinned tabs but also for _blank links in normal tabs.

Comment 6

[:Gijs (he/him)]

Err, so yeah, this was fixed in bug 1420702. Apologies for the confusion. I'm not really sure if it's appropriate to dupe given the fact that the original bug was specific to pinned tabs. The problem seems to be much broader, and IMO that might mean it qualifies for fixing on beta.

Comment 7

[Veronika]

(In reply to :Gijs from comment #1)
> Seems the target="_blank" is required for this to be broken, but obviously
> removing that has other side-effects so it's not really an easy workaround.
> 
> Have you tried if the <meta referrer> tag helps you here, or is that also
> broken? (To be clear, not saying the behaviour is not an issue if the meta
> tag works, but that would provide you with a short-term "fix", and
> presumably if the URL contains sensitive information then it shouldn't be
> leaked for *any* referring (non-same-origin) sites, which you can set up
> using the <meta> tag.)

I've checked it now, but it didn't work. Referrer is sent any way.

Comment 8

[Thomas Nguyen (:tnguyen)]

(In reply to :Gijs (mostly out until Jan 3) from comment #5)
> fixed window:
> https://hg.mozilla.org/integration/autoland/
> pushloghtml?fromchange=ace59c114b1df0a2b2876d03129abdff29c57ddd&tochange=0f6e
> e76c53931458b43a32f62adff085d9fe0cb7
> 
> Thomas, how risky would it be to take your patches to 58 - perhaps you could
> request uplift? It seems things weren't just broken in pinned tabs but also
> for _blank links in normal tabs.

The fix propagated referrer policy to nsOpenURIInFrameParams and I added necessary parameters (referrerPolicy and nsIDocShellLoadInfo) to pass referrerpolicy param in js. The patches did not change how to use the param, so I think it will be ok. I am requesting an uplift.

Comment 9

[Sylvestre Ledru [:Sylvestre]]

Too late for 57

Comment 10

[:Gijs (he/him)]

Given this was effectively fixed in bug 1420702 and we're not uplifting to 58 or 57, let's not keep this open.