{"id":3808,"date":"2019-04-08T11:05:00","date_gmt":"2019-04-08T11:05:00","guid":{"rendered":"http:\/\/the-codest.localhost\/blog\/web-app-security-target_blank-vulnerability\/"},"modified":"2026-04-27T09:54:29","modified_gmt":"2026-04-27T09:54:29","slug":"vefumsoknaroryggi-markmid-tom-veikleiki","status":"publish","type":"post","link":"https:\/\/thecodest.co\/is\/blog\/web-app-security-target-blank-vulnerability\/","title":{"rendered":"\u00d6ryggi vefums\u00f3kna. Veikleiki Target=\u201d_blank\u201d"},"content":{"rendered":"\n

Recently, we have written about web application security when it comes to XSS vulnerability<\/a><\/strong>. This time we want to pay your attention to another danger.<\/p>\n\n\n\n

The vulnerability discussed in this paper has been with us<\/a> for a long time and due to its simplicity, it is often underestimated or even unknown by some web application developers<\/a><\/strong>.<\/p>\n\n\n\n

Almost every web<\/a> application contains links that, when clicked upon, open in a new tab so as not to close the tab with the original page. This is a preferred behavior because the creators want the user to spend as much time in the application as possible.<\/p>\n\n\n\n

An attack that exploits this vulnerability is the so-called “reverse tabnabbing.” It is an attack where a page linked from the target page is able to replace that page with, for example, a phishing site.<\/p>\n\n\n\n

Attack scenario<\/h2>\n\n\n\n
    \n
  1. Suppose the victim uses Facebook which is known for opening links via target=”_blank”,<\/li>\n\n\n\n
  2. Create a fake viral page,<\/li>\n\n\n\n
  3. Create a phishing website that looks like Facebook sign-in page,<\/li>\n\n\n\n
  4. Put the below code<\/a> on the viral page e.g., via found XSS vulnerability
    window.opener.location = 'https:\/\/phishing-website\/facebook.com';<\/code><\/li>\n\n\n\n
  5. The victim clicks on the link on Facebook to the viral page,<\/li>\n\n\n\n
  6. The viral page redirects the Facebook tab to the phishing website asking the user to sign in again.<\/li>\n<\/ol>\n\n\n\n

    So, we can change the parent tab from infected target page by window object from Web API<\/a>. Typically, an attack involves using several discovered vulnerabilities and phishing scams in parallel.<\/p>\n\n\n\n

    The problem<\/h2>\n\n\n\n

    When we open a new tab in the browser using a link with the target=\"_blank\"<\/code> attribute, we have access to our “referrer” from the new tab. More specifically, to the opener<\/code> property of the Window<\/code> object, which returns a reference to the window that opened it, our parent page.<\/p>\n\n\n\n

    This is due to the behavior of the Window.open()<\/code> function. With access to this attribute, we can easily replace our parent page. Note that some modern browsers can make window.opener<\/code> function in target tab as null<\/code> to prevent this behavior.<\/p>\n\n\n\n

    Example code<\/h2>\n\n\n\n
     <a href=\"https:\/\/github.com\" target=\"_blank\">Go to GitHub - infected link<\/a><\/code>\nconst\n if (link)\n   link[0].onclick = () => {\n     if (window) window.opener.location = 'https:\/\/stackoverflow.com'\n   }<\/code><\/code><\/pre>\n\n\n\n
    Above you can see the infected link which originally opens a new tab with a GitHub page but meanwhile it changes our “parent” page to Stackoverflow site.<\/p>\n\n\n\n
    Live example<\/h2>\n\n\n\n
    \n