
Target=“_blank” – the most underestimated vulnerability ever - antibland
https://www.jitbit.com/alexblog/256-targetblank---the-most-underestimated-vulnerability-ever/
======
psiinon
It's called Reverse Tabnabbing on OWASP:
[https://www.owasp.org/index.php/Reverse_Tabnabbing](https://www.owasp.org/index.php/Reverse_Tabnabbing)
\- lots more details there. Its detected by the ZAP beta passive scan rules:
[https://github.com/zaproxy/zap-
extensions/wiki/HelpAddonsPsc...](https://github.com/zaproxy/zap-
extensions/wiki/HelpAddonsPscanrulesBetaPscanbeta#reverse-tabnabbing)

------
richardwhiuk
The Google Bughunter page suggests that there are plenty of other ways to
exploit this - anyone know what they are?

------
surround
Proof of concept:

[https://mathiasbynens.github.io/rel-
noopener/](https://mathiasbynens.github.io/rel-noopener/)

~~~
rasz
window.opener = undefined; takes care of the problem

------
SigmundA
Actually surprised this is possible in crossdomain. Almost everything else
through is locked down otherwise.

Anyone know why this isn't considered a bug and fixed? What is a legit use of
a window changing it opener location crossdomain? I get it in the same web
site / app.

------
hbcondo714
This was previously discussed here a few years ago but the article was updated
in September of this year

[https://news.ycombinator.com/item?id=15685324](https://news.ycombinator.com/item?id=15685324)

------
combatentropy
> The page we're linking to gains partial access to the linking page via the
> window.opener object. The newly opened tab can then change the
> window.opener.location

Dear browsers, please just remove this feature.

~~~
rasz
There might be some legacy code using this, but privacy conscious browsers (so
not Chrome, but maybe Vivaldi?) should have a section dedicated to turning off
stupid shit like this. Opera used to have plethora of options where you could
disable user hostile tricks like blocking right click menu etc. Things you
could customize (down to per website granularity):

Allow resizing of windows

Allow moving of windows

Allow raising of windows

Allow lowering of windows

Allow changing of status field

Allow scripts to detect context menu events

Allow script to hide address bar

Enable frames

Enable inline frames

Send referrer information

+ability to disable/set detailed quota/readonly for HTML5 local
storage/cookies

Modern browser should probably throw in ability to disable/block AudioContext/
navigator.mediaDevices/ navigator.getUserMedia/
HTMLCanvasElement.prototype.toDataURL/ HTMLCanvasElement.prototype.toBlob/
CanvasRenderingContext2D.prototype.getImageData/ WebRTC/ navigator.sendBeacon/
window.opener

------
rs23296008n1
Interesting that Google don't see this as fixable.

I'm surprised it can't be addressed. Is being able to modify the referrer
location that difficult to lock in various ways?

~~~
est
It's interesting that Google is the only expected browser vender these days.

~~~
zamadatix
Firefox was mentioned in the article, Safari isn't that interested in
furthering the web, and Microsoft has thrown in the towel and skinned Chromium
as many others. Not sure who else would have commented/been mentioned.

~~~
mistersquid
> Safari isn't that interested in furthering the web

On macOS 10.15.2 (19C57) using Safari 13.0.4 (15608.4.9.1.3), the proofs of
concept mentioned in the article yield

> The previous tab is safe and intact. window.opener was null; mischief not
> managed!

Perhaps your dismissal of Safari is presumptive and mistaken.

