Forgot to mentioned the Service Worker step:
Click on "Try registering Service Worker". This installs Service Worker on the scope of "https://vuln.shhnjk.com/". And it actually has DOM access.

falken, could you please take a look, or help with assigning this to the right person? thanks.

falken: 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

I'm crawling out of some other crashes and stuff. I am going to relook at the top crashers on M68 Beta now before getting to this. If anyone can chip in to verify this bug it'd be appreciated.

I took a look. I'm not sure this is a security bug.

The POC is doing the following:
(1) attack.shhnjk.com contains an iframe to vuln.shhnjk.com.
(2) vuln.shhnjk.com calls document.domain = "shhnjk.com"; to opt-in to the more general origin.
(3) From attack.shhnjk.com, we can:
  (a) Perform fetch() to vuln.shhnjk.com on the iframe's context, to get a plaintext response from vuln.shhnjk.com.
  (b) Perform navigation.serviceWorker.register() for vuln.shhnjk.com on the iframe's context, and register a service worker at vuln.shhnjk.com.

At least, this phenomenon is not exclusive to SW because 3a doesn't involve SWs.

I'm not very familiar with document.domain but it seems vuln.shhnjk.com opted itself into this behavior. But I agree that since "Try access iframe" is blocked, where attack.shhnjk.com tries to access the DOM of vuln.shhnjk.com, it appears Chrome tries to enforce some origin separation still.

The MDN docs for document.domain mention a lot about what Mozilla does, but not so much other browsers:
https://developer.mozilla.org/en-US/docs/Web/API/Document/domain

Do security or specification folks agree this is a bug in Chrome? cc/ +domenic

Editing summary so it's not all about SW.

+yhirano

It seems like the issue here, if there is one, is how certain parts of the platform (e.g. fetch) use same-origin checks, whereas others (e.g. DOM APIs and function calls, in general) use same-origin-domain. See https://html.spec.whatwg.org/multipage/origin.html#same-origin for the difference.

When evaluating the security issues here, keep in mind that any two pages that are same origin-domain (i.e. are either same origin, or have both set document.domain to the same value) can synchronously access each other. That means they can run arbitrary code "as if" they were in that other origin. (Trivial example: otherFrame.eval("....").)

So I don't think there can be any security issue here, if both pages have opted in in this way.

More specifically:

> (a) Perform fetch() to vuln.shhnjk.com on the iframe's context, to get a plaintext response from vuln.shhnjk.com.

This is totally expected. In particular you're using eval in the other frame, so of course it will work. It's as if the other frame was doing it itself.

>  (b) Perform navigation.serviceWorker.register() for vuln.shhnjk.com on the iframe's context, and register a service worker at vuln.shhnjk.com.

Same.

> Try access iframe

This fails because the third iframe hasn't opted in with document.domain. So it is still protected from access by its (cross-origin-domain) parent.

In conclusion, this all seems working as intended.

> This fails because the third iframe hasn't opted in with document.domain. So it is still protected from access by its (cross-origin-domain) parent.

In particular, in this case the iframe is cross-origin-domain, because its parent has set document.domain, but it hasn't. But it's still same-origin, because both are located on https://vuln.shhnjk.com:80.

Thanks for the analysis, Domenic! Based on that, I will WontFix this.

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