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

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

From: Domenic Denicola <d@domenic.me>
Date: Fri, 2 Dec 2016 01:39:40 +0000
To: Ian Hickson <ian@hixie.ch>, "Michael A. Peters" <mpeters@domblogger.net>, "whatwg@whatwg.org" <whatwg@whatwg.org>
Message-ID: <CY1PR0501MB136995DCCBF9B61A4C31BE29DF8E0@CY1PR0501MB1369.namprd05.prod.outlook.com>
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 01:40:13 UTC

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