This looks like medium severity: The service worker can intercept script resources injected by the extension, but doesn't seem to be able to intercept content scripts.

Script resources run in the page's context as opposed to content scripts which run in the extension's context, therefore tampering with content scripts is more dangerous from the extension's perspective.

Still, we might want to fix it. 

falken, devlin: Any thoughts?

I can't reproduce this. Can you suggest an extension to install that exhibits this bug?

Also I'm not clear whether this is actually a problem. If an extension can inject script into the page context that makes requests to a "chrome-extension://" URL, it seems reasonable for a service worker controlling that page context to see those requests. Note that the service worker can only control same-origin pages, so the scenario in comment 0 wouldn't happen (if I understand correctly).

We already allow an extension to install service worker which controls that extension and sees chrome-extension:// requests made by that extension.

I'm not sure this is a security bug.  If an extension injects a script via a <script> tag on the page, it will execute in the main world of the page (thus having no special privileges) and will be visible to that page (it's an element in the DOM like any other).  So the ability for the page to see these requests is nothing new (they could just watch DOM mutation), and even if the page could mess with the resource, it wouldn't have any privilege.  meacer@, is there an attack vector I'm missing?  If not, we might be able to unrestrict this.

All that said, looking at this from a functionality standpoint, I'm not sure it's correct.  Extensions are considered to be acting on behalf of the user agent, and thus can bypass the page (e.g., adding a <script> tag with an extension script bypasses the page's CSP).  It seems like we wouldn't want to necessarily allow the page's SW to intercept these requests.  Offhand, I'd say we shouldn't let the page's SW intercept any chrome-extension:-scheme requests, because I can't think of a legitimate reason to do so.  falken@, WDYT?  Are there any valid use cases that would break?

I agree there doesn't seem to be a security problem here.

From a functionality standpoint, I don't have a strong opinion in terms of use cases. I'd be motivated to implement whatever is easiest to get right. If chrome-extension:// requests are supposed to bypass CSP etc it might make it difficult to allow a SW to intercept the request while still bypassing such web security mechanisms. So I can see why just bypassing the SW might be easier.

On the other hand, we already allow the SW to see chrome-extension:// requests from a chrome-extension:// page it controls, so we'd have to special-case that interception.

Conceptually, I think something like

if (request_url.SchemeIs(kExtensionScheme) &&
    url::Origin(initiator_url) != url::Origin(request_url)) {
  // Extension requests are only visible to that extension.
  HideRequest()
}

is basically the behavior we'd want.  But I agree that plumbing will make this a bit tricky.

Right, the way this works at Blink level today is like:

// If the URL is not http(s) or otherwise whitelisted, do not intercept the
// request. Schemes like 'blob' and 'file' are not eligible to be
// intercepted by service workers.
if (!gurl.SchemeIsHTTPOrHTTPS() && !OriginCanAccessServiceWorkers(gurl))
      return nullptr;

Where in Chrome today the only white-listed scheme is chrome-extension.

If there's not really a strong reason to change things, I think we can just leave the current behavior as is for now, so I'm thinking we can just wontfixing this. Feel free to re-open or make a new (non security bug) for tracking.

I think it might be worth making a (non-security) bug to track hiding these requests from pages, since it doesn't seem like desired behavior - though lower priority to fix.

Before I do that, meacer@, are there any remaining security concerns here?

Sounds good. Re-opening for meacer@'s input.

If we are confident that SW can only intercept chrome-extension URLs that become part of the page's world, then yes I'm okay with dropping this from the security queue.

Yes I believe so. Service worker works like this:

- For main resource requests (basically frames and shared worker), a service worker intercepts the request if the URL falls in its scope, and the service worker controls the resulting context.

- For subresource requests (every other request, it comes from a frame or worker coontext), a service worker intercepts the request if it controls the context that made the request.

I don't fully understand Chrome extensions but the first interception only happens if a service worker is registered for that chrome-extension URL being navigated to, and the second interception only happens if the service worker controls the context making the request.

So I'll close this. If someone can make a repro saying otherwise we can reopen.

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