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

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



-- 
Zac Spitzer
+61 405 847 168

Received on Friday, 2 December 2016 01:46:16 UTC