What Is Target Blank Anchor Tag Phishing Attack? How To Prevent It?
Short Bytes: When one hits a link (anchor tag) on a web page, and it opens in a new browser tab, there are chances that a hacker might have taken control over your original tab web page. This is caused because of the absence of an important HTML element attribute rel=”noopener”. And it has some serious performance benefits as well. But Facebook and Twitter refuse to correct it because they’ve to make a tradeoff.
Last September, Instagram fixed a big issue which is taken for granted by most of the frontend developers around the world. It’s the issue of putting a link with target=”_blank” attribute in an anchor tag to make it open in a new tab. There is a problem in how the browser behaves if one uses this for opening the link in a new tab.<a href="//fossbytes.com" target="_blank">Fossbytes</a>
It is because, when one clicks the link like this, the new tab that gets open has a
window.opener
which points to the HTML document of the page from which the link was clicked. This means that once the user clicks the link, the new malicious page has full control over previous page’s document’s full window object!
window.opener.location
is accessible across origins!
The attacker can leverage this, and while the link is opening in another tab, the attacker can redirect the original tab’s URL location to a phishing page in the background, designed to look like the real original page, asking for login credentials (now the origin security model of web prevents the attacker from reading the page). The user likely wouldn’t notice this, because the redirect happens in the background. This attack could be made even more subtle by adding a delay before redirecting to the phishing page in the background. This kind of attack is called reverse tab nabbing.
If the attacker is targeting, it can leverage another kind of attacks to see if a user is logged into, for example, a banking service, which often requires re-authentication after a session gets expired after a few minutes. Combine this with Unicode Domain Names, and people would have absolutely no idea what hit them since even the last chance of theirs looking at the URL of the affected tab would have deserted them ( It’s possible that a user wouldn’t be attentive to notice the address bar, especially when he’s on mobile browsers, which sometimes hide the address bar while scrolling down).
However companies like Facebook and Twitter are reluctant to fix this issue, and why? Because Facebook says that although this is indeed a door to a phishing attack, it would also block websites from seeing which visitors came to their website from Facebook.
Facebook’s status as a top traffic director is a major source of its revenue, and profit for people who can monitor where their users are coming from, especially if they are paying Facebook to do so.
What did Facebook do? Facebook delimits the number of requests a given IP address can make to it each second, which keeps hackers from phishing users on a large scale. But that won’t stop websites from exploiting the vulnerability on a small scale or keep hackers from targeting individuals.
Also Read: Improve Parallax Scrolling Effect On Your Webpage
The makers of the browsers have to have an action on this. Why give a user access to the window object of the original web page at all?
For now, one can fix it by simply adding a rel=“noopener noreferrer” attribute in the anchor tag like this:
<a href="//fossbytes.com" target="_blank" rel="noopener noreferrer">Fossbytes</a>
(noreferrer needed for older browsers)
One could, instead use
window.open()
by preventing the default action on click of a link, but facebook has found that it significantly reduces the amount of time that the new link takes to open in a new tab + it has some Safari issues. So. Na ah.
Interesting, Google has a different say on this.
What is amazing on top of this is, without the rel=noopener, the web page suffers from a performance hit. If an anchor tag without rel is opened, the original webpage tab’s main thread activity is disrupted, which means that
- Any javascript running on that page would be disrupted
- Any selecting of the text will be janky
- Scrolling would be janky. And so on.
But with rel=noopener, everything keeps running smooth with 60fps.
Why does this performance glitch happen at all?
Most browsers are multi-process except Firefox, whose team is working on it. Each process has multiple threads, including what we call the “main” thread. This is where the parsing, style calculations, layout, painting, non-worker (browser UI) Javascript runs. This means that Javascript running on one domain (say fossbytes.com) runs on a different thread to a window/tab running another domain (say youtube.com).
However, due to synchronous cross-window access, the DOM gives us via
window.opener
windows launched via target=”_blank” end up in the same process and thread! rel=”noopener” prevents window.opener so there’s no cross window access, hence the better performance!
Let us know how you found this article! We’d love to see your views on this.
