Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to prevent tabnabbing with the referrer-policy header #141

Closed
ConradIrwin opened this issue Jul 6, 2020 · 3 comments
Closed

Ability to prevent tabnabbing with the referrer-policy header #141

ConradIrwin opened this issue Jul 6, 2020 · 3 comments

Comments

@ConradIrwin
Copy link

First off, I apologise if this is the wrong place to bring this up; but I figured that you would know even if it wasn't!.

Today an independent security researched flagged a potential "reverse tabnabbing" vulnerability on a website I run. I was unfamiliar with the concept, but it has been known of for a long time (https://en.wikipedia.org/wiki/Tabnabbing) and there's a good description here: https://web.dev/external-anchors-use-rel-noopener/

In short, if https://trusted.example has a link of the form <a target="_blank" href="https://untrusted.example"> (without rel="noopener") then javascript running on untrusted.example could run window.opener.location = "https://phishing.example" causing the trusted website to be replaced silently by the phishing website.

The only mitigation that I could find on the internet is to ensure that any link with a target="" attribute to an untrusted resource also has a rel="noopener" (or rel="noreferrer") as in these cases window.opener will be nulled out in the opened site.

As a website owner who allows other people to edit the contents of the site, and one who would never like to take advantage of opened sites accessing window.opener, I'd like to be able to set a header to globally prevent this.

There are a few options I could see:

  1. (Not backward compatible) If the Referrer-Policy would send either no referrer, or just the origin, then it would also set window.opener to null.
  2. Allow Referrer-Policy to end with, no-opener or , no-opener-when-cross-origin as a way to opt into the desired opener behaviour without changing the referrer-policy.
  3. Invent a new header (or maybe a new Content-Security-Policy rule) that allows for preventing this behaviour.

I'd love to know if there is a mitigation that exists today which I missed when searching, or where I should bring this discussion up.

Thanks in advance!

@annevk
Copy link
Member

annevk commented Jul 6, 2020

The Cross-Origin-Opener-Policy header tackles this, soonish shipping in Chrome and Firefox. Safari and Fx (from 79 onward) also default target=_blank to rel=noopener (you can undo with rel=opener).

@ConradIrwin
Copy link
Author

Perfect, thank you for sharing, and sorry I missed that!

Do you think it's worth filing a bug with Chrome about copying the Safari/Firefox behaviour? That seems like the best fix to me.

@annevk
Copy link
Member

annevk commented Jul 6, 2020

https://bugs.chromium.org/p/chromium/issues/detail?id=927340 https://bugs.chromium.org/p/chromium/issues/detail?id=898942 per whatwg/html#4330.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants