Reverse Tabnabbing

Description

Reverse tabnabbing exploits the window.opener reference that browsers establish between a page and any new tabs it opens via links with target="_blank". When a user clicks such a link, the newly opened page gains access to the window.opener object, which allows it to call window.opener.location.replace() and redirect the original tab to a different URL—typically a phishing page that mimics the original application's login screen.

CWE-1022 (Use of Web Link to Untrusted Target with window.opener Access) describes this mechanism precisely. The attack is particularly effective because users rarely monitor the content of tabs they have left inactive in the background. When they switch back to what they believe is their banking portal or corporate dashboard, they see a login prompt and enter their credentials without suspecting the page has been replaced.

The vulnerability is most impactful on applications that allow user-submitted URLs—forum links, comment sections, profile URLs, file sharing links, or any feature where untrusted users can cause links to appear in the application's interface. It also affects applications that link to third-party sites using target="_blank" without the rel="noopener" attribute.

How It Works

An attacker submits a URL to a comment, profile, or link field on the target application. When a victim user clicks the link:

1. A new tab opens to the attacker's page.
2. The attacker's page executes:

// Attacker's page — redirects the original (opener) tab
if (window.opener) {
  window.opener.location.replace(
    'https://attacker.example.com/fake-login'
  );
}

3. The victim's original tab silently navigates to the attacker's phishing page while the victim is looking at the new tab.
4. The victim switches back to the original tab, sees what appears to be a session timeout prompt, and enters their credentials.

The attacker's phishing page is a pixel-perfect clone of the target application's login screen. Since the victim was just using the real application in that very tab, the prompt appears entirely legitimate.

A vulnerable link in the target application looks like:

<!-- Vulnerable: no rel="noopener noreferrer" -->
<a href="https://external-site.com/user-content" target="_blank">View attachment</a>

Penetration testers identify tabnabbing by reviewing the application's HTML source for target="_blank" links without rel="noopener", and by submitting attacker-controlled URLs to any user-content link fields to test whether they render in the application.

# Find vulnerable links in page source
curl -s https://example.com | grep -oP '<a[^>]+target="_blank"[^>]*>' | grep -v noopener

Impact

• Credential phishing — Victims unknowingly submit credentials to a phishing page styled to match the original application.
• Session token theft — Sophisticated phishing pages that appear as session timeout prompts harvest active session tokens as well as credentials.
• Account takeover — Harvested credentials enable direct account compromise, especially for accounts without MFA.
• Trust exploitation — The attack leverages the trust users have in an established application context, making it more convincing than unsolicited phishing emails.
• Targeted corporate attacks — Attackers who can post to internal collaboration tools (wikis, ticketing systems) can target high-privilege users by embedding malicious links in official-looking content.

Detection

1. Review all HTML output for <a> tags with target="_blank" and check whether rel="noopener" or rel="noopener noreferrer" is present.
2. Submit attacker-controlled URLs to any user-content link fields (profile URLs, link submission forms, comment fields) and verify whether they render as clickable target="_blank" links.
3. Create a test page that checks window.opener and redirects it; serve it at a URL you submit to the application, then click the link as a victim user and confirm whether opener access is available.
4. Test all window.open() calls in the application's JavaScript for the noopener feature flag: window.open(url, '_blank', 'noopener,noreferrer').
5. Review user-generated content rendering pipelines to confirm that link sanitizers enforce noopener on all external links.

Remediation

Add rel="noopener noreferrer" to all external links. This is the primary fix and requires no server-side changes:

<!-- Fixed: opener access revoked -->
<a href="https://external-site.com" target="_blank"
   rel="noopener noreferrer">View resource</a>

noopener revokes window.opener access. noreferrer additionally prevents the Referer header from being sent, providing additional privacy.

Sanitize user-submitted links server-side. When rendering user-submitted URLs as links, enforce rel="noopener noreferrer" programmatically in your link rendering code rather than relying on authors to include it.

Use window.open with noopener flag. For JavaScript-initiated window opens:

window.open(url, '_blank', 'noopener,noreferrer');

Implement Content Security Policy. A strict CSP does not directly prevent tabnabbing but limits what attacker-controlled pages can do with opener access.