I guess this issue was discussed at the following thread on chromium.org, with comment #10 offering the more interesting exploit vector that seems to happen on sites with user-generated content (UGC):
https://bugs.chromium.org/p/chromium/issues/detail?id=168988#c10 ... and Comment 11 right after it: https://bugs.chromium.org/p/chromium/issues/detail?id=168988#c11 <-- although i guess this would only apply if the link was target="_blank" such that it does open in a new window, which is pretty common practice on UGC sites anyway. ... and as Michael pointed out, this bug got closed on the count of rel="noopener" I get Michael's point that securing an existing site with UGC content is going to be a somewhat painful proposition, although one could craft a one-liner piece of javascript which would use the DOM to add or augment the "rel" attribute to anchors. This should be easily done on Wordpress sites as a template footer, or in the header on document ready. This would alleviate your having to modify the HTML code for every single link, as I too would hate to liter my anchors with more unsightly attributes. I remember using window.opener to change a parent's location since the late 90's, this behavior has been around for a *long time*, so i could see why browser makers would be more than a little reluctant to "deny by default" and require site makers to add an extra http header to "allow" the behavior. But if I understand Michael's proposed behavior correctly, we would allow sites to set a header as such: X-Child-Context-Control-Allow-Domains: *foo.com <http://foo.com>, bar.net <http://bar.net> * <-- some sites are allowed X-Child-Context-Control-Allow-Domains: *none* <-- no sites are allowed X-Child-Context-Control-Allow-Domains: ** *<-- this header is unnecessary because it is the default behavior or all browsers ... *XCCCAD *for short (for lack of snazzier acronym) ==> when this header is not present, the current behavior applies, which means most sites are "insecure by default". ==> sites who do wish to secure themselves could set the above header and browsers would forbid child windows from controlling parent windows, aside from listed exceptions. This would: 0) complement, not replace rel="noopener" 1) retain current backward compatibility 2) allow sites to secure themselves more globally with a simple .htaccess rule. (instead of having to modify their anchors manually or via the DOM) The above proposition might remind you of CORS: Access-Control-Allow-Origin: * http://enable-cors.org/server.html However the above proposed behavior would be exactly opposite to that of the CORS behavior, and I think that it makes perfect sense, because the situation we're trying to address, is the exact opposite of the situation that the CORS behavior was looking to address: - Sites are "secure by default" in that they don't allow their content to be accessed by a browsing context outside of their host/domain, as this is every browser's default behavior. - Adding the CORS header enables sites to make themselves less secure by instructing browsers that other sites can load their content via, say, an XmlHttpRequest. I think the devil would be in implementation detail. Slapping a "rel/noopener" attribute on a specific link is very deterministic and straightforward from a logic standpoint ---- Whichever window was created from this link can't control the parent. In the case of an *XCCCAD *header we need to specify when it would be in effect. And I think it might be as simple as "it applies to all windows opened from the HTML document which was served with this header in the response headers". On Wed, Nov 30, 2016 at 9:33 PM, Michael A. Peters <mpet...@domblogger.net> wrote: > On 11/30/2016 06:21 PM, Michael A. Peters wrote: > >> 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. >> >> > Here is easy demo showing the blatant cross-domain scripting vulnerability. > > <!-- put this page as a.html on foo.com --> > <html> > <head> > <title>Test target link</title> > </head> > <body> > <p><a href="https://bar.net/b.html"; target="_blank">link to different > domain</a></p> > </body> > </html> > > <!-- put this page as b.html on bar.net --> > <html> > <head> > <title>Test window.opener</title> > <script type="text/javascript" > > if (window.opener && !window.opener.closed) > opener.location = 'http://www.example.org/' > </script> > </head> > <body> > <p>The page on foo.com will have changed to http://www.example.org/ > because this page had script access to that window. Obvious very serious > phishing concern, and probably other concerns</p> > </body> > </html> > > -- Chris Holland http://www.linkedin.com/in/chrisholland 310-500-7598
