- From: Michael A. Peters <mpeters@domblogger.net>
- Date: Thu, 1 Dec 2016 19:44:35 -0800
- To: whatwg@lists.whatwg.org
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