Phishing and data theft await users due to target="_blank" vulnerability

Websites that sloppily implement the target="_blank" attribute on links are leaving visitors open to data theft and phishing attacks.

Ruby and JavaScript developer Ben Halpern of The Practical Developer explains the vulnerability works because of the way the attribute is designed:

“When a website uses target="_blank" on their links in order to open a new tab or window, that website gives the new page access to the existing window through the window.opener API, allowing it a few permissions. Some of these permissions are automatically negated by cross-domain restrictions, but window.location is fair game.”

Okay…so what?

It’s much more serious than it sounds.

An attacker could theoretically exploit the attribute’s functionality to put malicious code on a website that opens in a new tab or window via a link. When a user clicks on the URL in an existing window, a new window opens and loads the website.

While that page is loading, the malicious code executes and makes use of the target="_blank" attribute to load a phishing page, for example, in the existing window.

One such attack is shown in the animated GIF below:

Yes, Facebook is affected by this vulnerability in all browsers, as are a number of other websites including Twitter (Safari only) and Instagram (which just recently protected against exploitation of the flaw).

But if you think phishing is the only malicious use of this issue, you best think again!

Halpern notes an attacker can also leverage the vulnerability to steal some pieces of information that belong to the user:

“Not only is this an issue with phishing attacks, it is also a privacy concern because the newly opened website has ongoing access to the browsing location of the original tab. It can poll for this information and get the answer. Thankfully this behavior seems to fall under the cross-domain restrictions, so while I might gain access to certain ongoing information you might not expect me to know, there are sane restrictions that should likely apply to the entire spec.”

Given this multidimensional threat, the developer recommends website owners restrict window.opener by including the attribute rel="noopener noreferrer" with all embedded links on their site that use target="_blank". He also suggests that browsers look into modifying the behavior of this attribute more generally.

But let’s be honest: it could take a while before any of them get around to addressing the flaw.

In the meantime, you can verify the vulnerability for yourself by following the steps below:

1. Visit The Practical Dev Facebook page.
2. Click the dev.to link in the profile. This opens a new tab or window.
3. Observe that the original tab has migrated to this page.

Found this article interesting? Follow Graham Cluley on Bluesky, Mastodon, or Threads to read more of the exclusive content we post.

---