What is Reverse Tabnabbing? Ways to Exploit, Examples and Impact
Learn how reverse tabnabbing exploits window.opener to hijack browser tabs. Discover technical examples and prevention tips to secure your web applications.
Phishing is often perceived as a collection of deceptive emails or SMS messages, but some of the most insidious threats reside directly within the architecture of the web browser itself. One such technique is Reverse Tabnabbing-a sophisticated phishing attack that leverages the trust a user places in an already-open browser tab. By exploiting a specific behavior in how browsers handle new windows, attackers can silently redirect a legitimate page to a malicious one, catching even tech-savvy users off guard.
What is Reverse Tabnabbing?
Reverse tabnabbing is a vulnerability that occurs when a web page links to an external site using the target="_blank" attribute without proper security restrictions. When a user clicks such a link, the browser opens the destination URL in a new tab. However, due to a legacy behavior in web standards, the newly opened page gains partial access to the original (parent) page via the window.opener JavaScript object.
This access allows the malicious site to change the URL of the original tab. While the user is busy browsing the new page, the original tab-which they likely trust because they navigated to it themselves-is redirected to a phishing site. When the user eventually clicks back to that original tab, they are presented with a fake login screen or a "session expired" notice, prompting them to re-enter sensitive credentials.
The Role of window.opener
To understand the technical depth of this attack, we must look at the window.opener property. In the Document Object Model (DOM), when a window is opened from another window (using window.open or a link with target="_blank"), it maintains a reference to the window that opened it.
This reference is stored in window.opener. While Same-Origin Policy (SOP) prevents the child page from reading the content of the parent page if they are on different domains, it does not prevent the child from accessing the window.opener.location property. This allows the child page to execute a command like window.opener.location = 'https://malicious-site.com', effectively hijacking the parent tab's navigation.
How Reverse Tabnabbing Works: The Attack Flow
The execution of a reverse tabnabbing attack typically follows a specific sequence of events. Understanding this flow is crucial for developers and security professionals using tools like Jsmon to identify potential entry points in their external infrastructure.
- The Vulnerable Link: An attacker finds a website that allows user-generated content, such as a forum, a social media profile, or a comment section. They post a link to a website they control, ensuring the link uses
target="_blank". - User Interaction: A victim, browsing the legitimate site, clicks the attacker's link. A new tab opens, displaying the attacker's content.
- The Silent Redirection: While the victim is reading the content in the new tab, a small piece of JavaScript executes on the attacker's page. This script targets the
window.openerobject to redirect the original, legitimate tab to a phishing page that looks identical to the original site's login page. - The Phishing Trap: The victim finishes reading the content in the second tab and closes it. They return to the first tab, which now shows a login prompt. Believing their session has timed out, the victim enters their username and password.
- Data Exfiltration: The phishing page captures the credentials and sends them to the attacker's server, often redirecting the user back to the real site afterward to avoid suspicion.
Technical Payload Examples
Let's look at the code that makes this possible. Suppose a vulnerable site has the following HTML code for a user's profile link:
<!-- Vulnerable Code on https://legit-social-network.com -->
<a href="https://attacker-site.com/blog-post" target="_blank">
Visit my personal blog
</a>
When the user clicks this link, https://attacker-site.com/blog-post opens in a new tab. On that page, the attacker includes the following JavaScript snippet:
// Malicious script on https://attacker-site.com/blog-post
if (window.opener) {
window.opener.location = "https://legit-social-network.com.phish.com/login";
}
Alternatively, if the attacker wants to be even more subtle, they can use a delay to ensure the user is distracted:
setTimeout(function() {
if (window.opener) {
window.opener.location = "https://legit-social-network.com/login-expired";
}
}, 5000); // Redirects after 5 seconds
Common Vulnerable Scenarios
Any platform that allows users to share links that open in new tabs is potentially vulnerable to reverse tabnabbing if not properly configured. Common examples include:
- Social Media Profiles: Linking to personal websites or portfolios from a profile page.
- Forums and Message Boards: Links included in signatures or post bodies.
- Content Management Systems (CMS): Internal dashboards that link out to third-party plugins or documentation.
- Web-based Email Clients: Clicking links within an email that open in a new tab.
In many of these cases, the user has already authenticated with the platform, making the "session timeout" or "re-login" ruse highly convincing.
Real-World Impact and Examples
The impact of reverse tabnabbing is primarily centered on credential theft and account takeover. Because the attack relies on the user's existing trust in a specific tab, the success rate can be significantly higher than traditional email phishing.
Credential Harvesting
This is the most common outcome. Attackers target high-value accounts, including corporate emails, banking portals, and administrative dashboards. Once the credentials are stolen, the attacker can move laterally through an organization or drain financial assets.
Bypassing Multi-Factor Authentication (MFA)
If the phishing page is sophisticated, it can act as a proxy. When the user enters their credentials and MFA code on the fake site, the attacker's server passes them to the real site in real-time, effectively hijacking the session even with MFA enabled.
Brand Damage
For organizations, being the "source" of a tabnabbing attack can lead to significant reputational damage. Users may blame the original site for failing to protect them, even if the actual theft happened on a different domain.
How to Detect Reverse Tabnabbing
Detection involves identifying outbound links that lack the necessary security attributes. Security teams can use automated scanners or manual code reviews to find instances of target="_blank" without accompanying protection.
For a large-scale infrastructure, manually checking every link is impossible. This is where Jsmon becomes invaluable. By mapping your external attack surface, Jsmon helps you visualize how your web properties interact with external domains, making it easier to spot risky configurations and unvalidated redirects that could be exploited for tabnabbing.
Prevention and Mitigation Strategies
Fortunately, preventing reverse tabnabbing is technically straightforward. The primary defense involves using the rel attribute in HTML links.
Using rel="noopener"
The rel="noopener" attribute is the most effective way to stop reverse tabnabbing. When added to a link, it instructs the browser to open the new page in a separate process and, crucially, to set window.opener to null in the new tab.
<!-- Secure Code -->
<a href="https://external-site.com" target="_blank" rel="noopener">
Safe Link
</a>
Using rel="noreferrer"
The rel="noreferrer" attribute provides the same protection as noopener but also prevents the browser from sending the Referer HTTP header to the destination site. This is useful for privacy, as it hides the URL of the originating page from the destination server.
<!-- Secure and Private Code -->
<a href="https://external-site.com" target="_blank" rel="noreferrer">
Safe and Private Link
</a>
Implementing a Content Security Policy (CSP)
A robust Content Security Policy can provide an additional layer of defense. While CSP doesn't directly disable window.opener, it can restrict where your site is allowed to send users and what scripts are allowed to run, limiting the efficacy of a phishing page if a redirect does occur. Specifically, the disown-opener directive was proposed in the past, though modern browser support favors the rel attribute approach.
Browser-level Protections
In recent years, browser vendors have taken steps to mitigate this vulnerability by default. Starting with Chrome 88, Firefox 79, and Safari 12.1, the browsers began treating target="_blank" as if rel="noopener" were implicitly set.
However, developers should not rely solely on browser defaults. Legacy browsers still in use in corporate environments may not support these defaults, and explicit declaration of rel="noopener" remains a best practice for defense-in-depth.
Conclusion
Reverse tabnabbing is a prime example of how small, often-overlooked technical details can be weaponized into powerful social engineering tools. By understanding the relationship between the target="_blank" attribute and the window.opener object, developers can implement simple HTML fixes that provide massive security gains.
As the web evolves, maintaining visibility over your links and external dependencies is paramount. Vigilance, combined with proper coding standards and modern security headers, ensures that your users remain safe from the subtle art of tab hijacking.
To proactively monitor your organization's external attack surface and catch exposures before attackers do, try Jsmon.