wouldn't a simple solution be
About rel=noopener
21–30 of 115 posts
Re: About rel=noopener
#22They ever heard of "security by default"? I guess no.
Re: About rel=noopener
#23I'm using Chromium and even the link with `rel=noopener` seems to be able to "hax" the first page. Am I reading it wrong or is `rel=noopener` supposed to protect against this?
It's a bit confusing if you didn't pay close attention to the article, because neither link actually show the `rel=noopener` fix.
Instead, the two links present two different angles to the same problem. The first link demonstrates the attack using a page within the same domain (reasonable), and the second demonstrates that it will continue to work even when the link points to a page ordinarily restricted by cross-origin policies (potentially surprising).
If you manually add `rel=noopener` to either link, the attack won't work. Try it with DevTools.
Re: About rel=noopener
#24sigh This is a perfect example of a title that should not have been changed. The original was objectively better than the current one. If you don't already know what rel=noopener is, you'd have no reason at all to click through on this. But the earlier title actually explained something about the content on the other end of the link.
HN submissions are kind of like startups. Often you have to break the rules to get off the ground. But once you have some lift, it's time to become boring and straighten out.
Re: About rel=noopener
#25Earlier quoted context omitted.
FYI, the article links to a Chromium issue from 2013: https://bugs.chromium.org/p/chromium/issues/detail?id=168988 which links to another issue from 2012. Edit: My purpose was to confirm the bug has been "known" for awhile, not to take away credit for you reporting the bug years ago. Congrats for independently discovering it before many people (such as myself) became aware of it.
Well there you go, although I submitted it trough a different channel. For sure, I think its a very important bug that hasn't had much attention for years now, especially since so many websites use _blank, GMail being one of them.
I get that linking from a "trusted site" to a "not trusted site" is probably of greater concern. But, this `noopener` does nothing to address a similar attack demonstrated here: http://lcamtuf.coredump.cx/switch/.
Re: About rel=noopener
#26> Note that this also works when index.html and malicious.html are on different origins — window.opener.location is accessible across origins!
... Why. Why would anyone (not maliciously) consider this desirable behaviour?
Re: About rel=noopener
#27[deleted]
Re: About rel=noopener
#28NoScript saves the day again.
Re: About rel=noopener
#29> Note that this also works when index.html and malicious.html are on different origins — window.opener.location is accessible across origins! ... Why. Why would anyone (not maliciously) consider this desirable behaviour?
Agreed. But what's more intriguing to me is that the proposed "solution" is to add yet another hack on top of that (rel=noopener), instead of doing something to fix the broken behavior of target=_blank.
I doubt that many sites rely on this broken behavior. And even if they do, browsers could still block it and show some warning to the user "Hey, this tab that just opened wants to change the URL of this other tab [allow, always, nope, never]", just like they do for popup windows or sites with broken SSL certs.
Does someone with more experience in these kind of issues know why it was decided to put the responsibility of fixing this on individual websites (rel=noopener) instead of browsers (blocking the URL changing or showing a warning)?
Re: About rel=noopener
#30Earlier quoted context omitted.
Linking to stuff that you control is okay, because you know and control the contents inside the new window. So your example (terms and conditions created by you) is totally cool. As described in the article, it is dangerous when the link's destination is not controlled by you. That destination has access to its opener's window and could potentially change the url to eg. a malicious look-alike of your site. It's a con…
This is one of the reasons why FB et al go to a special link before opening the actual target site.
That's more of a happy accident. Their primary reason is to track things.