1. Front End Security Basics: Reverse Tabnabbing

1. Front End Security Basics: Reverse Tabnabbing

1. VULNERABILITY INTRODUCED

A web-page may use multiple methods to open additional tabs or windows. However, these methods may often add a reference to the opener (or window.opener) object in the newly opened window, which refers to the “parent” tab or window. While most attributes in the opener window are blocked and inaccessible to the opened window, such that the opened window may not refer to most opener attributes (part of the cross-domain policy), some are not blocked. In particular, the opened window may change the location of the opener window, by setting opener.location.
For example, if a web application X insecurely opens a malicious web application Y in a new window, Y may immediately redirect X to a malicious website Z that resembles X, and uses this fake website Z to phish users for credentials.
As the user doesn’t expect the original page X to change, they are less likely to notice that it has been changed to a phishing site, especially it the site Z looks the same as the source site X. When the user authenticates to this new page, their credentials (or other sensitive data) are sent to the phishing site rather than the legitimate one. This attack is known as Reverse Tabnabbing (unlike normal Tabnabbing, which is an ordinary phishing attack).
There are two frequently used ways to leak the opener object:
1. Using an <a href> and target=_blank in HTML:
<a href=”https://evilsite.com/reverse_tabnabbing.html” target=”_blank”>Click me</a>
2. Using window.open in Javascript:
<script> window.open(‘https://evilsite.com’); </script>
The opened website can then alter the address of the opening website:
<script>opener.location=”https://www.evilsite.com”;<script>

image

image

2. EXERCISE BACKGROUND

The vulnerable application pane loads the FriendsList.me website, a popular social network where people communicate with each other and share content. Because of its growing popularity, many other websites have implemented shared authentication with FriendsList using its API.
Enter the following credentials to log in as Bob:
Email: [email protected]
Password: Qwerty123!

3. VULNERABILITY DETECTED

Bob is a malicious user of FriendsList.me. When he was posting a link to his favorite page:
https://www.owasp.org/index.php/Reverse_Tabnabbing
Bob noticed that when FriendsList.me processes the link to display it on the page, it adds target=_blank parameter for the target page to open in a new tab or window. This actually means that this page could be vulnerable to the Reverse Tabnabbing attack.

image

image

image

Click the link in Bob’s post.

image

4. MALICIOUS PAGES CREATED

First, Bob creates a page that contains a quiz: “Which Game of Thrones Character Are You?” and embeds the following code in it:
window.opener.location = ‘https://fakeslist.me/phishing_page.html’;
This code opens specified page in the opener (source page) window instead of the source page.
Then Bob creates a phishing page asking the FriendsList users to re-enter their website credentials. After the users click LOGIN, they are redirected to the actual FriendsList page and their credentials are sent to Bob’s server.

image

5. GET PREPARED TO THE ATTACK

Bob shares a link to his malicious quiz page in his neighborhood group on FriendsList, with a lead-in that motivates other members to click it.
At the same time, Bob opens his server log to check for results of his attack.

image

6. VULNERABILITY EXPLOITED

Alice is logged in to the application. She likes Game of Thrones and funny quizzes, so she clicks the link. 
For the purpose of clarity, we’ve put both windows side by side to demonstrate that the source window loads the phishing page right after the target window loads the quiz page. In real life, source window web page reloads in the background: below the target window, or on another tab.

image

When Alice clicks the link, the web page with the quiz opens in a new window and loads as expected.
However, Bob’s malicious code is also executed in Alice’s browser. And at the background, Alice’s FriendsList page is changed to Bob’s malicious phishing page that looks like the login page of FriendsList.me website.
When Alice returns to the window where her FriendsList page was displayed, he sees that her session has expired, and she needs to log in again.
Enter the following credentials to log in as Alice:
Email: [email protected]
Password:12345!

image

7. SUCCESSFUL ATTACK

Alice is successfully redirected to her FriendsList page.
Now look at the server log of Bob’s server: there is a string with Alice’s credentials. 

image

8. REMEDIATION

To prevent the Reverse Tabnabbing attack, cut the back link between the parent and the child pages:
For an html link:
Add the attribute rel=”noopener” on the tag used to create the link from the parent page to the child page. This attribute value cuts the link.
For the javascript window.open function:
Add the  noopener value into the corresponding function.

//In HTML:
<a href=”https://evil_site.com/reverse_tabnabbing.html” target=”_blank”>Click me</a>
//In Javascript:
<script> window.open(‘https://evil_site.com’, ‘new window name’); </script>

To prevent pages from abusing window.opener, use rel=noopener for HTML links, or noopener as a third variable for window.open in JavaScript. This ensures window.opener is null.

image

//In HTML:

<a href="https://evil_site.com/reverse_tabnabbing.html" target="_blank" rel="noopener">Click me</a>

//In Javascript:

<script> window.open('https://evil_site.com', 'new window name', 'noopener'); </script>

Comments are closed.