On 11/30/2016 05:23 PM, Ian Hickson wrote:
On Wed, Nov 30, 2016 at 4:49 PM Michael A. Peters <mpet...@domblogger.net>
wrote:


Right now the specification for window.opener() is seriously insecure,
allowing for cross-domain script access by default.


I believe that's a bit of an overstatement. There are certainly risks
involved in window.opener (they're briefly discussed in the spec itself),
but it doesn't remove the origin checks.



Actually it does. Site A can link to Site B on a completely different domain and JavaScript on Site B has access to the window for Site A and can change the URL and other things.


The reason they refuse to properly address the issue is because it would
break OAuth.


I'm not sure who "they" is here, but since this is the first this topic has
come up on this list, would you mind providing us with some background?

Yes, I apologize, this was written in frustration and I should have calmed down.

Browsers are implementing rel="noopener" as a fix. A wrong fix, I have never heard of an attribute on an element being used to define script security for a window but that's how it is being addressed.

It is a fix that is not ideal. Archived web pages won't have the fix, and anchors in web applications are created by many different processes and plugins - both when the page is served and via ajax after the page the served - sometimes by the main web application and sometimes by a plugin. It is simply not realistic to ask web applications to make sure each use of an anchor with a target attribute is accompanied by a rel="noopener" attribute in order to be secure.

People at browsers I spoke with said they can only implement what the WhatWG specifies, and the rel="noopener" is the specified solution.

So I went to the WhatWG github page, found an open issue on noopener and contributed my thoughts. Was told I was off topic, and not to derail it.

So I started a new issue asking to deprecate rel="noopener" and replace it instead with a header that websites who want to allow window.opener to modify them including a whitelist of domains that could use it.

The issue was very quickly closed without any discussion based upon the issue of backwards compatibility. That was more important that fixing the insecure spec.

When digging to try and find out what was so important, a link to another topic was given where it turns out OAuth is the application that makes heavy use of window.opener

So I then came up with a different suggestion, one that doesn't break backwards compatibility, but instead allows a webmaster to send a header specifying what domains (if any) to whitelist. No header and the current behavior would be retained, but it would allow sites to secure their pages from window.opener() without having to add a rel tag to every link - a simply .htaccess directive could serve the header.

Again with absolutely no discussion the issue was immediately closed by a Google employee (and I know Google is heavily invested in OAuth) claiming that CSP is the right place for that.

But as much as I personally love CSP, virtually every webmaster I have talked to who has tried it has abandoned it because it was too difficult for them to implement without problems that then take hours to figure out. It apparently can be particularly difficult to configure on WordPress sites or sites that use Google Adsense or Analytics.

So Content Security Policy isn't the right place.

It is very frustrating to have such a bad security flaw that is being kept around because OAuth depends upon the flaw and have any attempt to have the specification fixed in a sane reasonable way immediately closed on the WhatWG github page.

And I confess, I'm not exactly a people person as it is, but it just really felt like they didn't care about the issues and had absolutely no interest in a solution that makes the web safer for users.

That's the history.

Something needs to be done, relying upon websites adding rel="noopener" to every case of <a href="external" target="_blanl" they serve is just not realistic and even many websites that try will fail.

But a header can be adding in one line to a .htaccess file and served with every web page. It's the right solution, the secure solution.

Whether the header is required by sites that want to allow window.opener or required by sites that want to block it - I don't really care, but a header is the right solution and a rel tag is just so conceptually broken I don't know how that even was accepted.

Thank you for your time, I apologize for the tone of my earlier post.

Reply via email to