Integrity for service workers

[hlandau]

I think it would be valuable to support SRI for service worker JS files.

Reasoning: There's a lot of controversy about web-based crypto applications. Namely, that they're never truly secure because they can be compromised by changing the code shipped to the client implementing the crypto, and there's a lack of visibility for client-side code updates on the web.

If a service worker could be constrained to have a specific hash, that service worker could, in turn, implement a site-specific content verification policy. It could, for example, chainload another service worker file after verifying a cryptographic signature, so it wouldn't prevent frequent updates. Applications would be free to define policies around those updates that quell any concerns about the visibility of future updates to a codebase. As an arbitrary example, signatures from multiple unrelated parties could be required. Having verified a service worker implementing such a trust policy, the use of such a service worker would be verified simply via its hash. Thus adding SRI for service workers has the potential to create a programmable root of trust for an entire website. In particular, service workers are designed to have great longevity as things a browser remembers.

I could envisage someone developing an addon that ships a preloaded list of service worker SRI pins for popular origins providing cryptographic applications. People could update their list of pins based on what they're willing to trust, which would make code updates more visible for high-security web applications.

These aren't the only use cases; if you don't find them compelling, there are others. Because a service worker has extremely powerful control over an origin, and is remembered for long periods, a compromised service worker file is potentially one of the most disastrous things that could happen to a site. I'd therefore argue that extending SRI to service workers should be a fairly high-priority item, relative to other things to which SRI might be extended, like images.

Proposed API: Add an integrity field to the options object passed to ServiceWorkerContainer.register().

[EGreg]

Anyone ever implemented this?

[llebout]

It's been a while but I'd like to express once again my support for this feature, very much needed.

[mozfreddyb]

I'd argue SRI is only really useful for same-origin resources and whether ServiceWorker ought to support cross-origin at all is still debatable (see linked issue above).

If the folks over there agree that cross-origin ServiceWorkers are a good idea (I'll remain skeptical), then you'd need to file for support on their end. They are specifying how the options object is parsed and they end up invoking the "fetch", that would need to be annotated with integrity metadata.

Please file at https://github.com/w3c/ServiceWorker/issues/new/choose, once the linked issue 1518 has come to a conclusion.

[annevk]

That's been proposed and rejected in the past, even with SRI, as the risk of injection is too great.

[mozfreddyb]

Ah yes. I can see there are web-platform-tests to ensure that browsers won't allow cross-origin registrations and they seem to pass with all browsers. (looking at https://wpt.fyi/results/service-workers/service-worker/registration-scope.https.html?label=experimental&label=master&aligned and https://wpt.fyi/results/service-workers/service-worker/registration-script-url.https.html?label=experimental&label=master&aligned and https://wpt.fyi/results/service-workers/service-worker/registration-security-error.https.html?label=experimental&label=master&aligned)

I'm taking it that the issue on ServiceWorkers spec will resolve in them adding a cross-origin check and will resolve this one here as closed then.

[hlandau]

SRI isn't only useful for cross-origin resources, same-origin SRI would be especially valuable for service workers; see rationale in the original post of this issue.

It looks like you're right about the correct place to file this issue — thanks for pointing me in the right direction.