Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 31 users
Status: Assigned
Owner:
(OOO until 16th)
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Feature

Blocked on:
issue 551884



Sign in to add a comment
Security: if window.opener exists, a page can trigger a navigation in the opener regardless of security origin
Project Member Reported by jochen@chromium.org, Jan 9 2013 Back to list
a.html:

<a href="b.html" target="_blank">link</a>

b.html:

<script>window.opener.location.href="http://google.com";</script>

When the user goes to a.html and clicks the link, a new tab with b.html is opened, and the old tab with a.html navigates to google.com in the background.

Note that this also works when a.html and b.html are on different security origins.

can be used to annoy the user.

Or get the referrer if the tab was opened without a referrer.
 
Owner: creis@chromium.org
Status: Assigned
@creis - i know this is a duplicate, but I can't seem to find the original report.  thanks.
Comment 2 by creis@chromium.org, Jan 10 2013
Yep, we also saw this in  issue 156712 .  Before I close it as a dupe, I want to confirm whether my understanding of the spec is correct or not.  I thought it was required to allow cross-origin windows to navigate their opener, but perhaps it's not.
Comment 3 by creis@chromium.org, Jan 10 2013
Cc: ajwong@chromium.org nasko@chromium.org darin@chromium.org
Interesting.  We may look into locking this down.

The current wording of the spec doesn't allow a cross-origin page to navigate its opener:
http://www.whatwg.org/specs/web-apps/current-work/#allowed-to-navigate

That seems to apply both to navigations of named windows and things like the location.href setter.

Other browsers (including Safari, Firefox, IE, and Opera) all behave the same as Chrome here, so we may need to get a sense for the compatibility impact of changing this.  Worth a try to lock it down, though.

Note that I may not have time to get to this right away, so someone else should feel free to grab it if they have the time.

Quote from the spec:
A browsing context A is allowed to navigate a second browsing context B if one of the following conditions is true:
 - Either the origin of the active document of A is the same as the origin of the active document of B, or
 - The browsing context A is a nested browsing context with a top-level browsing context, and its top-level browsing context is B, or
 - The browsing context B is an auxiliary browsing context and A is allowed to navigate B's opener browsing context, or
 - The browsing context B is not a top-level browsing context, but there exists an ancestor browsing context of B whose active document has the same origin as the active document of A (possibly in fact being A itself).

Comment 4 by darin@chromium.org, Jan 10 2013
If all browsers allow cross-origin windows to navigate their opener, but the spec does not, then I'd bet that the spec is just incorrect :-/
Comment 5 by cdn@chromium.org, Jan 30 2013
Can this be closed as Won't Fix or do we intend to change behavior here?
Comment 6 by creis@chromium.org, Jan 31 2013
I'd like to look into some UMA data for how many pages we would affect if we locked it down.

I would be ok with marking this as Feature-Security and lifting the view restriction, though, since the current behavior is somewhat expected and on par with all browsers.  @cdn, do you agree?
Comment 7 by cdn@chromium.org, Jan 31 2013
Labels: -Restrict-View-SecurityTeam -Type-Security Feature-Security Type-Bug
Sounds good
Project Member Comment 8 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Feature-Security -Area-WebKit Cr-Content Cr-Security
Project Member Comment 9 by bugdroid1@chromium.org, Apr 5 2013
Labels: -Cr-Content Cr-Blink
Hey everyone,

This is a pretty huge issue for any site that deals with user-generated content. There's a pretty gnarly attack scenario enabled by this behavior:

1. Go to a UGC site that allows uploading files with embedded links.
2. Upload a file containing a link to an attacker's page.
3. When someone clicks the link, the attacker page redirects the original window to a page that looks like the UGC site but is actually a phishing site designed to look like it. The user doesn't notice this because focus is on the attacker's page in the new window while the redirect happens.

I don't want to speak for others, but this seems like a pretty big security hole that is important to close
This is also an issue on a page that allows user commenting with anchor links. When someone else clicks on the link, the destination can easily change the original page with window.opener.location.replace() to show a different page that looks like the original page or one that asks for login credential.
For the record, it looks like the spec's wording has changed and now allows cross-origin openers to be navigated.  Here's an updated quote from https://html.spec.whatwg.org/#allowed-to-navigate:

"A browsing context A is allowed to navigate a second browsing context B if the following algorithm terminates positively:

If A is not the same browsing context as B, and A is not one of the ancestor browsing contexts of B, and B is not a top-level browsing context, and A's active document's active sandboxing flag set has its sandboxed navigation browsing context flag set, then abort these steps negatively.

Otherwise, if B is a top-level browsing context, and is one of the ancestor browsing contexts of A, and A's node document's active sandboxing flag set has its sandboxed top-level navigation browsing context flag set, then abort these steps negatively.

Otherwise, if B is a top-level browsing context, and is neither A nor one of the ancestor browsing contexts of A, and A's Document's active sandboxing flag set has its sandboxed navigation browsing context flag set, and A is not the one permitted sandboxed navigator of B, then abort these steps negatively.

