Header for dissalowing SW registration (and implicitly removing SWs)?

[slightlyoff]

Pending discussion of CSP policy, it seems as though we should either craft the CSP support in such a way as to dissalow registration of SW's based on header (e.g., so that rawgithub.io can continue to function) and potentially unregister existing SW's when it encounters such a directive.

/cc @jakearchibald @mikewest

[slightlyoff]

Will attempt to capture the major issues involved here. First, background for those just tuning in:

1. Service Workers are same-origin-only. That is, the script that is registered must be served from the registering origin. It may subsequently use importScripts() to compose x-origin scripts, but as a mitigation against 3rd parties (or transient, hostile first parties) the SW script itself must remain under control of the source origin.
2. Service Workers are HTTPS only. See SSL/TLS Only? #199 for discussion. This mitigates the risk of hostile portals, etc.
3. The max cache duration for SW scripts is 1 day. Past that mark, the UA will go to the network to try to fetch a new script. This is meant to help mitigate against intermittent failure/pwnage.

The remaining threats revolve around compromised same-origin content. The naive version of this (which has been discussed at length) is the university homedir scenario. It's already the case that this content has full authority relative to other content on the origin, but SW's potentially exacerbate this.

Another scenario worth considering is a transient pwning: a malicious SW could be served from the location of an (otherwise valid) image URL. Since it won't successfully update once the hole is closed, it may appear silent to site owners and users might be pwn'd for a long time. It was proposed at one point to remove SWs on 4xx responses, but this doesn't address the correct-but-doesn't-parse cloaking (and significantly complicates multi-datacenter rollouts).

The proposed mitigations for these scenarios are:

1. a header that's sent with the request for the SW script identifying it as such. Combined with the 24 hour max age for pings, this should help administrators keep the window of vulnerability small and provide a path to remediating issues once discovered.
2. potential extensions to CSP to control which bits of URL space are allowed to register SWs. SWs will respect the script-src attribute already, but separate control may be desirable to disable SWs only as they have the power to more persistently affect content.

[johnmellor]

It doesn't seem like the header would help for a shared host (e.g. university homedirs) that allows directories to set their own headers, e.g. using PHP.

How about instead having the highest allowed SW scope be set by the path of the SW? For example, if the SW is hosted at https://example.com/sw.js, then https://example.com/foo/bar.html should be allowed to register that SW for any same-origin scope, including '/*'. But if the SW is hosted at https://example.com/foo/sw.js, then the highest allowed scope would be '/foo/'. Thus you would only be able to intercept content in the same directory or subdirectories of the location of the SW, which it is more likely that the author of the SW already has access to.

[jyasskin]

It's a tricky problem. Limiting the scope to be under the current path, with no escape via a header, would prevent sites like https://mail.google.com/mail/u/0/, https://github.com/slightlyoff/ServiceWorker/issues, and http://www.yelp.com/biz/the-original-ghirardelli-ice-cream-and-chocolate-shop-san-francisco from registering a single service worker for their whole site given a deep link. They'd probably have to redirect through the root on every request that didn't already have an active service worker.

Using a header to set a more permissive maximum scope would leave the university sites broken, but it might let more sites like rawgit.com keep working by default.

I suspect @slightlyoff prefers the opposite default at least partly because https://tools.ietf.org/html/rfc6454#section-3.4.3 recommends against trying to subdivide origins.

However, I'm still worried about the now-stronger requirement that sites need to isolate each user to their own sub-domain or serve this new header. What fraction of the web is this going to make exploitable?

[jakearchibald]

Limiting the scope to be under the current path, with no escape via a header, would prevent sites like

I think @johnmellor is proposing preventing registration for scopes parent to the service worker js file, not scopes parent to the registering page. It does solve the homedrive issue. Being able to put a file there becomes "proof" of ownership.

Pretty sure we had a discussion about this already, but can't find it. Here are the issues:

• Restrictive over worker urls - if you want to control "/*", your worker must be at the root
• The default value for scope becomes a poor default, although its default could be determined by the worker url. For "/whatever/worker.js" the default scope would be "/whatever/*". This could be a gotcha.

[jakearchibald]

As for the SW CSP stuff, there's a discussion over at #113

[devd]

I vote for sticking to origin based policies and a HTTP header to allow/disallow registrations. https://tools.ietf.org/html/rfc6454#section-3.4.3 is based on a number of previous bad experiences trying to get anything more finer-grained than origins.

Lets stick to origins and if sites want finer-grained isolation, then can use sub-origins http://www.chromium.org/developers/design-documents/per-page-suborigins

[slightlyoff]

Fundamentally insecure sites that don't control outbound headers can't be helped, I think. Nearly all other origin-based resources (IDB, storage, etc.) can be poisoned. Restricting SWs here only changes the scope of the poisoning.

I'd previously considered the path restriction (can't quickly find the bug where I proposed it) but ended up deciding against it based on the ability of evil content on an origin to screw with so many other aspects of content for that origin. The argument from defense in depth is intresting to me, though.

/cc @jakearchibald @jungkees @mikewest

[johnmellor]

Nearly all other origin-based resources (IDB, storage, etc.) can be poisoned.

Poisoning at least requires you to find a vulnerable script that reads and evals (or similar) a value from storage. Whereas installing a SW grants you god-mode on all future requests to the origin.

If we don't want to split origins based on paths (and I understand there are good reasons for this), then perhaps the best mitigation is to require Service Worker scripts to always be located in the root directory?

[piranna]

This would difficult usage... What about like CSS, where paths are relative
to the CSS file? We would forbit to register a SW in a path lower that the
SW or the current page, whatever of both is lower...

[slightlyoff]

@piranna : agreed.

The better alternative (which I had previously considered) is to not allow the page to register for a scope broader than it's current-path-component + "/*". Constraining the location of the script itself doesn't buy you much. The real issue is the scope. There will always be ways to trick a well-written worker script into doing "bad" things when under the control of an attacker. The only meaningful defense is to ensure that attackers can only attack themselves.

The path restriction on scope has the benefit of perhaps enabling sites like github.io from not needing to freak out as soon as a browser supports SWs. Have opened #253 to discuss further.

I'd like to refocus this issue on design for headers for detection/remediation/control. We clearly need them as well.

[annevk]

I don't see how the CSS argument makes sense. If it is associated with a document and that document is associated with a service worker, that service worker will see all requests.

[piranna]

I asking about using a similar scheme to how CSS works, where the referenced paths (for example for images) are relatives to the CSS file. In that case, paths would be relatives to the SW file. This way we can use the same SW from /foo/index.html and /foo/blah/index.html, being for example the paths to the SW utils/sw.js and ../utils/sw.js respectively. Later, we can set that the SW can't be able to manage content in a lower level of the top common path, in that case, SW could manage anything on /foo/* since the /foo path frament in common for both, but on /*. Is it my idea more clear now?