New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 658673 link

Starred by 1 user

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Feature



Sign in to add a comment

Feature Request: Prohibit Navigation policy bypass via window.opener

Reported by cs.anura...@gmail.com, Oct 24 2016

Issue description

VULNERABILITY 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)

 
List.zip
756 bytes Download
Cc: mkwst@chromium.org
Components: UI>Browser>Navigation
Summary: Security: Navigation policy bypass via window.opener (was: Security: CORS policy bypass using logical flaw)
This isn't about CORS, this concerns origin restrictions for navigation.

I believe this is Working-as-Intended and is the motivational scenario for the rel=noopener attribute.

Comment 2 by mkwst@chromium.org, 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).
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.
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Pri-3 Type-Feature
Summary: Feature Request: Prohibit Navigation policy bypass via window.opener (was: Security: Navigation policy bypass via window.opener)
As this is standards-based and known behavior, there's no need to track this as a security bug. Changing to security feature.
Cc: tkonch...@chromium.org
Status: Untriaged (was: Unconfirmed)
Confirming the issue as this is a feature request

Waiting for more inputs on this

Sign in to add a comment