The target="_blank" vulnerability by example
Tags: security, html, phishing
Published: 2016-09-11 17:04:16

---
title: The target="_blank" vulnerability by example
published: true
description: Instagram leaves its users open to a simple phishing attack
cover_image: https://i.vimeocdn.com/video/570148251_1280x720.jpg
tags: security,html,phishing
---

_**Edit:** We took the behavior to point out this flaw in Facebook because, even though interesting, it was getting to be annoying because Facebook was not fixing it. Oh well. Read this article and **imagine** everything that is described here. We're still playing around with this sometimes for fun. The overall issue is still alive and well in the web in general._

***

If you use the `target="_blank"` attribute on a link, and do not accompany it with a `rel="noopener"` attribute, you are leaving your users open to a very simple phishing attack. We run a script that takes advantage of this issue in order to notify users when they come from a site that has not protected them from the vulnerability.

```
if (window.opener) {
  window.opener.location = "https://dev.to/phishing?referrer="+document.referrer;
}
```


I believe that the majority of websites do not deal with this issue properly, but I was surprised to find that [Instagram.com](https://instagram.com/thepracticaldev) was one of them. We just recently started an [Instagram account for @ThePracticalDev](https://www.instagram.com/thepracticaldev) and that is when we noticed the problem. If you click the `dev.to` link in our profile, and then go back to the original tab, you will see what I mean. Twitter also does not protect against this vulnerability on Safari, not Chrome or Firefox. They do not use `rel="noopener"` so it seems like the script they are using to accomplish this security is not working properly in Safari.

**Edit:** Because Instagram fixed the issue after this post went up I have changed the following example to Facebook Pages.

### To clarify

1. Visit [The Practical Dev Facebook page](https://www.facebook.com/thepracticaldev/about/).
2. Click the `dev.to` link in the profile. This opens a new tab or window.
3. Observe that the original tab has migrated to [this page](https://dev.to/phishing).


![@ThePracticalDev Instagram Account](http://i.imgur.com/vc93vSS.png)

When a website uses `target="_blank"` on their links in order to open a new tab or window, that website gives the new page access to the existing window through the window.opener API, allowing it a few permissions. Some of these permissions are automatically negated by cross-domain restrictions, but window.location is fair game.

### But wait, there's more

Not only is this an issue with phishing attacks, it is also a privacy concern because the newly opened website has _ongoing_ access to the browsing location of the original tab. It can poll for this information and get the answer. Thankfully this behavior seems to fall under the cross-domain restrictions, so while I might gain access to certain ongoing information you might not expect me to know, there are sane restrictions that should likely apply to the entire spec.

**Edit:** When I first wrote this, I proposed a browser-spying scenario where a bad-actor could spy more thoroughly on a user's browsing history. I think that was inaccurate, so I modified the statement.

In order to restrict the behavior `window.opener` access, the original page needs to add a `rel="noopener"` attribute to any link that has `target="_blank"`. However, Firefox does not support that tag, so you should actually use `rel="noopener noreferrer"` for full coverage. Some amount of prevention can be acheived through scripting, though, as observed with Twitter, this seems to fail on Safari.

```
var otherWindow = window.open();
otherWindow.opener = null;
otherWindow.location = url;
```

This script suggestion came from [a good article on the subject](https://mathiasbynens.github.io/rel-noopener/).

This issue is not well-known, and is totally underestimated. This has been [brought up](http://lists.w3.org/Archives/Public/public-whatwg-archive/2015Jan/0002.html) in a Web Hypertext Application Technology Working Group mailing list. In my opinion, the risks of this browser behavior far outweigh the potential benefits. Either way, there are no excuses for Facebook and Instagram and Twitter to have overlooked this.

I'll have more to say about this kind of thing in the future. Follow me ([@bendhalpern](https://twitter.com/bendhalpern)) or [@ThePracticalDev](https://twitter.com/thepracticaldev) on Twitter if you are interested.