Cool bug! Mike, can you please take a look?

Reproduction confirmed. The naive version of the attack is blocked by the XSS Auditor unless the victim page uses X-XSS-Protection: 0. However, the XSS Auditor is best-effort and isn't considered a security feature.

Executing the attack yields this in the console:
Unsafe JavaScript attempt to initiate navigation for frame with URL 'attacker' from frame with URL 'victim'. The frame attempting navigation of the top-level window is sandboxed, but the 'allow-top-navigation' flag is not set.

If the victim page has the XSS Auditor enabled, it's followed by:
VM47 onload=alert(document.domain)>:1 The XSS Auditor refused to execute a script in 'victim' because its source code was found within the request. The auditor was enabled as the server sent neither an 'X-XSS-Protection' nor 'Content-Security-Policy' header.

If XSS Auditor isn't disabled or the attacker has bypassed it, script executes in the child domain.

Severity guidelines suggest Medium or Low.

-- Standards Compliance --
https://www.w3.org/TR/html5/browsers.html#sandboxLinks says "If the source browsing context is not allowed to navigate the browsing context being navigated, then abort these steps."

Chrome does not navigate, but the cancellation of the window.top navigation does not abort the <A> navigation to the JavaScript:-scheme url, meaning that the result of the JavaScript yields a new string document which runs in the context of the victim site. 

Could we fix this by causing the navigation attempt to throw an exception? That seems to be what happens in Firefox.

Yes, I think we should be throwing for `location` object setters if the frame is sandboxed. This is spelled out in https://html.spec.whatwg.org/#location-object-navigate and https://html.spec.whatwg.org/#navigating-across-documents:allowed-to-navigate.

We'll have to do a bit of refactoring to support the exceptions flag; I'll take a look at it tomorrow.

https://codereview.chromium.org/2371993003 is up for review.

+Jochen, since I've asked you to review the patch. You should have access to the bug regardless, but just in case.

I just realized this works even without 'sandbox', as long as the navigation isn't instantaneous: https://attacker.website/JustLocation

Interesting. It looks like we're synchronously replacing the document in  `FrameLoader::replaceDocumentWhileExecutingJavaScriptURL` and `DocumentLoader::replaceDocumentWhileExecutingJavaScriptURL`. CCing people who know more about the intricacies of navigation, as it's not clear to me what the right answer is here. Perhaps if the executed script queues a navigation, we ignore the crazy `javascript:` replacement behavior?

P.S. `attacker.website` and `victim.website` are wonderful, wonderful domains. Nice job!

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

commit ce8199558bd1cc8737c4349fc0937860b380da3c
Author: mkwst <mkwst@chromium.org>
Date: Thu Sep 29 13:55:10 2016

Throw when blocking top-level navigation.

In a sandboxed <iframe>, setting 'top.location' currently blocks the
resulting navigation, but does not throw. This doesn't match the HTML
spec (see https://html.spec.whatwg.org/#location-object-navigate and
https://html.spec.whatwg.org/#navigating-across-documents:allowed-to-navigate),
nor does it match Firefox's behavior.

This patch changes our implementation to throw a SecurityError in
these cases.

BUG= 650232 

Review-Url: https://codereview.chromium.org/2371993003
Cr-Commit-Position: refs/heads/master@{#421807}

[modify] https://crrev.com/ce8199558bd1cc8737c4349fc0937860b380da3c/content/browser/site_per_process_browsertest.cc
[modify] https://crrev.com/ce8199558bd1cc8737c4349fc0937860b380da3c/third_party/WebKit/LayoutTests/fast/frames/sandboxed-iframe-navigation-parent-expected.txt
[modify] https://crrev.com/ce8199558bd1cc8737c4349fc0937860b380da3c/third_party/WebKit/LayoutTests/fast/frames/sandboxed-iframe-navigation-top-denied-expected.txt
[add] https://crrev.com/ce8199558bd1cc8737c4349fc0937860b380da3c/third_party/WebKit/LayoutTests/http/tests/security/sandbox-iframe-blocks-top-navigation-to-javascript.html
[add] https://crrev.com/ce8199558bd1cc8737c4349fc0937860b380da3c/third_party/WebKit/LayoutTests/http/tests/security/sandbox-iframe-blocks-top-navigation.html
[add] https://crrev.com/ce8199558bd1cc8737c4349fc0937860b380da3c/third_party/WebKit/LayoutTests/imported/wpt/html/browsers/history/the-location-interface/security_location_0.sub-expected.txt
[modify] https://crrev.com/ce8199558bd1cc8737c4349fc0937860b380da3c/third_party/WebKit/Source/core/frame/Location.cpp
[modify] https://crrev.com/ce8199558bd1cc8737c4349fc0937860b380da3c/third_party/WebKit/Source/core/frame/Location.h
[modify] https://crrev.com/ce8199558bd1cc8737c4349fc0937860b380da3c/third_party/WebKit/Source/core/frame/Location.idl
[modify] https://crrev.com/ce8199558bd1cc8737c4349fc0937860b380da3c/third_party/WebKit/Source/web/tests/WebFrameTest.cpp

Hello!  Any more changes expected or can this be moved to fixed?  Cheers.

mkwst: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

Marking as Fixed to get this into our security bug workflow.

[Automated comment] Commit may have occurred before M55 branch point (10/6/2016), needs manual review.

+awhalley@ for M55 merge review

We couldn't work out any way an attacker could use this to cause any user harm.

Approving merge to M55 branch 2883. Please merge ASAP.

Sorry, didn't remove enough labels.  No need to take this into M55.

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