1629455 - New window can edit window.opener.location to mask a phishing attack

Status: UNCONFIRMED

(Core :: DOM: Navigation, defect, P5)

Description

[Eric Huber]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

When a link opens in a new window, window.opener.location is easily edited by the destination page to refresh the original window/tab with a new location. The browser seems to issue no warnings about this.

Example:

(Originating page snippet)
<p>
<a href="landing.html" target="_blank">go to landing</a>
</p>

(Landing page snippet)
<script>
window.opener.location = "https://www.google.com";
</script>

Actual results:

Clicking the link opens a new tab (/window) and refreshes the originating page with a new URL in the background.

Expected results:

I think this should pop up a warning message from Firefox that the active page is trying to redirect another tab to a new URL. I imagine that this mechanism is used by certain login windows or payment window popups, but it's possible to use it to disguise a phishing attack, as illustrated in this (already old) Reddit post:

https://www.reddit.com/r/netsec/comments/bs07rj/why_reverse_tabnabbing_matters_an_example_on/

Comment 1

[Eric Huber]

It looks like this issue has been raised in the past, but the old issue about it suggests it was resolved:

https://bugzilla.mozilla.org/show_bug.cgi?id=408052

There have been similar issues posted for Chromium but no conclusive solution yet (or the issue has been ignored):

https://bugs.chromium.org/p/chromium/issues/detail?id=429395
https://bugs.chromium.org/p/chromium/issues/detail?id=168988

See also this article about it, that pointed out the issue links above:

https://medium.com/whatever-io/on-the-security-implications-of-window-opener-location-replace-a4a93c110768

The author notes that adding rel=noreferrer on the originating link can help to mitigate this, although it still leaves people vulnerable if whatever forum they are on has not enforced that on links other people have posted.

Comment 2

[Daniel Veditz [:dveditz]]

This is a known attack sometimes called "Tab-napping". We don't need to keep this hidden.

The old bug 408052 was about frames and taking over the destination of a window.open() popup, not the opener. No one's come up with a solution for opener that doesn't break the web, though browsers are trying to come up with new features to give pages an option.

Comment 3

[Eric Huber]

Thanks for following up. I see there was an attempt to implement the noreferrer workaround previously: https://www.ghacks.net/2018/11/30/firefox-security-relnoopener-for-target_blank/ I take it that was rolled back.

Comment 4

[Eric Huber]

(Or, rather than being rolled back, the dom.targetBlankNoOpener.enabled preference is still visible in about:config by default, just set to false.) It looks like it works in the trivial example but I suppose it would break sites. I wonder if a confirmation popup asking for permission to refresh the background tab would be sufficient.

Comment 5

[Firefox Bug Husbandry Bot]

Resetting severity to default of --.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:smaug, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 7

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Comment 8

[Chris Peterson [:cpeterson]]

P5 until we have a solution for opener that doesn't break the web.