Target=”_blank” is an underestimated vulnerability • Hacker News Board

Re: Target=”_blank” is an underestimated vulnerability

#21

Post by ptoomey3 » Wed, May 04, 2016, 11:10 PM UTC

ptoomey3 wrote: post #20

nailer wrote: post #19

Earlier quoted context omitted.

Re: http://lcamtuf.coredump.cx/switch/ , couldn't browsers simply do a better job of showing the address when window.location.href is 'data:text/html;-peak.us/banking_interface/' or any other data URL? Re: malicious sites linking back to a parent that opened the, could browsers not also disable cross-origin .opener?

Sure...but that is another thing that needs to be added to all browsers; it begins to feel like a game of whack-a-mole. In the end, browsers rely on an admittedly fragile premise...the only thing that guarantees your current location is a persistent awareness of what domain you are on. Most of the time that works for savvy users (normal users have no fighting chance/nor should they be expected to have to do this). Bu…

Another benefit of implementing it in CSP is that you could retroactively fix existing sites without having to go back and fix up potentially thousands of links that didn't set the attribute mentioned in this article.

Re: Target=”_blank” is an underestimated vulnerability

#22

Post by mmems » Wed, May 04, 2016, 11:17 PM UTC

LunaSea wrote: post #12

I reported this issue to Google, Facebook and GitHub. Google and Facebook were not interested and GitHub was already working on a fix.

Same here. I build a demo for that: https://gist.github.com/mems/df881c9495b6744b650c It's display a fake Facebook login page (just HTML and CSS). You can try with your relatives. How many people fall into the trap?

Re: Target=”_blank” is an underestimated vulnerability

#23

Post by briHass » Wed, May 04, 2016, 11:34 PM UTC

zerd wrote: post #16

I guess this is the trick 99% of porn sites use to do "pop-unders" now. Shouldn't the fix for this be in the browers?

Yep. Open requested link in a new tab, change the previous tab to some autoplay video or fake chat interface. It's not phishing exactly, but it is certainly devious.

Re: Target=”_blank” is an underestimated vulnerability

#24

Post by bandrami » Thu, May 05, 2016, 12:22 AM UTC

Which points to the fact that target= is a very bad idea in the first place. As a web developer, it's not my concern or business what window/tab combination my reader views a link in (mechanism vs. policy and all). If I decided to hijack the browser's and user's preferred target policy, then yeah, I'm opening myself up to some exposure to what that link does.

Re: Target=”_blank” is an underestimated vulnerability

#25

Post by ams6110 » Thu, May 05, 2016, 12:23 AM UTC

dakull wrote: post #17

Twitter's t.co links seem to mitigate this by issuing a 301 to the actual link thus fixing the `window.opener.location` vulnerability. I wonder if the reasons for implementing this are related or just good riddance :)

They are tracking links.

Re: Target=”_blank” is an underestimated vulnerability

#26

Post by wmil » Thu, May 05, 2016, 1:12 AM UTC

It seems like there's an easy fix... infer 'rel=noopener' by default on every https site that opens an http site. Or just don't allow http pages to redirect https pages.

It would make scam pages much more expensive while still allowing most legitimate use. And it would be consistent with existing security policies.

Re: Target=”_blank” is an underestimated vulnerability

#27

Post by gruez » Thu, May 05, 2016, 1:25 AM UTC

wmil wrote: post #26

It seems like there's an easy fix... infer 'rel=noopener' by default on every https site that opens an http site. Or just don't allow http pages to redirect https pages. It would make scam pages much more expensive while still allowing most legitimate use. And it would be consistent with existing security policies.

I wouldn't be surprised if there was legacy software that depended on this behavior. Restricting URL change to same-origin will work much better

Re: Target=”_blank” is an underestimated vulnerability

#28

Post by gcr » Thu, May 05, 2016, 2:05 AM UTC

Cpoll wrote: post #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 malicio…

How is this any different in principle than $.get("page", function(result){document.body = result;}); ?

If the attacker can run the javascript you mentioned, they've already run.

Re: Target=”_blank” is an underestimated vulnerability

#29

Post by gcr » Thu, May 05, 2016, 2:08 AM UTC

This is not a very informative article. It doesn't explain how the attack works (e.g. what is the window.opener object? how can an attacking page modify it? what's the trick and why is it important?).

Re: Target=”_blank” is an underestimated vulnerability

#30

Post by cyphar » Thu, May 05, 2016, 2:10 AM UTC

wmil wrote: post #26

It seems like there's an easy fix... infer 'rel=noopener' by default on every https site that opens an http site. Or just don't allow http pages to redirect https pages. It would make scam pages much more expensive while still allowing most legitimate use. And it would be consistent with existing security policies.

Then the scammer can use let's encrypt. The solution should be that window.opener shouldn't work cross-domain.