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 <mpet...@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-boun...@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.
