1094449 - links opened with rel="noreferrer nofollow" do not set window.opener to null, send over referrer information

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect)

Description

[kennysanx]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141027150301

Steps to reproduce:

Visit http://www.makesomeday.today/rel.html in Firefox 33/Firefox Beta 34
click on the link


Actual results:

Clicking on the link opens a new tab to http://66.228.47.213/landpage.html which contains a script that sets window.opener.location = https://www.google.com, which sets the parent tab location to google.com.

Observe in the net inspector that referrer information is transferred in the request, and window.opener is not set to null. If you edit http://www.makesomeday.today/rel.html and change the link attribute to only rel="noreferrer", clicking on the link does not transmit referral info and also sets window.opener to null.


Expected results:

1) No referrer information is transmitted in the request to open http://66.228.47.213/landpage.html
2) window.opener is set to null
3) The parent window (makesomeday.today/rel.html) should not redirect to google.com)

Comment 1

[Boris Zbarsky [:bzbarsky]]

Looks like nsDocShell::OnLinkClickSync is checking for the attribute value being "noreferrer".  It should be checking that one of the tokens in the value is noreferrer.

I don't think this is a security bug, fwiw.

Comment 2

[kennysanx]

Hey Boris sorry--I agree that this isn't particularly sensitive. This is my first time submitting a bug to Mozilla and I didn't really reflect too much on that checkbox at the end.

Comment 3

[Boris Zbarsky [:bzbarsky]]

No need to apologize.  It's not obvious that this is not a security bug (which is why I haven't unchecked the checkbox; I _think_ this is not an issue we need to keep hidden, but I could well be wrong).

And thank you very much for reporting this, by the way!

Comment 4

[Andrew McCreight [:mccr8]]

Please remove the sec-other keyword if you think this may be a security issue after all.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Attachment: Treat @rel on anchors as a set of space-separated tokens, not a single token

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8526517 [details] [diff] [review]
Treat @rel on anchors as a set of space-separated tokens, not a single token

bah, I should have caught this while reviewing.

Comment 7

[Boris Zbarsky [:bzbarsky]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/125c6f4823e5

Comment 8

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/125c6f4823e5

Comment 9

[:Gavin Sharp [email: [e-mail]]]

Bug 530396 landed in Firefox 33, is it worth uplifting this fix?

Comment 10

[sjw]

Now that we have this fixed it would be nice to have this in release notes.

[Why is this notable]:
This is a great privacy feature if you link to a (external) site on blog or forum posts.

[Suggested wording]:
Support for the rel="noreferrer" attribute added

[Links (documentation, blog post, etc)]:
https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a


(In reply to :Gavin Sharp [email: [e-mail]] from comment #9)
> Bug 530396 landed in Firefox 33, is it worth uplifting this fix?

For Firefox 33 it's to late, but we should ship this fix to release soon. I think this feature will be primarily used on external links and mostly they open in a new tab. So a lot of people run in this issue.

Comment 11

[Sylvestre Ledru [:Sylvestre]]

Added to the 36 release notes with "Link rel="noreferrer" attribute implemented" as wording.

Comment 12

[Boris Zbarsky [:bzbarsky]]

That's not the right wording.  rel="noreferrer" was implemented in firefox 33.

The right wording for this bug is:

  Fix bug with rel="noreferrer" being ignored if the rel value contains other tokens as
  well.

Comment 13

[Sylvestre Ledru [:Sylvestre]]

ok. That is not worth release notes that. Thanks.