11–20 of 56 posts
Actually thinking about it more, it's same world that connects to remote servers over plaintext telnet. Oh and you don't need to verify your identity either, user's will just say who they are and we'll trust them.
> 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.
> Blocked a frame with origin "https://www.google.com" from accessing a frame with origin "https://news.ycombinator.com". Protocols, domains, and ports must match.
When executing
window.opener.location = 'javascript:alert(1);'> 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.
The attack I linked to originates from the malicious site and links to the trusted site (the reverse of the attack in this post). There is nothing a site can do to prevent this since there is no way for a linked to site to prevent the linking site from getting a window reference to it. So, imagine a scenario like this:
* trusted site implements the guidance here and links to malicious site.
* The malicious site, detecting that they can't get a reference to "window.opener" immediately opens a new tab back to the trusted site (maybe to the login page if the site has any logout CSRF issues).
* The user is slightly confused, but they were just on the trusted site, so it doesn't feel too strange.
* If the user is super savvy, the look up at the URL bar and are assured that they actually are back in the trusted site (possibly staring at a login prompt).
* the attacker has a reference to the window they opened back to the trusted site. They set a timer for a couple seconds (like the attack I referenced above). After a few seconds they change the trusted site to load a malicious site and/or malicious data URL.
* user "logs in to the trusted site" and gives up their creds.
How are rel=noreferrer and rel=noopener equivalent in Firefox?
I wonder if the reasons for implementing this are related or just good riddance :)
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…
First we had pop-ups that opened on top of the current window
Then we had pop-unders that opened behind the current window
Now we have... what? pop-switches? that open your link target in a new window and change the source page to the "pop(-up)" behind your back.
Impressive idea, I opened both windows on purpose so they couldn't be blocked or else I wouldn't get to my content and one was transmogrified to an ad page behind my back.
Earlier quoted context omitted.
I'd be interested in knowing the others. So would I imagine most people reading that page.
I mentioned this on another related thread: https://news.ycombinator.com/item?id=11554080 . In short, the solution here only closes one of potentially many other similar attacks: http://lcamtuf.coredump.cx/switch/ The attack I linked to originates from the malicious site and links to the trusted site (the reverse of the attack in this post). There is nothing a site can do to prevent this since there is no way for a l…
Re: malicious sites linking back to a parent that opened the, could browsers not also disable cross-origin .opener?
Earlier quoted context omitted.
I mentioned this on another related thread: https://news.ycombinator.com/item?id=11554080 . In short, the solution here only closes one of potentially many other similar attacks: http://lcamtuf.coredump.cx/switch/ The attack I linked to originates from the malicious site and links to the trusted site (the reverse of the attack in this post). There is nothing a site can do to prevent this since there is no way for a l…
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?
In my opinion, the better place for a more holistic fix to this is within Conntent Security Policy. That could, theoretically, address all attacks that somehow obtain a window ref. The CSP policy could say "window-ref: 'none'". That would be a declarative policy that the browser could enforce in any situation where a window ref might be available.