Otherwise, terminate positively!"

The spec now defaults to allowing the navigation, which seems to be consistent with existing browser behavior.  I'm not opposed to seeing that changed, but someone would have to find the time to measure the compatibility impact.
Agreed that this is very risky and unfortunate for the many sites that allow user-supplied links.  It forces an additional script-driven redirect interstitial page to be loaded in every new tab to disown the opener before navigating to any untrusted content, which has unacceptable performance implications.
Comment 13: That's not quite correct.  A page can put rel=noreferrer target=_blank on untrusted links to force them to open in a window with no opener, and Chrome will even try to put them in a separate process.  Alternatively, it can use w=window.open();w.opener=null;w.location.href=url; without any extra navigations.
Comment 15 by echo1...@gmail.com, Feb 24 2015
@14 - window.open() will trigger the popup blocker, so it's not an equivalent "alternative" to an anchor link.
Comment 16 Deleted
FYI, I have submitted a proposal which will address this in the HTML spec. https://github.com/w3c/html/pull/22

I welcome support in developing a standardized way of fixing this sort of vulnerability.
Note: The W3C version is not the canonical one (most) UAs use.

I believe you want to file against the WHATWG HTML Living Standard ( https://html.spec.whatwg.org/multipage/ ) - in particular, the "File a bug" process described there (which, incidentally, points back to a W3C hosted bug tracker, which is several orders of magnitude more than the Github pull request)
Thanks for the tip rsleevi... I've filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28821
Blockedon: chromium:551884
Labels: -Type-Bug Type-Feature Cr-Blink-SecurityFeature
Charlie, did you add metrics for this? It does seem like a default that we might want to find a way to reverse. In the meantime,  issue 551884  covers a more explicit way of doing the `rel=noreferrer target=_blank` trick to block access to `window.opener` (and to allow us to do clever things with processes).
@mkwst: No, I never had the chance.  Comments 3, 6, and 12 sum up my current understanding.  Feel free to take it over, as I'm not likely to have the time in the near future (though it would be great to lock down if we can).
Labels: -Cr-Blink
Removing Cr-Blink from issues that already have Cr-Blink sub-label set.
Cc: -ajwong@chromium.org creis@chromium.org
Labels: Cr-UI-Browser-Navigation
Owner: mkwst@chromium.org
This has come up again in issue 574958, so it might be worth revisiting.  mkwst@, would you have time to take a look at whether navigations of cross-origin openers should be denied?
Cc: alex...@chromium.org
Also adding alexmos@ for his take, since I know he's looked at this part of the spec recently.
Issue 574958 has been merged into this issue.
Comment 26 by mkwst@chromium.org, Jan 11 2016
I'm pretty sure that this is the specced behavior. I'm also pretty sure that I don't like it and that we should change pieces of it if possible. I'll try to get some metrics in for this milestone.
Comment 27 by mkwst@chromium.org, Jan 11 2016
(Also note that https://code.google.com/p/chromium/issues/detail?id=551884 did land, so `noopener` is a totally valid workaround for the existingly annoying behavior.
IMO it doesn't matter if it's specced behavior or not. And 'noopener' workaround is probably not very common or widely used. The truth is that Chrome has a huge security issue which allows to replace trusted sites in browser tabs with malicious ones, which makes it "phising paradise". It may pretend Google, or Facebook, or your banking site and ask to re-enter credentials etc. Just click a wrong banner or link - and you are in trouble.
It's very sad to find "gems" like this one in Google Chrome, and even more sad to find out that the problem was known but ignored for more than a year.
"Secure browser" ya say? 8b

Comment 30 by math...@qiwi.be, Mar 15 2016
FWIW, I made a quick “explainer” document/demo for this feature: https://mathiasbynens.github.io/rel-noopener/

Mike, can this issue be closed now that Chrome 49 shipped with this feature?
What about <form ... target="_blank">?

Probably much less common but seems to be affected, too.
Comment 32 by math...@qiwi.be, Mar 18 2016
Re: comment 31: if you allow `<form>` in user-generated content, you have bigger problems.
Comment 33 by run...@gmail.com, Aug 25 2016
There are about 140+ comments about this issue on the reddit thread here: https://www.reddit.com/r/programming/comments/4zikpx/the_target_blank_vulnerability_by_example/ -- almost seems like a consensus that rel="noopener" should become the default.

Is it possible to change the default to noopener, and add a setting so that outdated/legacy applications can have users manually toggle this behavior back on?  IMO this is the wrong default behavior for the browser because it is a huge phishing issue.  Main reason I can see to persist it is if Chromium developers have some kind of conflict of interest wherein they derive some income from phishing sites.
I agree. This would overall be more beneficial in terms of security than it would be detrimental in terms of backward compatibility, so it's worthwhile to adjust the default behavior to something which obeys cross origin policies.
Sign in to add a comment