Target=“_blank” – the most underestimated vulnerability ever | Hacker News Reader

Target=“_blank” – the most underestimated vulnerability ever

jitbit.com

105 pointsantibland13 comments

It's called Reverse Tabnabbing on OWASP: 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...

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

Proof of concept:

https://mathiasbynens.github.io/rel-noopener/

window.opener = undefined; takes care of the problem

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.

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

> 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.

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

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?

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

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.

> 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.

I think aspects of this should be fixed in the standards. Firefox should definitely fix it. Make it readonly or even non-readable by default when the child domain is different to parent. Have the parent decide.

Security issues need secure solutions, right?

I don't actually see the utility in allowing open access from child page to parent page, especially when cross-server is a factor. There are similar other issues that have been closed. Why not this one?

Reply on news.ycombinator.com