Deprecate rel="noopener"

[AliceWonderMiscreations]

It is my opinion that the rel="noopener" is the wrong solution to a very serious problem.

The way I look at things, when it comes to security, maintaining backwards compatability is less important than protecting the end user who often does not have a clue how things work underneath making them vulnerable in cases where geeks are less likely to be vulnerable.

The basic problem that rel="noopener" is attempting to address is the issue of Window B, opened by Window A, by default having some script access to modify Window A.

The obvious exploit is a phishing exploit where Window A is a window the user trusts. They follow a link to Window B and Window B then changes the URL to Window A.

The user doesn't realize Window A has changed (especially problematic on mobile where the URL is often hidden) and their trust in Window A is then exploited for phishing.

This is an incredibly serious problem. This bug in specification for window.opener() is probably not limited to the phishing scenario, it probably can be exploited in many other ways as well.

The solution of rel="noopener" I believe is the wrong the solution to the problem. A user does not expect that opening a link in a new window results in the window they were coming from being vulnerable to a cross-site or cross-window scripting attack.

For a window to allow another window to have script access by default, that is a very broken default. By default no window other than Window A should have script access to Window A.

If Window A is to allow another window to have script access to it, the server should be required to send a header specifying a domain white list before the data for Window A is sent.

A header can not be modfied after data is sent, making it the secure mechanism by which a domain whitelist can be sent. This is why Content-Security-Policy uses a header, for example. It probably would be okay for the Same Origin to be the default white-list if the server does not send a header, but when the server does send a header, then only domains specified should be in the white-list. I would recommend using the same type of domain list that CSP uses just for consistency.

When Window B then wants script access to Window A, if the domain for Window B is not in the white list sent with the content for Window A then Window B can not use window.opener().

An insecure default secured by an attribute is wrong for several reasons:

• It requires knowledge on the part of the webmaster
• It is subject to typographical errors by the webmaster that are not likely to be caught in testing
• It is part of the DOM and can be altered the page is created
• The user should not be expected to look at the web page source to determine if they can trust the window

By changing the specification so that a header is required for window.opener() to work, there will be a backwards compatibility problem. I suspect (no stats) that could be reduced by allowing Same Origin by default when no header is sent, but there still will be a problem.

However it is a problem that is relatively easy for webmasters to fix. Sending a header can easily be done through a .htaccess file (or equivalent in non-Apache) or in the configuration of a front-end proxy. The change is minor in scope and I suspect window.opener() is only used by a small number of websites.

The rel="noopener" solution however is highly problematic, to achieve security for the end user, far more websites must correctly implement it and it can not be implemented just by sending a header, it can only be implemented by modifying the content served to the end user.

It requires a code change to web applications, a far greater number of web applications, and it is easy for a mistake to occur where it is not fully implemented because some CMS plugin or Ajax call or something creates links that don't include the rel="noopener" tag even though the web application does.

Requiring the rel tag to be secure is extremely problematic for archived web pages, especially web pages created before the rel="noopener" tag was even specified. Either all archived pages that open links in new windows have to be modified in their archived state, or modified on the fly as they are served, or they are vulnerable to the bug in the specification.

Archived pages are more likely to have link references to domains that have expired, making them an attractive target for attack because domains are cheap to register.

This is a serious problem, and requiring a header to white-list domains is the only solution that maintains some backwards compatibility (honestly I personally would prefer to just get rid of window.opener() and require service workers and Ajax for that kind of function) while protecting the end user who knows nothing of the vulnerability and is thus extremely vulnerable to being fooled by malicious websites that will continue to exploit the fact that many websites, out of laziness or ignorance or coding mistakes, won't include the necessary the tag to protect the users.

So please deprecate rel="noopener" and instead require a whitelist header for pages that want to allow access.

I mean no dis-respect, but I do not believe the rel="noopener" solution was very well thought out.

[annevk]

Basically, you are correct, but breaking a non-trivial number of pages is not an option we have. Therefore we are stuck with a bandaid rather than a proper security model. Sorry.

[AliceWonderMiscreations]

And this is exactly why the Internet will continue to be an insecure cesspool. Enjoy it and have a nice day.

Seriously, I find it incredibly moronic that backwards compatibility matters more than security and this issue is just closed without proper discussion.

[annevk]

We've had this discussion quite a few times in the history of the web already. Starting over is not an option.

[alastc]

Is it an option for browsers to default to Same Origin unless the site specifies otherwise? If so, where would be the best place to suggest that?

[annevk]

No, we basically cannot change the status quo other than through opt-in.

[annevk]

(This is the right place for suggestions to changing the processing model around links and browsing contexts, etc. I suppose you could file a new issue that is more scoped, but I recommend reaching out to some browser vendors first by seeing if they're even willing to change their processing model.)

[Boldewyn]

Are there any numbers available, which sites would break? And more specifically, what'd be the number of pages using that "feature" for windows within the same origin?

[hashbangperl]

How many of the Alexa 1000 sites would break, really - it's not a widely used feature at all, and almost all instances would be on the same domain, so allowing that would mitigate almost all the breakage.

WONTFIX really isn't an adequate answer.

[annevk]

Are there any numbers available, which sites would break? And more specifically, what'd be the number of pages using that "feature" for windows within the same origin?

For that kind of information you'd have to ask a browser vendor to measure things for you. It's my understanding not much has been done here because of, e.g., #2047 (comment).

If we could make breaking changes that were largely compatible and would improve security we would be making them.

[AliceWonderMiscreations]

What is the reason they can't be made? So that silicon valley companies can charge consulting fees to "secure" web applications?

Seriously it makes no sense whatsoever to keep an insecure specification insecure.

[AliceWonderMiscreations]

With respect to OAuth, a system I personally never liked because it is a privacy tracking nightmare, it seems that OAuth would want the website using a header to specify where it can come from to prevent man in the middle type attacks that could potentially happen if an attacker managed to modify the href attribute of the page opening the OAuth link.

But I've always suspected the real motivation behind OAuth was user tracking for advertising purposes, just look at the companies behind it.

[AliceWonderMiscreations]

btw if OAuth is the issue, I hope I'm not the only one who finds it highly ironic that a so-called security product requires an insecure Internet to function.

[TiddoLangerak]

Just a quick thought: when a website goes fullscreen then browsers display a notification that informs the user about this, to prevent phishing attacks. Wouldn't it be possible to implement a similar mechanism for the noopener issue? This would maintain backwards compatibility, and allows for a secure mechanism without notification to be implemented in parallel.

[annevk]

Yeah, something like that might be feasible. Do you know where to file bugs against browsers? If two browsers pick something like that up it might be worthy to add something about it to the standard to encourage others to follow.

[Boldewyn]

Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1321305

Feel free to use that as template for bugs to the other ones.

[AliceWonderMiscreations]

I came up with another solution that doesn't break backwards compatibility. I created a new issue -

#2122

Unfortunately the new issue was closed within 10 minutes of posting it, based upon logic that CSP is doing it, without taking into consideration that CSP is far too cumbersome for many sites to deploy (no scripts in the body, etc.)

Would appreciate some discussion in that thread as I believe the suggestion there is workable since it does not break any existing web applications.

Thank you for your time.

[TiddoLangerak]

Chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=670203
Edge bug: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/10022307/