4th December 2020

Chrome gets to grips with tabnapping phishing attacks

Everything Else

Ten years after tabnapping was first demonstrated, Chrome is taking steps to stop it.

Tabnapping is a phishing attack where an open but inactive browser tab is quietly changed to a malicious site behind your back, exploiting users’ inability to keep track of what’s on each of their open browser tabs.

There are two variations:

In the original version, demonstrated by Firefox’s Aza Raskin a decade ago, a user loads a phishing site disguised as an innocent-looking website. When the user opens a second tab, the phishing site uses JavaScript or a meta refresh tag to transform itself into something else. When the user returns to the first tab it now looks like a login page for Facebook, Gmail, or another service.

Forgetting which site was originally open in that tab, the user logs into the fake service, handing over their credentials to the attackers behind it.

Luckily, it never became terribly popular among cybercriminals, probably because it was more involved than traditional phishing attacks which were already hugely successful.

In this original form of the attack the user must be lured to a malicious page. But there’s a second and potentially more dangerous variant called reverse tabnapping.

In reverse tabnapping, that first page can be genuine, which in theory raises the chance that users will be fooled.

In this form of the attack, a user loads a genuine web page and clicks a link on it that opens a site in a second tab. If an attacker is able to control the page in the second tab – perhaps by hacking the site or its DNS, or by intercepting the user’s HTTP traffic – they can swap the genuine site in the first tab for a malicious one (using the JavaScript opener object) while the user is busy on the second tab.

Browser fixes

It’s taken a long time for the industry to address the issue at a technical level. For years, the only way to counter this was to load a browser plug-in such as NoScript, but that came at the expense of manually approving or even blocking JavaScript from working on legitimate websites.

Site owners could protect users by adding the rel="noopener" attribute to links on their sites that open in a new tab. This severs the parent-child relationship between two tabs and solves the problem, but getting every website to do this (or even just some) was always going to be difficult.

The third possibility was to tweak browsers so that they assume the presence of a rel="noopener" attribute by default. That’s now happening - Firefox version 79 adopted this approach in July 2020 and Google says it is implementing the same change in Chrome version 88, due in January 2021.

The change will inevitably break some sites, and site owners who aren’t happy with the change can restore the original functionality by setting a rel="opener" attribute on links that should open in a new tab.

Importantly, it seems other browsers based on the Chromium core will get the same upgrade, so this change will apply to browsers such as Edge, Brave and Opera too.

The tabnapping story is another example of how difficult it is to stop phishing attacks by technical means alone. Technical changes take time because consensus takes time, by which point years can have elapsed. In this case the technical change is welcome, but it only addresses a single phishing tactic and attackers that rely on it will have plenty of time to move on before it’s rolled out.



Enter your email address to get full access

James Moore, CultureAI
By James Moore
CEO & FOUNDER
Trusted by

Get started now with 30 days free, instant access

Build a security culture where people prevent breaches.