Blog of Daniel Ruf

target="_blank" considered harmful

30.08.2020

A few weeks ago I found a very simple but also dangerous vulnerability on a website as attackers can take control of the page when a user clicks a specific link. The reported vulnerability was quickly acknowledged and they rolled out a fix a few days later.

Often links look like this:

<a href="https://example.com" target="_blank">some link</a>

Besides the bad UX, links with target="_blank" can cause more problems, like specific security issues.

In this case the target attribute value _blank creates a new navigation context, a new tab.

A new opened tab like this still has control over the original page through window.opener which includes window.opener.location. Adding rel="noopener" to the link prevents this and sets window.opener to null. For old browsers like Internet Explorer 11 you have to use rel="noopener noreferrer", see which browsers support noopener and noreferrer.

Such links should look like this:

<a href="https://example.com" target="_blank" rel="noopener noreferrer">some link</a>

This vulnerability is also known as Reverse Tabnabbing. There are also some examples and a detailed explanation with illustrations and further references which demonstrate the problem.

If you want to test for this in pentests or bug bounties, you may have to disable some new security measures / settings in some modern browsers like Firefox.

// disable protection against tabnabbing in user.js
user_pref('dom.targetBlankNoOpener.enabled', false);
user_pref('privacy.firstparty.isolate.restrict_opener_access', false);
user_pref('dom.noopener.newprocess.enabled', false);
user_pref('browser.tabs.remote.useCrossOriginOpenerPolicy', false);

By finding expired domains which are still linked on many websites, an attacker can abuse this technique to effectively take control of the tabs and the pages where the links were opened. This could be used for several (Self-)XSS and phishing attacks. And most developers have forgotten that this vulnerability still exists.

Timeline

2020-06-18 21:49: reported the vulnerability
2020-06-18 22:07: report was acknowledged and a fix was prepared


Written by Daniel Ruf.