5 ms·

Target=“_blank” – the most underestimated vulnerability ever

105 points by antibland 7y ago

richardwhiuk 7y ago
The Google Bughunter page suggests that there are plenty of other ways to exploit this - anyone know what they are?
- pg_is_a_butt 7y ago
  History hijacking
hbcondo714 7y ago
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
psiinon 7y ago
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/HelpAddonsPscanrulesBetaPscanbeta#reverse-tabnabbing https://github.com/zaproxy/zap-extensions/wiki/HelpAddonsPsc...
- deleted 7y ago
  [deleted]
rs23296008n1 7y ago
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 7y ago
  It's interesting that Google is the only expected browser vender these days.
  - zamadatix 7y ago
    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 7y ago
      > 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.
  - rs23296008n1 7y ago
    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?
surround 7y ago
Proof of concept: https://mathiasbynens.github.io/rel-noopener/ https://mathiasbynens.github.io/rel-noopener/
- rasz 7y ago
  window.opener = undefined; takes care of the problem
SigmundA 7y ago
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.
combatentropy 7y ago
> 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 7y ago
  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

105 points by antibland 7y ago

richardwhiuk 7y ago

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

pg_is_a_butt 7y ago
History hijacking

hbcondo714 7y ago

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

psiinon 7y ago

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/HelpAddonsPscanrulesBetaPscanbeta#reverse-tabnabbing https://github.com/zaproxy/zap-extensions/wiki/HelpAddonsPsc...

deleted 7y ago
[deleted]

rs23296008n1 7y ago

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 7y ago
It's interesting that Google is the only expected browser vender these days.
- zamadatix 7y ago
  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 7y ago
    > 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.
- rs23296008n1 7y ago
  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?

surround 7y ago

Proof of concept: https://mathiasbynens.github.io/rel-noopener/ https://mathiasbynens.github.io/rel-noopener/

rasz 7y ago
window.opener = undefined; takes care of the problem

SigmundA 7y ago

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.

combatentropy 7y ago

> 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 7y ago
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