Feature Request: Prohibit Navigation policy bypass via window.opener
Reported by
cs.anura...@gmail.com,
Oct 24 2016
|
|||
Issue descriptionVULNERABILITY DETAILS Chrome does not allow user to change grandfather window href if the grandfather window is at different origin. So if a user tries to use opener.opener.location.href='http://somesite.com' then chrome will throw: **Unsafe JavaScript attempt to initiate navigation for frame with URL 'https://twitter.com/' from frame with URL 'http://anuragtesting2.weebly.com/files/theme/d.html'. The frame attempting navigation is neither same-origin with the target, nor is it the target's parent or opener.** Now we can simply bypass this using the fact that a window is allowed to change href of its opener. 1) Open and extract the zip file and place them in one location 2) Open b.html 3) Click on link "Open c.html". A new window c.html comes up. 4) Click on link "My file" 5) A new window http://anuragtesting2.weebly.com/files/theme/d.html opens up. 6) The window at step 5 would fail to execute opener.opener.location.href since both are at different origin. 7) But you will notice that on opening step5 window, the window at step 2 changed which should not be allowed. How it happened: For that lets see whats inside http://anuragtesting2.weebly.com/files/theme/d.html <script>opener.location="http://anuragtesting2.weebly.com/files/theme/c.html";</script> So it moved its parent window which was c.html to http://anuragtesting2.weebly.com/files/theme/c.html Now lets see whats inside http://anuragtesting2.weebly.com/files/theme/c.html <script>opener.location="http://twitter.com"; history.back(); </script> As you can see the grandfather window will now moved to twitter.com by its child window and then using history.back() child window will revert to its original url. Overall one action on grandchild window changed the url of grandfather window. VERSION Chrome Version: 54.0.2840.71 m (64-bit) Operating System: Windows but should work fine with other OS also REPRODUCTION CASE Zip attached with all necessary html files Just to add the case is same for opener.location.history.length which is restricted but can be bypassed using same trick (ie point parent to a attacker site which collect the history.length and then use history.back to get back to original url like nothing happened) Also not sure but should not closed method be forbidden for opener window since it could tell the attacker site how long user used that parent site (although their are several restriction which make this one minor serious)
,
Oct 24 2016
This is indeed the way things work in browsers I've tested, and it's the way things are specced in HTML. I think there's some willingness among browser vendors to look at reducing the scope of `opener` to same-origin/site navigations, but no one's taken that step yet (nor do we have any metrics on usage of `opener`, cross- or same-origin).
,
Oct 24 2016
True but then restricting opener.opener.location.href in Chrome would not make sense. Also it would be great if in future we have a spec where child window is not allowed to close the parent window since that might actually result in loss of data. Right now even if child is allowed to close parent window even when they are from different origin.
,
Oct 25 2016
As this is standards-based and known behavior, there's no need to track this as a security bug. Changing to security feature.
,
Nov 8 2016
Confirming the issue as this is a feature request Waiting for more inputs on this |
|||
►
Sign in to add a comment |
|||
Comment 1 by elawrence@chromium.org
, Oct 24 2016Components: UI>Browser>Navigation
Summary: Security: Navigation policy bypass via window.opener (was: Security: CORS policy bypass using logical flaw)