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: Thu, 1 Dec 2016 19:44:35 -0800
To: whatwg@lists.whatwg.org
Message-ID: <10b427a7-70c5-f258-eab7-769f3ae3f176@domblogger.net>
If window.opener() did not work cross-domain then as far as I can tell 
that would be secure.

On 12/01/2016 07:23 PM, Richard Maher wrote:
> I see what you're saying Michael and also agree it's serious. Would I be
> correct in thinking that MS Edge solves the problem by not returning
> window.opener cross-domain? Is the UA not a logical and uniform place for
> this?
>
> BTW I've also experienced the CitHub topic-closure nazis many times :-(
>
>
> On Fri, Dec 2, 2016 at 10:42 AM, Michael A. Peters <mpeters@domblogger.net>
> wrote:
>
>> Well if it was done as a header, I suppose it could be added as a
>> http-equiv meta tag for those who want to.
>>
>> Header is the easiest solution to make sure it is applied everywhere
>> without question. It could even be added at the front-end proxy to cover
>> numerous web applications on many domains at once.
>>
>> And I know this is conspiracy theory, but that's why I think there is such
>> resistance to it.
>>
>> Since the flaw is required for OAuth to work, companies invested in OAuth
>> and that profit from OAuth solutions don't want sites behind proxies that
>> would break OAuth and don't want webmasters to understand they have to
>> reduce security in order to implement an OAuth solution.
>>
>> That's just a suspicion of mine, but I can't think of any other logical
>> reason as to why a node attribute was chosen as the solution, and why there
>> is such resistance to doing it the right way with a header. To me it just
>> doesn't make sense.
>>
>>
>> On 12/01/2016 05:45 PM, Zac Spitzer wrote:
>>
>>> how about rather than requiring this on every <a> why not support a base
>>> tag directive
>>> for the whole document i.e. <base rel="noopener">, similar to <base
>>> target="_blank">?
>>>
>>> On Fri, Dec 2, 2016 at 12:39 PM, Domenic Denicola <d@domenic.me> wrote:
>>>
>>> From: whatwg [mailto:whatwg-bounces@lists.whatwg.org] On Behalf Of Ian
>>>> Hickson
>>>>
>>>> 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.
>>>>
>>>> This is the crucial point.
>>>>
>>>> Whenever you are discussing a supposed security issue, you need to make
>>>> clear what the threat model is. That is:
>>>>
>>>> - What would be the impact on the victim if the security hole is taken
>>>> advantage of?
>>>> - Is this something we are trying to prevent on the web platform?
>>>>
>>>> In this case, the impact on the victim (a user of a web browser) is that
>>>> they could click a link from page A to page B, which opens in a new tab
>>>> (tab B). Then, tab A could be navigated to a new URL, instead of staying
>>>> on
>>>> page A.
>>>>
>>>> This is not a big impact. Notably, page B is not able to read any of the
>>>> content of page A, which might be sensitive. Page B is not able to
>>>> interfere with the operation of any of page B's scripts. And crucially,
>>>> when page B navigates tab A to another page, the URL bar of tab A changes
>>>> to indicate that.
>>>>
>>>> There is no desired security guarantee on the platform that we want to
>>>> prevent pages from directing users to "bad" sites. We count on users
>>>> inspecting the URL bar to understand what page they are interacting with
>>>> in
>>>> a given tab.
>>>>
>>>> So, while it might be a bit surprising that suddenly tab A is navigating
>>>> somewhere else, there is no security issue here, and users are not
>>>> endangered in any way---at least, not in any more danger than they
>>>> already
>>>> are from browsing the web without looking at their URL bar to see where
>>>> they've ended up at.
>>>>
>>>>
>>>
>>>
>>>
>>
Received on Friday, 2 December 2016 03:45:11 UTC

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