Guessing at severity/impact labels for this bug on its own; please adjust if not correct.

I'm not entirely sure that this makes sense as a security bug.  WAR isn't really a security boundary in most cases, and if the opener relationship is severed, this doesn't (by itself) seem bad.  Does this warrant security_impact-?  If so, can we elaborate on why?

I consider this a security bug because there is part of ChromeContentBrowserClientExtensionsPart::ShouldAllowOpenURL that enforces a security boundary for blob/filesystem.

The "noopener" sidestep was used as part of one variant of the bug 820838 sandbox escape. We'll fix that by moving the blob/filesystem security checks from ShouldAllowOpenURL to FilterURL ( bug 821596 ; fix is in the CQ as we speak).

After that lands, the fact that ShouldAllowOpenURL isn't effective in the 'noopener' case can be treated as a functional bug. My hunch is that what's going on here is that we create an extension SiteInstance early in the noopener case, so we never check permissions against the web process. So, this could easily turn out to be a content bug.

We've also got checks in ExtensionNavigationThrottle::WillStartOrRedirectRequest which prevent non-extension processes from navigating to extension origins (https://cs.chromium.org/chromium/src/extensions/browser/extension_navigation_throttle.cc?l=81&rcl=178a7ae0bc121cdb286a7e46b002706785abc51b), and based on Nick's repro, it seems that check was also bypassed with noopener.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a6102ee28b50372c8cf67ee3040c929e86b1eb07

commit a6102ee28b50372c8cf67ee3040c929e86b1eb07
Author: Nick Carter <nick@chromium.org>
Date: Wed Mar 14 18:49:13 2018

Stricter blob/filesystem check in CanRequestURL.

Blobs and filesystem URLs are considered "local" schemes by blink;
they can only be requested from processes with permission to
commit them.

Adding this means that we block extension filesystem: URLs via FilterURL
rather than ShouldAllowOpenURL, meaning that the WebAccessibleResource
UMAs don't trigger. Update test expectations to reflect this.

Add a test that exercises an interesting 'noopener' corner case.

Change-Id: Ie0473a4d4034ceb03e6098d524f16ef8d215398e
Bug:  821586 ,  821596 
Reviewed-on: https://chromium-review.googlesource.com/961126
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Nick Carter <nick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#543142}
[modify] https://crrev.com/a6102ee28b50372c8cf67ee3040c929e86b1eb07/chrome/browser/extensions/process_manager_browsertest.cc
[modify] https://crrev.com/a6102ee28b50372c8cf67ee3040c929e86b1eb07/content/browser/child_process_security_policy_impl.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fd30633d9051ff97eed229cab019f75eaaa16144

commit fd30633d9051ff97eed229cab019f75eaaa16144
Author: Nick Carter <nick@chromium.org>
Date: Thu Mar 15 18:43:02 2018

Stricter blob/filesystem check in CanRequestURL.

Blobs and filesystem URLs are considered "local" schemes by blink;
they can only be requested from processes with permission to
commit them.

Adding this means that we block extension filesystem: URLs via FilterURL
rather than ShouldAllowOpenURL, meaning that the WebAccessibleResource
UMAs don't trigger. Update test expectations to reflect this.

Add a test that exercises an interesting 'noopener' corner case.

Change-Id: Ie0473a4d4034ceb03e6098d524f16ef8d215398e
Bug:  821586 ,  821596 
Reviewed-on: https://chromium-review.googlesource.com/961126
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Nick Carter <nick@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#543142}(cherry picked from commit a6102ee28b50372c8cf67ee3040c929e86b1eb07)
Reviewed-on: https://chromium-review.googlesource.com/962975
Reviewed-by: Nick Carter <nick@chromium.org>
Cr-Commit-Position: refs/branch-heads/3359@{#273}
Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276}
[modify] https://crrev.com/fd30633d9051ff97eed229cab019f75eaaa16144/chrome/browser/extensions/process_manager_browsertest.cc
[modify] https://crrev.com/fd30633d9051ff97eed229cab019f75eaaa16144/content/browser/child_process_security_policy_impl.cc

Please mark security bugs as fixed as soon as the fix lands, and before requesting merges. This update is based on the merge- labels applied to this issue. Please reopen if this update was incorrect.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Not fixed, but also not a security bug anymore, just a web compat and correctness issue.

Looks like HTTP redirects to chrome-extension:// URLs can be used in a similar manner to defeat ShouldAllowOpenURL. I'll try to plug that hole too.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1cb9c33c4afd6df591c6306511bac80ec216d463

commit 1cb9c33c4afd6df591c6306511bac80ec216d463
Author: Nick Carter <nick@chromium.org>
Date: Fri Mar 30 18:40:07 2018

Prevent webpages from navigating to chrome-extension:// URLs, unless webaccessible

In render_frame_host_impl.cc, fix webaccessible resource bypass via 'noopener':

   When window.open is called with an URL that is disallowed, do the
   ShouldAllowOpenURL check up front, against the SiteInstance of the requesting
   page. The problem with doing it later is that if the window is created with
   the "noopener" attribute, we forget the requesting SiteInstance, and the
   check was done against a newly-created SiteInstance -- which succeeds, since
   the SiteInstance was created to host |target_url|. This behavior allowed some
   requests (e.g. to the URL of an invalid extension) to proceed that would have
   been blocked without "noopener". The "noopener" attribute shouldn't change
   whether a navigation succeeds or fails.

