Reverse Tabnabbing | OWASP Foundation
Reverse Tabnabbing
Thank you for visiting OWASP.org. We have migrated our community to a new web platform and regretably the content for this page needed to be programmatically ported from its previous wiki page. There’s still some work to be done.
This is an example of a Project or Chapter Page.
Update 2023 - this is fixed in modern, evergreen, browsers
Links that use
target="_blank"
now have implicit
rel="noopener"
in
modern browsers, so this vulnerability isn’t as widespread and critical
as before. This implicit rule is also a part of the
HTML standard
According to Caniuse.com evergreen browsers support implicit
rel="noopener"
from about 2018, but there are still some browsers out there that doesn’t support
it, so please consider your userbase when/if deciding to
drop
rel="noopener"
Using
rel="noreferrer"
implies also
rel="noopener"
, so if you have
chosen to use
rel="noreferrer"
, the use of
rel="noopener"
isn’t required.
Description
Reverse tabnabbing is an attack where a page linked from the target page
is able to rewrite that page, for example to replace it with a phishing
site. As the user was originally on the correct page they are less
likely to notice that it has been changed to a phishing site, especially
if the site looks the same as the target. If the user authenticates to
this new page then their credentials (or other sensitive data) are sent
to the phishing site rather than the legitimate one.
As well as the target site being able to overwrite the target page, any
http link can be spoofed to overwrite the target page if the user is on
an unsecured network, for example a public wifi hotspot. The attack is
possible even if the target site is only available via https as the
attacker only needs to spoof the http site that is being linked to.
The attack is typically possible when the source site uses a
target
instruction in a
html link
to specify a
target loading
location
that do not
replace the current location and then let the current window/tab
available and does not include any of the preventative measures detailed
below.
The attack is also possible for link opened via the
window.open
javascript function.
Overview
With back link
Link between parent and child pages when prevention attribute is not
used:
Without back link
Link between parent and child pages when prevention attribute is used:
Examples
Vulnerable page:


  • href=
    "bad.example.com"
    target=
    "_blank"
    Vulnerable target using html link to open the new page

  • onclick=
    "window.open('https://bad.example.com')"
    Vulnerable target using javascript to open the new page



    Malicious Site that is linked to:





    When a user clicks on the
    Vulnerable Target
    link/button then the
    Malicious Site
    is opened in a new tab (as expected) but the target
    site in the original tab is replaced by the phishing site.
    Accessible properties
    The malicious site can only access to the following properties from the
    opener
    javascript object reference (that is in fact a reference to a
    window
    javascript class instance) in case of
    cross origin
    (cross
    domains) access:
    opener.closed
    : Returns a boolean value indicating whether a window has been closed or not.
    opener.frames
    : Returns all iframe elements in the current window.
    opener.length
    : Returns the number of iframe elements in the current window.
    opener.opener
    : Returns a reference to the window that created the window.
    opener.parent
    : Returns the parent window of the current window.
    opener.self
    : Returns the current window.
    opener.top
    : Returns the topmost browser window.
    If the domains are the same then the malicious site can access all the
    properties exposed by the
    window
    javascript
    object reference.
    Prevention
    Please check the first heading on this page, Update 2023, as this is now automatically prevented in all modern, evergreen, browsers.
    Check prevention information documented in the
    HTML5 Cheat Sheet
    References
    WHATWG HTML - Windows opened via

    should not have an opener by default
    Caniuse implicit rel=”noopener” when using
    target="_blank"
    Chrome Platform Status - Feature: Anchor
    target="_blank"
    implies
    rel="noopener"
    by default
    Chromium - Issue 898942: Anchor
    target="_blank"
    should imply
    rel="noopener"
    Mozilla - Make
    target="_blank"
    on
    area
    elements imply
    rel="noopener"
    by default
    WebKit Bugzilla - Bug 190481: Experiment:
    target="_blank"
    on anchors should imply
    rel="noopener"
    The
    target="_blank"
    vulnerability by example
    About
    rel="noopener"
    attribute values
    target="_blank"
    —  the most underestimated vulnerability ever
    Cure53’s
    Browser Security WhitePaper
    Reverse tabnabbing and blackshield demo
    Watch
    Star
    The OWASP
    Foundation
    works to improve the security of software through its community-led open source software projects,
    hundreds of chapters worldwide, tens of thousands of members, and by hosting local and global conferences.
    Important Community Links
    Community
    Attacks (You are here)
    Vulnerabilities
    Controls
    Upcoming OWASP Global Events