
Target="_blank" – An underestimated vulnerability (2016) - handpickednames
https://www.jitbit.com/alexblog/256-targetblank---the-most-underestimated-vulnerability-ever/
======
Nagyman
I think/hope Chromium's recent announcement about "Expanding user protections
on the web", addresses the redirect issue:

> When the user interacts with content, things can also go wrong. One example
> that causes user frustration is when clicking a link opens the desired
> destination in a new tab, while the main window navigates to a different,
> unwanted page. Starting in Chrome 65 we'll also detect this behavior,
> trigger an infobar, and prevent the main tab from being redirected. This
> allows the user to continue directly to their intended destination, while
> also preserving the context of the page they came from.

[https://blog.chromium.org/2017/11/expanding-user-
protections...](https://blog.chromium.org/2017/11/expanding-user-protections-
on-web.html)

~~~
hdhzy
Excellent! Stealth redirects and vibrating ads are what drove me to Firefox
for Android with uBlock.

Note that developers could protect their sites for some time with noopener:
[https://mathiasbynens.github.io/rel-
noopener/](https://mathiasbynens.github.io/rel-noopener/)

~~~
ravenstine
Vibrating ads as in they move around or they cause your phone to vibrate?
Never seen that, but either way that makes me all the more glad to have ad
blocking installed at the root level. The level of annoyance the ad industry
goes to is astounding.

~~~
hdhzy
They cause my phone to vibrate "thanks to" the Vibration API [0]. A critical
component of the Web Platform ecosystem apparently.

[0]: [https://developer.mozilla.org/en-
US/docs/Web/API/Vibration_A...](https://developer.mozilla.org/en-
US/docs/Web/API/Vibration_API)

~~~
r00fus
In time this annoyance API will be seen as equivalent to the blink [1] tag.

[1]
[https://en.wikipedia.org/wiki/Blink_element](https://en.wikipedia.org/wiki/Blink_element)

------
jenoer
Various articles, blog posts etc. about this have already been posted to HN.

One of these inspired me to make a Firefox add-on that solves this issue:
[https://addons.mozilla.org/en-US/firefox/addon/dont-touch-
my...](https://addons.mozilla.org/en-US/firefox/addon/dont-touch-my-tabs/)
[/plug]

~~~
grahamel
Still always good to keep in people's minds.

Personally I use linting rules for this, e.g. for React projects
[https://github.com/yannickcr/eslint-plugin-
react/blob/master...](https://github.com/yannickcr/eslint-plugin-
react/blob/master/docs/rules/jsx-no-target-blank.md)

------
rdslw
Google considers (1) it unfixable:

" _Unfortunately, we believe that this class of attacks is inherent to the
current design of web browsers and can 't be meaningfully mitigated by any
single website; in particular, clobbering the window.opener property limits
one of the vectors, but still makes it easy to exploit the remaining ones._"

(1)
[https://sites.google.com/site/bughunteruniversity/nonvuln/ph...](https://sites.google.com/site/bughunteruniversity/nonvuln/phishing-
with-window-opener)

~~~
fniephaus
Lighthouse Audit - Opens External Anchors Using rel="noopener":
[https://developers.google.com/web/tools/lighthouse/audits/no...](https://developers.google.com/web/tools/lighthouse/audits/noopener)

~~~
madeofpalk
The 'popular' eslint-plugin-react can also make this a lint error
[https://github.com/yannickcr/eslint-plugin-
react/blob/master...](https://github.com/yannickcr/eslint-plugin-
react/blob/master/docs/rules/jsx-no-target-blank.md)

------
Grom_PE
In Opera 12, I killed "window.opener" by replacing the "opener" string with
"opera" in the opera.dll. This way it gets overwritten by the normal
window.opera variable and is essentially hidden. So far I haven't encountered
a site legitimately relying on this variable.

~~~
mygo
Window.opener isn’t your problem. Window.opener is sandboxed by CORS. And you
need it for things such as oAuth.

Target=“_blank” is your problem. That’s where Window.opener gets exposed.
You’re better off finding the “_blank” definition and renaming it so that it’s
never triggered, or assigning it to the definition of “self”, etc.

~~~
Grom_PE
Killing off "_blank" would disable force-opening links in a new window, which
is useful in dynamic context, e.g. chat page, so I don't want that.

Also, window.opener is still abusable if I middle-click links to open in a new
tab. I was very surprised when my Google Search tab got replaced by something
else after I middle-clicked on some questionable link.

------
username223
It's crazy that, after 20 years, web standards people still haven't realized
that the server is the user's _enemy_. Back in the 90s, this was demonstrated
by popups, which eventually got mostly fixed in most browsers. Now we have
this new pop-under mechanism, currently marked as WONTFIX, which will get
slowly mitigated over the next few years. Window.opener and target=_blank are
obvious avenues of abuse that would never have been added if web people had
learned anything over the past couple of decades.

~~~
XaspR8d
Didn't target="_blank" originate in that era you were talking about? I know
the target attribute was part of HTML4 (1999). I'm not sure when _blank became
a special value, but I imagine it was before the spec acknowledged it.

I agree window.opener was a fairly dangerous addition, but it _is_ subject to
CORS restrictions. You can't access it from just anywhere.

~~~
username223
I think you're right about target=_blank. Still, it has very little potential
to benefit the user, who can option-click or similar if he/she wants a new tab
or window, but has to copy-and-paste to prevent one. It should never have been
added.

I would rather that web browsers simply not implement things with significant
potential to do harm; at the least, those things should be disabled by
default. Unfortunately we aren't headed that way: WebUSB is coming[1]. Anyone
who could write that "[t]he composablity of the web allows a new ecosystem of
hardware support to be built entirely from web technology" without feeling a
chill run down their spine and imagining a years-long security nightmare is
truly blind.

[1] [https://wicg.github.io/webusb/](https://wicg.github.io/webusb/)

~~~
eponeponepon
Strewth, I can't even _read_ that without wanting to go and uninstall every
browser from every device I own.

Are people _really_ considering this? People that, y'know... _matter_?

edit: good lord, I read further and saw this:

    
    
        3. Security and Privacy
        Considerations
        
        This section is non-normative.
    

...I mean... surely, _surely_ that's the one bit that should be most
gigantically normative? Right?

~~~
pmoriarty
_" This specification recommends device manufacturers practice defense in
depth by designing their devices to only accept signed firmware updates and/or
require physical access to the device in order to apply some configuration
changes."_

Yes, let's put the burden of protecting users from browser-transmitted malware
on to the hardware manufacturers, who've had a such a wonderful track record
of caring about and protecting their users' security in the past. What could
possibly go wrong?

~~~
username223
_Aagh!_ "Let's take hardware designed to be connected to a machine by its
owner, connect it to the whole internet, and blame the hardware when it gets
hacked." Does anyone remember how long it took for single-user operating
systems to harden themselves against remote attacks? Yeah, they're still
working on it. Now imagine something like that, but for hardware that either
never gets firmware updates, or is connected to the internet so it can have
them pushed.

------
SippinLean
Setting target=_blank is almost always a bad idea anyway. Typically marketers
ask for it to prevent users from leaving your domain when clicking a link to
an external domain; the thinking being they will remain on our site longer if
we force a new window on them.

Testing has shown that this doesn't work in practice, and instead achieves the
opposite: the user in confused as to why they are in a new window, and it's
harder for them to return to your domain. The user is confused by the
ostensible "pop-up" (that they associate with ads) that has opened, and the
Back button no longer returns them to our domain, breaking with their expected
behavior.

Users know how to open links in new tabs/windows if they want to. In testing
at the places I've worked target=_blank only hurts conversions. Personally I
run a plugin that strips it from all links.

~~~
dazc
'Testing has shown that this doesn't work in practice....'

Is there any research you can point me to about this?

'...and the Back button no longer returns them to our domain, breaking with
their expected behavior.'

Yeah, except when the target site has disabled it and then you have even more
confusion. (Accepted it is rare, but it does happen).

~~~
SippinLean
I was referencing internal A/B testing results for several high-volume
e-commerce sites I've worked on.

An oft-parroted best practice in UX is "effective user interface places users
in control of the application." This study seems to agree:

[https://www.nngroup.com/articles/top-10-enduring/](https://www.nngroup.com/articles/top-10-enduring/)

>Many of our study participants moved to a new site or subsite without
realizing it and then struggled to get back to the main site because the
subsite offered no option for return

Using target=_blank _ensures_ the Back button is broken. A third-party site
disabling the Back button is out of your control.

~~~
dazc
Thanks for the further information.

------
Tehnix
Quick fix is _Search and Replace_ in your whole project, via your favourite
editor, from,

> target="_blank"

to

> target="_blank" rel="noopener noreferrer"

Which should not break anything unless you have some weird HTML lying around.

~~~
JamieF1
Yep you're right. I wrote a post about it before on Medium and made an
extension that automatically puts noreferrer in there for you. Here's the
link: [https://medium.com/@Jamie_Farrelly/browsers-are-broken-
but-n...](https://medium.com/@Jamie_Farrelly/browsers-are-broken-but-nobody-
cares-all-it-took-was-1-line-of-code-to-fix-it-f8af13c18cff)

------
singularity2001
TL;DR : read the original post, its to the point.

why not make rel="noopener noreferrer" default? if sites want to get credit
they can explicitly add rel="opener referrer"

~~~
nitely
They had their chance with HTML5. Actually, it was removed at some point.

------
konceptz
I’ve seen one case, not saying the generic model is not an issue, where this
was particularly bad. In a thick client built on web, there was absolutely no
indication of redirection because the app’s window showed only content. Plus
it was stored and delivered to other users. Persistent open redirect in a
thick client.

------
phkahler
Once again we have to ask "why is this even possible?" Web designers have been
given too much control over the browser is the usual answer and seem to be the
case here. There should be no interaction allowed between tabs.

~~~
styfle
The problem is the implementation, not the feature.

The postMessage API provides a safer way for Windows/Tabs to communicate.

[https://developer.mozilla.org/en-
US/docs/Web/API/Window/post...](https://developer.mozilla.org/en-
US/docs/Web/API/Window/postMessage)

~~~
phkahler
Given that most implementation are flawed, and given the limited utility of
this "feature", and given the inherent desire to sandbox thing on a browser, I
would say the problem is the mindset of the developers who keep adding stuff
that ends up exploited.

------
jopsen
Couldn't this just follow same domain rules like CORS?

But yeah it could break a lot of things... changing location is bad, but can
it really execute JavaScript in the opener context? That would be very
serious.

~~~
parenthephobia
JavaScript is subject to CORS, but "opener" isn't generally, except in Edge.

Even then, there is a risk of being surprised. If you open a page on the same
site, you may expect that scripts on the opened page can't access the opening
page: but because of CORS they can.

Here's a fiddle with a link to _another_ fiddle that copies the contents of a
password field from the first fiddle:
[https://jsfiddle.net/u6rmc49c/3/](https://jsfiddle.net/u6rmc49c/3/)

------
_pdp_
This reminds of my 9year old vulnerability reported here:
[https://bugzilla.mozilla.org/show_bug.cgi?id=469939](https://bugzilla.mozilla.org/show_bug.cgi?id=469939).

Essentially one can trick a user into typing their credentials into a phishing
site although it may appear they are using the legitimate site at first
glance.

The reason this is unfixed is that this is how the web works still.

------
carstimon
I'm pretty ignorant of browser stuff, but couldn't the attack be even worse
than mentioned in the article?

If the newly opened website has full control over the Facebook tab, can't the
attacker directly modify the html in the opener to pop up a form asking for a
password? This would be stronger because the address would not change.

Could the attacker reach into the Facebook tab and pull any information from
it?

~~~
paulddraper
No. You do not have access to the contents of the window because facebook.com
is on a different origin.

As this article says, you _can_ change the location of the window.

------
z3t4
> PS. Interestingly, Google doesn't seem to care.

Doesn't Google's browser hide the address bar !? Hiding the address does make
exploits like this way harder to notice. I know Google want's everyone to
search instead of typing an URL. But URL's are really powerful, please Google,
don't make them irrelevant!

~~~
Ajedi32
> Doesn't Google's browser hide the address bar

Huh? What are you talking about? All mobile browsers I'm aware of hide the
address bar when you scroll down, not just Chrome.

~~~
bhandziuk
Though when you navigate to a new page the address bar does show as the page
loads.

------
nixpulvis
I can assure you that at least "some" people at Google care.

