Web app security. Target=”_blank” vulnerability

Recently, we have written about web application security when it comes to XSS vulnerability. This time we want to pay your attention to another danger.

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

Almost every web 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.

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.

Attack scenario

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

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

The problem

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

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

Example code

 <a href="https://github.com" target="_blank">Go to GitHub - infected link</a>
const
 if (link)
   link[0].onclick = () => {
     if (window) window.opener.location = 'https://stackoverflow.com'
   }

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.

Live example

1. HTML links

Add rel="noopener noreferrer" to the <a> tag.

The rel attribute defines the relationship between a linked resource and the current document.

noopener tells the browser to navigate to the target without granting access to the parent that opened it. Target tab Window.opener will be null.

noreferrer prevents the browser, when navigating to target, to send to the parent the address or any other value as referrer via the referer HTTP header. Note that this HTTP header name is intentionally misspelled as “referrer.”

2. JavaScript links

For the JavaScript Window.open function, you can add the values noopener and noreferrer in the windowFeatures parameter of the Window.open function but different browsers may respond differently so it is recommended to make Window.opener as null after using Window.open() function.

Read more:

Rails API & CORS. A dash of consciousness

Data fetching strategies in NextJS

7 Reasons Why Your Online Shop Needs Magento

If you find this article interesting, follow Lukasz on Github: https://github.com/twistezo