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

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 <mpeters@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
>>> <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.
>>
>>
> 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

Received on Thursday, 1 December 2016 06:41:42 UTC