8 ms·
About rel=noopener
- mindcrime 10y agosigh 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.
- dmnd 10y agoHN 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.
- lumpypua 10y agoI have no idea what this submission is about. Why would I want rel=noopener?
- notatoad 10y agoThe original title (and the point of the article) was about the security problems target=_blank has. You want rel=noopener because the page it navigates to can't affect the content of the opening page.
- kderbe 10y agoIt would be helpful if you stated what the original title actually was, especially now that you have the top-level post!
- mindcrime 10y agoIt was something like "TIL: target=_blank is harmful"
- unimpressive 10y agos/harmful/insecure/ IIRC.
- mindcrime 10y agoOh yeah, I think you're right. Anyway, it was something along those lines.
- teej 10y agoThis is the new pop-under. Sites trying to serve as many ads as possible will open links with target=_blank and redirect the old window to an ad.
- yxhuvud 10y agoYeah. This is amazingly irritating.
- happyslobro 10y agoSo that's what's happening! With uBlock, all I see is a flicker on the browser's tab bar, and my history is gone. It's still annoyingly retarded.
- gorhill 10y agoI did try to provide a fix for the history-lost case for when a popunder is blocked, but in the end I had to give up because there was no way to make it work reliably (using current extensions API). [1] https://github.com/gorhill/uBlock/issues/1028 https://github.com/gorhill/uBlock/issues/1028
- happyslobro 10y agoHa, no worries, I wouldn't have expected an ad blocker to know that for me, the dead tab and this new tab are semantically one. I'm just glad that the bad tab is dead. It's the ad that I was calling retarded :p Awesome work btw, it runs like greased lightning in FF nightly.
- eli 10y agoBut doing what you describe doesn't rely on this window.opener security issue, right? Of course any site that can open popups can open popups and then also redirect somewhere else. (Also, I'm not sure I've personally seen that)
- deleted 10y ago[deleted]
- _RPM 10y agoDoes this "work" for cross origin requests? If I plant a `target=_blank` in my website, user clicks it, goes to my second website, do I have control over the website the link came from? If not, I don't see the security issue. Of course you can XSS yourself, what have you.
- educar 10y agoYes, it says so lower down the article.
- kalmi10 10y agoTo some extent.. Yes. The attacker can replace the current page with his own phising page. Of course, the hostname part of the url would change, but the user is unlikely to notice that.
- colejohnson66 10y agoCase in point: People still fall for things like `facebook.com.totallynotaphishingsite.com'
- deleted 10y ago[deleted]
- mort96 10y agoIt's a huge difference between clicking on a random facebook.com.totallynotphishing.com link, and being on the legitimate facebook.com and having that tab automatically go to a phishing site while you're not looking.
- donatj 10y agoWell I just had an "Oh sh*t" moment thinking about all the websites I built over the years at my old company that had target=_blank to commentors sites... Aw crap. Not my problem anymore, but I never even considered this.
- knowtheory 10y agoMaybe you could send them a note? Do you know anybody who's still working on the project?
- donatj 10y agoIt's a complicated situation. They owe me a bit of money and don't reply to any of my emails.
- colejohnson66 10y agoCan't you sue them then? Or at the least threaten to sue?
- lsaferite 10y agoFor future reference, IP transfer on final payment.
- donatj 10y agoIt's quite complicated really. I had been their lead developer, having worked my way up over a five year period with the company. My leaving was very cordial. I had been there a long time and they understood me wanting to grow. I started a project on the side for them almost immediately after I left because I knew they needed help. I had a medical emergency (my tonsils swelled to the point where I could not breathe) and ended up needing surgery, so before the surgery I gave them the work that had been completed (By my estimate 80%) so they could finish the rest. They told me to get better and we would discuss how to handle the partial payment after my surgery. While recovering, two of my former coworkers quit and took jobs at my current company. I had nothing to do with this. This is when my old company threatened to sue myself as well as them. Sigh. Our cooperate lawyer came back at them about them having no case and they soon dropped the whole thing. I tried to pursue what I was owed, first emailing my contact and after receiving no response to a handful over several months beginning to loop in lower and lower managers I knew. I'm genuinely not sure if they had all been poisoned against me or if there was just some sort of email filter enacted, but I never heard a response from any of them. Several years later they declared bankruptcy. I contacted their lawyer who informed me that only debts incurred within the last 6 months were perusable, and the money they owed me was not be perusable. Sigh. They are still in business now several years after the bankruptcy restructuring but on a skeleton crew. I don't believe I have any ability to pursue the money for the project now. The whole ordeal was incredibly frustrating. It actually really saddens me as I LOVED that job and my coworkers there.
- pmalynin 10y agoThis is a pretty old bug, I think I reported it a few years ago to Google. EDIT: 2013 to be exact.
- jaredsohn 10y agoFYI, the article links to a Chromium issue from 2013: https://bugs.chromium.org/p/chromium/issues/detail?id=168988 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.
- pmalynin 10y agoWell 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.
- ptoomey3 10y agoI 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/ http://lcamtuf.coredump.cx/switch/.
- jklinger410 10y agoThs is a problem for Browsers, not developers. target=_blank is too embedded into the web.
- jay_kyburz 10y agodevelopers can fix the problem for their users.
- jklinger410 10y agoIt's more expensive for a web dev to fix this than a browser to prevent it.
- detaro 10y agoIf you open a page of your own site that then redirects to the target (like some pages do, presumably to hide the exact source URL in the referer-header before there was a header for it), is the opener-reference broken?
- doughj3 10y agoI'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?
- cgm616 10y agoSame here on Firefox for iOS. Both links show the "hacked" text.
- illuna 10y agoIt'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.
- kaoD 10y agoMaybe the page changed? I see 3 links: non-Cross-Origin, Cross-Origin and noopener. The third one doesn't "hack" the page for me.
- Dru89 10y agoWhat is the correct way to force a link to open in a new tab, then? Unfortunately "let the user decide" is not the best answer if you want to link to something like "terms and conditions" in the middle of a sign up flow or something. If the user doesn't know how to open it in a new tab on their own, this can be extremely frustrating I'd imagine.
- illuna 10y agoLinking 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 consideration when linking to arbitrary pages, but when you own the destination (and trust that your site has no other security issues) then this becomes a non-issue.
- ddoolin 10y agoIs there a practical reason that a reference to the opener window is given to the opened window? That seems like something we could do without.
- krastanov 10y agoExample: Google Slides where one tab has the presentation and another tab has the speaker notes. You want those to be in sync.
- sjwright 10y agoBut presumably this example is not cross-domain. This behaviour should not be allowed by default for cross-domain links!
- nsgi 10y agoThere are plenty of other ways to do this e.g. web sockets or localStorage.
- acdha 10y agoNow, yes, but a lot of precedent was set before then. Even now both of the technologies you mentioned would add significant complexity – needing to start running an otherwise unnecessary WebSocket server, having to debug and workaround client bugs or network issues like large organizations blocking WebSockets.
- zspitzer 10y agowouldn't a simple solution be <base rel="noopener">
- homakov 10y agoThey ever heard of "security by default"? I guess no.
- qznc 10y agoSecurity is hard, especially if your opponent is more clever than you. For example, the internet years later.
- bzbarsky 10y agoIn the early to mid '90s, threat models on the web were quite a bit different from now.
- homakov 10y agoI was implying "make it a default for everyone, now"
- bzbarsky 10y agoRight, but now you have 20 years worth of content which depends on the current behavior....
- homakov 10y agoOn this particular behavior unlikely
- bzbarsky 10y agoWhat makes you think this is unlikely? On the contrary, I think it's _very_ likely there are things depending on it. I don't expect there to be a huge number of them, but I also expect them to disproportionately be in things like intranet deployments where it's hard to even get measurements. :(
- homakov 10y ago
- stormbrew 10y ago> 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?
- epidemian 10y agoAgreed. 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)?
- reitanqild 10y ago> I doubt that many sites rely on this broken behavior. Any web based system where a pop up dialog is opened to allow the user to select something that is then inserted into the original page?
- epidemian 10y agoGood call! I guess i haven't seen any of those. But i've seen some internal web based systems that relied too heavily on popup windows and started breaking when tabbed browsing became a thing and brosers started blocking popup windows by default, so i don't doubt that there are probably systems out there relying on this weird behavior of target=_blank. For those systems, though, i'd imagine most of them would have these popup windows on the same origin, right? So having browsers prevent child windows changing their parent's location if they are cross-origin seems like a sensible idea, or am i missing something else?
- deleted 10y ago[deleted]
- adrianN 10y agoNoScript saves the day again.
- etatoby 10y agoYeah, except breaking 99% of the modern Web. NoScript has its place, for example in the Tor browser or in other high-security applications, but it's too much of a burden for everyday use.
- gkya 10y ago> NoScript [is] too much of a burden for everyday use. No it is not. It actually removes most of the burden from my daily browsing. Modern web is mostly a bunch of obstacles between the user and the information, and with NoScript (or xombrero in my case) the user skips over that. I believe most of the users don't care about layouts, transitions, syncing between tabs, etc, it's all designers' and marketers' caprice.
- pdkl95 10y agoIf your website breaks without Javascript, then it's the website's fault for not properly implementing progressive enhancement. Javascript is useful to enhance the page with better features, but the page itself should work without it. If you tools/framework make this hard or generate output that incompatible with progressive enhancement, then I suggest you find (or write) better tools.
- Strom 10y agoI do wonder for how many sites does this actually make sense to do. Take the number of users who use NoScript and are not willing to turn it off when the site doesn't work without JS, and then take the subset from those who would actually be willing to pay for using the website. [1] Do these niche users really generate enough revenue to pay for the toolchain & work culture changes necessary to have this progressive enhancement? What's more, this group of users doesn't even receive the charity boost that some other niche groups like the visually impaired might receive, that would lead to changes even without direct financial sense. [1] Being NoScript users, they most likely also run some sort of ad blocker, so ad revenue from them is likely zero.
- carey 10y agoIn the right circumstances, which as far as I can tell are when crossing between security zones, Internet Explorer and Edge already seem to block this. I've never been able to pin down exactly what's happening, or to get Google login to work on our intranet sites with IE as a result.
- deleted 10y ago[deleted]
- vortico 10y agoNote that all the opened page has control over is closing and changing the address of the tab. You can't insert HTML into the page, for example. Phishing seems to be the only problem this creates, but no more.
- jaredsohn 10y agoI built a quick userscript that treats rel="noopener" as default for links with target:"_blank". It could be worth checking out if you want to avoid experiencing this security issue yourself (but I offer no warranties) or if you want to see if it would break any site you visit if browsers would enable the behavior by default. https://github.com/jaredsohn/noopener_by_default https://github.com/jaredsohn/noopener_by_default
- nsgi 10y agoThere should be an option in content security policy to prevent this on all links.
- Grom_PE 10y agoSome time ago I was surprised that my Google Search page was replaced by something else after I returned from some spammy page (opened in another tab). As the browser I use, Opera 12, also treats all links manually opened in the new tab as if they had target="_blank", giving them opener access, I decided to remove the window.opener altogether by replacing the "opener" string with "opera" in the opera.dll. This way it gets overwritten by the normal window.opera variable and is essentially hidden. So far I haven't encountered a site legitimately relying on this behavior.