In step 4, do not press the back button but enter the URL 'about:blank'. Is it reproducible now?

I'll try to make a video-capture. Thanks.

Thank you for providing more feedback. Adding requester "elawrence@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Interestingly, this didn't repro in my original attempt, but I did get a repro in Chrome 54 when manually typing "about:blank" into the omnibox. 

This isn't limited to the document.origin property, it also shows that the about:blank markup has access to the target site's cookie. Injecting JavaScript into the markup shows that the markup has access to the cookie and origin data so it's not purely a Developer Tools artifact.

There's definitely something amiss here, but it's not clear whether or not this is remotely exploitable or whether it requires developer tools shenanigans.

Deleted: ConfusedState.png 38.3 KB

	ConfusedState.png 38.3 KB View Download

Typo in Comment #4: I have now repro'd in both Chrome 56.0.2924.87 and Chrome 59.0.3033.0. I was also able to reproduce using a different target site that uses a serviceworker:

  window.open('https://kimmobrunfeldt.github.io/service-worker-demo/', '_self') 

...but was not able to reproduce this with two other sites that use HTTPS but not ServiceWorker.

Is the root cause being investigated?

Is this related to navigation? Confused as to what site we're on? (Also this issue feels familiar; we may already have something open about this.)

(Change the components/labels if necessary.)

Marking severity high out of an abundance of caution, this may require dev tools interaction. Assigning to nasko per palmer's guess in C8.

about:blank pages often inherit the origin of their opener or parent, which allows real web pages to script them (e.g., in popups or iframes).  Sounds like this is going in the reverse direction, so maybe there's some confusion over how the opener is set in the _self case?  (I haven't tested variations on when this does and doesn't work.)

So far I don't see this being exploitable, unless it works when another page opens an about:blank window (inheriting its origin) and then is able to change the origin using this trick.  Even then, there's no code from the attacker's origin running in about:blank when you come back, so I'm not sure there's much damage here.

That said, I'm CC'ing alexmos and dcheng who know more about openers and origins.

Interesting.  window.open('https://foo.com', '_self') updates the window.opener to point to the window itself.  Then, when re-navigating to about:blank, as part of trying to inherit the SecurityOrigin from the opener [1], I'm guessing that we end up using the origin of the window's old document.

Interestingly, the repro doesn't work in --site-per-process mode, because we end up swapping processes for both the window.open("...", "_self") navigation, and the subsequent about:blank navigation.  However, that's because the repro uses a browser-initiated navigation to go to about:blank (by going back or using the omnibox).  If we used a renderer-initiated navigation to about:blank from google.com (such as by assigning location="about:blank"), we'd still end up inheriting the google.com origin.

I agree with Charlie that this doesn't seem exploitable, and I don't see a way for the attacker to run code after coming back to about:blank.  Suppose evil.com opens an about:blank popup, which initially inherits the evil.com origin.  Then if the attacker uses this trick to navigate the popup to google.com and then to about:blank and get the origin of about:blank to be google.com, that seems no more dangerous than just a window.open("https://google.com") to start with.  The attacker won't be able to script the popup in either case.

Nasko, Charlie, and I discussed this a bit more today, and we should also check the behavior in a few tricky cases (such as mixing the opener-points-to-self setup with srcdoc, session restore, and/or about:blank with an inherited non-null origin) to make sure that we don't end up with putting an about:blank page into a SiteInstance that doesn't match with the document.origin.

I'll also mention that we've got plans to change the inheritance logic in [1] to inherit the origin of whoever is initiating the navigation to about:blank, rather than necessarily the parent or opener.  That would help in the case above as if evil.com navigates its popup to about:blank, it'd wind up in the evil.com origin, even if its opener pointed to google.com.

[1] The inheritance logic is in DocumentLoader::ensureWriter():

  // Prepare a DocumentInit before clearing the frame, because it may need to
  // inherit an aliased security context.
  Document* owner = nullptr;
  // TODO(dcheng): This differs from the behavior of both IE and Firefox: the
  // origin is inherited from the document that loaded the URL.
  if (shouldInheritSecurityOriginFromOwner(url())) {
    Frame* ownerFrame = m_frame->tree().parent();
    if (!ownerFrame)
      ownerFrame = m_frame->loader().opener();
    if (ownerFrame && ownerFrame->isLocalFrame())
      owner = toLocalFrame(ownerFrame)->document();
  }
  DocumentInit init(owner, url(), m_frame);

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/loader/DocumentLoader.cpp?l=546

The origin from the DocumentInit is later picked in Document::initSecurityContext.

Given comments #11 and 12, I'm adjusting the labels, since this doesn't seem remotely exploitable.  The about:blank origin inheritance seems weird in this case, but not entirely unexpected given that window.opener points to the window itself.  Reporter: please speak up if we missed something.

I agree this is not exploitable. I just wanted to report something that I felt was unexpected.

Although not for a security fix anymore, will there be code modifications to change the 'weird' behavior that we are seeing here?

There are definitely issues with about:blank origin inheritance which we hope to fix - see issue 585649 for an example and some related spec discussion.  I've added a link to this issue there so we won't forget to consider it.

I think we should at least fix this to not inherit any origin when navigating to about:blank from the omnibox.  I'm less sure about a history navigation to about:blank; that might need to go into the origin it was originally in rather than a unique origin, and it should probably not inherit from the parent/opener or whoever's calling history.back().

If we used a renderer-initiated navigation to about:blank in your repro though, it'd kind of make sense for the google.com origin to be inherited as that's the initiator of the navigation.

Do I qualify for a reward? :)

Hi, is there any update on this one?

Since the consensus seems to be that this is not exploitable, this does not seem like a security issue. Marking this as a general bug and removing the view restrictions.