On 12/01/2016 05:39 PM, Domenic Denicola 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.
It is a huge impact.
Scenario A) It can be used for protocol downgrade attack.
Site A has both https and http. JavaScript on site B reloads Site A as
HTTP - so even though the user visited A as HTTPS, now they are at A as
HTTP.
The user has no reason to suspect that the protocol changed, and on
mobile devices the URL bar is often hidden.
Scenario B) User clicks on link to Site B. Site B puts up a fake page
telling the user Google has blocked the site because of malware and asks
them to close the window.
Meanwhile JavaScript changhed Site A to a phishing page that says
Facebook (or whatever) detected a malicious cross site scripting, would
they please login again to verify their identity.
The user was just at Site A and it was genuine, just experienced a
warning they believed to be from Google that malware was attempted, and
enters their username and password.
This is an extremely serious bug and I literally do not comprehend why I
keep having to explain it.
Remember most users don't know the difference between JavaScript and
Turbo Pascal.
The best encryption in the world doesn't protect users from social
engineering attacks directly made possible by this kind of flaw.
