1312385 - Probable issues with window.opener

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, defect, P3)

Description

[Anurag]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20161019084923

Steps to reproduce:

While testing access control of child window over parent window i saw some issue (some of them only exist in Firefox and other browser had them fixed)

1) You can change url of grandfather tab using opener.opener.location.href which normally is restricted in other browser like Chrome as part of CORS
2) You can show alert/confirm boxes using opener.confirm("Hello"); in parent/grandfather window which is restricted with other browser (Good thing is parent & child should be at same domain, safe but could be exploited under special conditions)
3) Child can close parent window which can lead to loss of user data
4) Just a suggestion
a) if we really need to expose closed function since it could tell attacker how much time user spent on parent window (Full exploitation has several restriction but if user dont want to disclose his time on site then this would become problem)
b) opener.location.history.length which is normally permission denied for child window can be accessed by making the parent move to malicious site which record history.length & then perform history.back to move the parent back to original location.
c) You can make parent window navigate on data uri ( Alert boxes, fake virtual login forms) like on navigating below link it would call print function and also navigate user (Firefox goes to hackerone and Chrome goes to twitter because of difference in parsing way)
opener.location.href='data:text/html;base64,PHNjcmlwdD53aW5kb3cubG9jYXRpb24uaHJlZj0naHR0cHM6Ly9oYWNrZXJvbmUuY29tJztwcmludCgpO3ByaW50KCk7d2luZG93LmxvY2F0aW9uLmhyZWY9J2h0dHBzOi8vdHdpdHRlci5jb20nPC9zY3JpcHQ+'



Actual results:

The above can be used by an attacker to spoof user or to make user loss his data


Expected results:

Most of these could be changed the way Chrome is handling.

Comment 1

[:Gijs (he/him)]

Blake, am I right in thinking you might know about whether this is all WebIDL specced and/or how hard it would be to harden some of this?

Andrew, any guesses on severity? The fact that there's a number of issues in the same report makes it harder for me to pick something - e.g. opener.opener feels like enough of a long shot that it might not matter, but navigating the opener to look at history.length is vaguely weird (though then again, what does history.length really tell you?).

(In reply to Anurag from comment #0)
> some of them only exist in Firefox and other browser had them fixed

Which of these? Do you have test pages for the list of items you reported?

Comment 2

[Anurag]

Attachment: Use Case.zip

Hi,

Issue which are solved in Chrome are :

1) You cannot access grandparent window using opener.opener.location.href
2) You cannot make alert/confirm boxes in parent even when they are at same domain

I have attached sample html for each usecase.

Thanks

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

https://html.spec.whatwg.org/multipage/browsers.html#crossoriginproperties-(-o-)

Comment 4

[Boris Zbarsky [:bzbarsky]]

This is certainly specced, as Olli points out.  What we are doing right now follows the spec as far as I know, so this entire discussion should be happening in a spec issue, not a browser issue.

> 1) You can change url of grandfather tab using opener.opener.location.href which normally is restricted in other browser like Chrome as part of CORS

There has been some discussion about this in the past; I can't recall whether it was in our bug database or the HTML spec issue tracker.  I've never seen a clear description of what Chrome's actual behavior here is, precisely, which is a minimum requirement for considering implementing it.

> 3) Child can close parent window which can lead to loss of user data

Indeed.  And "parent" can close "child", which has the same issue in general, but people rely on it.

> a) if we really need to expose closed function since it could tell attacker how much time user spent on parent window

We could consider restricting this to "close() has been called" in the cross-origin case.  But note that the closed state can be detected anyway by simply attempting to navigate and observing that it doesn't happen...

> b) opener.location.history.length which is normally permission denied for child window can be accessed by making the parent move to malicious site which record history.length 

Yep.  history.length is a busted API that leaks information across origins by design.  It's very sad, but no different from reading your own history.length and discovering that you were not the first page loaded in the browser tab.

> c) You can make parent window navigate on data uri 

Yes, like any other URI.

I don't think this should be security-sensitive; all the information here is public and has been for a long time; it's all basic "how the web security model works" stuff...