> When the user interacts with content, things can also go wrong. One example that causes user frustration is when clicking a link opens the desired destination in a new tab, while the main window navigates to a different, unwanted page. Starting in Chrome 65 we'll also detect this behavior, trigger an infobar, and prevent the main tab from being redirected. This allows the user to continue directly to their intended destination, while also preserving the context of the page they came from.
Note that developers could protect their sites for some time with noopener: https://mathiasbynens.github.io/rel-noopener/
One of these inspired me to make a Firefox add-on that solves this issue:
Personally I use linting rules for this, e.g. for React projects https://github.com/yannickcr/eslint-plugin-react/blob/master...
"Unfortunately, we believe that this class of attacks is inherent to the current design of web browsers and can't be meaningfully mitigated by any single website; in particular, clobbering the window.opener property limits one of the vectors, but still makes it easy to exploit the remaining ones."
Chrome does support rel=noopener, _and_ the "fairly good demonstration" that page links to doesn't work in Chrome any more.
In the example that Google's page links to they change it to a data: URI - which no longer works in Chrome - but they could just as easily change it from http://good.com/ to http://evil.com/ - which would still work in Chrome - and hope you don't notice.
That's why Google says it's still easy to exploit the other vectors for the attack. A website can protect itself by clearing "window.opener", but similar attacks are possible that a website can't prevent. e.g. A window can't prevent the window that opened it from later forcing it to navigate to a different URL.
Target=“_blank” is your problem. That’s where Window.opener gets exposed. You’re better off finding the “_blank” definition and renaming it so that it’s never triggered, or assigning it to the definition of “self”, etc.
Also, window.opener is still abusable if I middle-click links to open in a new tab. I was very surprised when my Google Search tab got replaced by something else after I middle-clicked on some questionable link.
I agree window.opener was a fairly dangerous addition, but it is subject to CORS restrictions. You can't access it from just anywhere.
I would rather that web browsers simply not implement things with significant potential to do harm; at the least, those things should be disabled by default. Unfortunately we aren't headed that way: WebUSB is coming. Anyone who could write that "[t]he composablity of the web allows a new ecosystem of hardware support to be built entirely from web technology" without feeling a chill run down their spine and imagining a years-long security nightmare is truly blind.
Are people really considering this? People that, y'know... matter?
edit: good lord, I read further and saw this:
3. Security and Privacy
This section is non-normative.
Yes, let's put the burden of protecting users from browser-transmitted malware on to the hardware manufacturers, who've had a such a wonderful track record of caring about and protecting their users' security in the past. What could possibly go wrong?
No. "Security and privacy considerations" sections of standards documents are typically used for a analysis or discussion of the security/privacy posture of the standard. The security features are "baked into" other portions of the document.
You can't access things via opener but you can change the location of opener, that's an easy target for phishing.
Not that much. Both have some conflicting interests, and plenty of aligned interests.
Testing has shown that this doesn't work in practice, and instead achieves the opposite: the user in confused as to why they are in a new window, and it's harder for them to return to your domain. The user is confused by the ostensible "pop-up" (that they associate with ads) that has opened, and the Back button no longer returns them to our domain, breaking with their expected behavior.
Users know how to open links in new tabs/windows if they want to. In testing at the places I've worked target=_blank only hurts conversions. Personally I run a plugin that strips it from all links.
Is there any research you can point me to about this?
'...and the Back button no longer returns them to our domain, breaking with their expected behavior.'
Yeah, except when the target site has disabled it and then you have even more confusion. (Accepted it is rare, but it does happen).
An oft-parroted best practice in UX is "effective user interface places users in control of the application." This study seems to agree:
>Many of our study participants moved to a new site or subsite without realizing it and then struggled to get back to the main site because the subsite offered no option for return
Using target=_blank ensures the Back button is broken. A third-party site disabling the Back button is out of your control.
> target="_blank" rel="noopener noreferrer"
Which should not break anything unless you have some weird HTML lying around.
why not make rel="noopener noreferrer" default?
if sites want to get credit they can explicitly add rel="opener referrer"
The postMessage API provides a safer way for Windows/Tabs to communicate.
Even then, there is a risk of being surprised. If you open a page on the same site, you may expect that scripts on the opened page can't access the opening page: but because of CORS they can.
Here's a fiddle with a link to another fiddle that copies the contents of a password field from the first fiddle: https://jsfiddle.net/u6rmc49c/3/
The same origin policy for DOM access allows setting the location.href attribute (getting any attribute is still disallowed).
Setting location.href also works with frames in both ways, e.g. frame.location.href as well as parent.locaton.href and top.location.href
Essentially one can trick a user into typing their credentials into a phishing site although it may appear they are using the legitimate site at first glance.
The reason this is unfixed is that this is how the web works still.
If the newly opened website has full control over the Facebook tab, can't the attacker directly modify the html in the opener to pop up a form asking for a password?
This would be stronger because the address would not change.
Could the attacker reach into the Facebook tab and pull any information from it?
As this article says, you can change the location of the window.
Doesn't Google's browser hide the address bar !? Hiding the address does make exploits like this way harder to notice. I know Google want's everyone to search instead of typing an URL. But URL's are really powerful, please Google, don't make them irrelevant!
Huh? What are you talking about? All mobile browsers I'm aware of hide the address bar when you scroll down, not just Chrome.