Closed Bug 1094449 Opened 6 years ago Closed 6 years ago
links opened with rel="noreferrer nofollow" do not set window
.opener to null, send over referrer information
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://220.127.116.11/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://18.104.22.168/landpage.html 2) window.opener is set to null 3) The parent window (makesomeday.today/rel.html) should not redirect to google.com)
Component: Untriaged → Document Navigation
Product: Firefox → Core
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
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!
Please remove the sec-other keyword if you think this may be a security issue after all.
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
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.
Attachment #8526517 - Flags: review?(bugs) → review+
Target Milestone: --- → mozilla36
Bug 530396 landed in Firefox 33, is it worth uplifting this fix?
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: email@example.com] 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.
Added to the 36 release notes with "Link rel="noreferrer" attribute implemented" as wording.
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.
ok. That is not worth release notes that. Thanks.
You need to log in before you can comment on or make changes to this bug.