In extension_protocols.cc, fix webaccessible resource bypass via HTTP redirect:

   HTTP servers are allowed to redirect to chrome-extension:// resources. If
   this redirect were to occur client-side from the http server's origin, it
   would be subject to webaccessible resources restrictions. The existence of
   HTTP redirects shouldn't expand the set of extension URLs that an origin is
   able to trigger a navigation to.

   The WebRequest API also can introduce redirects; however, the required
   enforcement turns out to be the same as with HTTP, per the webaccessible
   resources doc:
    > When an extension uses the webRequest or declarativeWebRequest APIs to
    > redirect a public resource request to a resource that is not web
    > accessible, such request is also blocked.

In process_manager_browsertest.cc, add tests of the above cases.

Bug:  821586 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_mojo
Change-Id: I578b3ce401267994a8ef302f713e88dc43940af6
Reviewed-on: https://chromium-review.googlesource.com/963441
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Commit-Queue: Nick Carter <nick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#547218}
[modify] https://crrev.com/1cb9c33c4afd6df591c6306511bac80ec216d463/chrome/browser/extensions/process_manager_browsertest.cc
[modify] https://crrev.com/1cb9c33c4afd6df591c6306511bac80ec216d463/chrome/browser/extensions/window_open_apitest.cc
[modify] https://crrev.com/1cb9c33c4afd6df591c6306511bac80ec216d463/content/browser/frame_host/render_frame_host_impl.cc
[modify] https://crrev.com/1cb9c33c4afd6df591c6306511bac80ec216d463/extensions/browser/extension_protocols.cc
[modify] https://crrev.com/1cb9c33c4afd6df591c6306511bac80ec216d463/testing/buildbot/filters/mojo.fyi.network_browser_tests.filter

Requesting merge to M66 for r547218. To apply cleanly, the merge will also have to pick up two test-only flakiness fixes (r543797 and r543870).

This bug requires manual review: M66 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), josafat@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Can you please mark which OS's this is impacting so it routes to the correct owner?

I assume all desktop + chromeOS?

The bug this fixes is desktop + cros, but to the extent there is regression risk, it exists on Android too, since window.open() exists there.

Approving merge to M66. Branch:3359

I've merged the two prerequisite test changes; will need to manually merge the others, since there are conflicts.

Thanks - can you please merge them soon? We're about to cut beta candidate. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/46a34ec8c862517bf346fcfd0af05032569220cf

commit 46a34ec8c862517bf346fcfd0af05032569220cf
Author: Nick Carter <nick@chromium.org>
Date: Tue Apr 03 22:24:44 2018

Prevent webpages from navigating to chrome-extension:// URLs, unless webaccessible

In render_frame_host_impl.cc, fix webaccessible resource bypass via 'noopener':

   When window.open is called with an URL that is disallowed, do the
   ShouldAllowOpenURL check up front, against the SiteInstance of the requesting
   page. The problem with doing it later is that if the window is created with
   the "noopener" attribute, we forget the requesting SiteInstance, and the
   check was done against a newly-created SiteInstance -- which succeeds, since
   the SiteInstance was created to host |target_url|. This behavior allowed some
   requests (e.g. to the URL of an invalid extension) to proceed that would have
   been blocked without "noopener". The "noopener" attribute shouldn't change
   whether a navigation succeeds or fails.

In extension_protocols.cc, fix webaccessible resource bypass via HTTP redirect:

   HTTP servers are allowed to redirect to chrome-extension:// resources. If
   this redirect were to occur client-side from the http server's origin, it
   would be subject to webaccessible resources restrictions. The existence of
   HTTP redirects shouldn't expand the set of extension URLs that an origin is
   able to trigger a navigation to.

   The WebRequest API also can introduce redirects; however, the required
   enforcement turns out to be the same as with HTTP, per the webaccessible
   resources doc:
    > When an extension uses the webRequest or declarativeWebRequest APIs to
    > redirect a public resource request to a resource that is not web
    > accessible, such request is also blocked.

In process_manager_browsertest.cc, add tests of the above cases.

TBR=nick@chromium.org

(cherry picked from commit 1cb9c33c4afd6df591c6306511bac80ec216d463)

Bug:  821586 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_mojo
Change-Id: I578b3ce401267994a8ef302f713e88dc43940af6
Reviewed-on: https://chromium-review.googlesource.com/963441
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Commit-Queue: Nick Carter <nick@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#547218}
Reviewed-on: https://chromium-review.googlesource.com/994236
Reviewed-by: Nick Carter <nick@chromium.org>
Cr-Commit-Position: refs/branch-heads/3359@{#567}
Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276}
[modify] https://crrev.com/46a34ec8c862517bf346fcfd0af05032569220cf/chrome/browser/extensions/process_manager_browsertest.cc
[modify] https://crrev.com/46a34ec8c862517bf346fcfd0af05032569220cf/chrome/browser/extensions/window_open_apitest.cc
[modify] https://crrev.com/46a34ec8c862517bf346fcfd0af05032569220cf/content/browser/frame_host/render_frame_host_impl.cc
[modify] https://crrev.com/46a34ec8c862517bf346fcfd0af05032569220cf/extensions/browser/extension_protocols.cc
[modify] https://crrev.com/46a34ec8c862517bf346fcfd0af05032569220cf/testing/buildbot/filters/mojo.fyi.network_browser_tests.filter

All merges done.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot