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>
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
can change the URL and other things.
The reason they refuse to properly address the issue is because it would
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
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.