Live data from Hacker News

Target=”_blank” is an underestimated vulnerability

medium.com

1–10 of 56 posts

Re: Target=”_blank” is an underestimated vulnerability

#2
> PS. Interestingly, Google doesn’t seem to care.

That's not fair. They state it's a problem that is inherent to browsers, not that they don't care about the issue.

Also be mindful of Google's warning regarding the author's workaround:

> in particular, clobbering the window.opener property limits one of the vectors, but still makes it easy to exploit the remaining ones.

Re: Target=”_blank” is an underestimated vulnerability

#3
For anyone that wants to see this in action:

- Open a website, let's say google.com

- Open a console and type in `window.open("http://xkcd.com")`

- Disable your popup blocker and do it again.

- Open a console in the new xkcd window and type in `window.opener.location = "https://news.ycombinator.com/user?id=Cpoll"`

Note that Google quietly turned into my profile page. Now, imagine that it instead turned into maliciousgoogle.com, which looks just like Google, and you can see the attack vector.

Re: Target=”_blank” is an underestimated vulnerability

#4
> The newly opened tab can then change the window.opener.location to some phishing page.

This is true, and is a vulnerability I have been looking at for a while now, though I've not actually seen it exploited yet in the real world. For anyone interested, there are some pretty interesting exploits involving pages where an auth token is in the querystring and thus sent in the referer field by the browser. Also, consider what happens when you use an alert() in javascript to yank context back to the now attacker controlled tab...

> Or execute some JavaScript on the opener-page on your behalf…

Not true, this implies the "attacker" can run javascript in the context of the original page. They can only run javascript after redirecting the original page to one they control, so it's not like they can run code on the facebook.com domain, which would be a _huge_ exploit.

Re: Target=”_blank” is an underestimated vulnerability

#5

> PS. Interestingly, Google doesn’t seem to care. That's not fair. They state it's a problem that is inherent to browsers, not that they don't care about the issue. Also be mindful of Google's warning regarding the author's workaround: > in particular, clobbering the window.opener property limits one of the vectors, but still makes it easy to exploit the remaining ones.

I'd be interested in knowing the others. So would I imagine most people reading that page.

Re: Target=”_blank” is an underestimated vulnerability

#6
So quite apart from being a crime against usability, now it turns out target="_blank" is a great big security hole, too. I fear this isn't going to be solved 'the flash way' (i.e. by ditching it altogether) but just by making window.opener.location read-only (but maybe only for different domains). One can still dream, though.

Re: Target=”_blank” is an underestimated vulnerability

#9
post #4

> The newly opened tab can then change the window.opener.location to some phishing page. This is true, and is a vulnerability I have been looking at for a while now, though I've not actually seen it exploited yet in the real world. For anyone interested, there are some pretty interesting exploits involving pages where an auth token is in the querystring and thus sent in the referer field by the browser. Also, conside…

What happens if they change `window.opener.location` to a javascript: URI? I'm assuming (well, hoping) it fails to work, but it would be nice to have that confirmed.
Post reply on HN