W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2016

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

From: Michael A. Peters <mpeters@domblogger.net>
Date: Wed, 30 Nov 2016 18:21:34 -0800
To: whatwg@lists.whatwg.org
Message-ID: <8a983c9e-93f6-883c-8587-3f4887aa9c29@domblogger.net>
On 11/30/2016 05:23 PM, Ian Hickson wrote:
> On Wed, Nov 30, 2016 at 4:49 PM Michael A. Peters <mpeters@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.
Received on Thursday, 1 December 2016 02:36:52 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:40 UTC