-
Notifications
You must be signed in to change notification settings - Fork 316
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support subresource integrity for service workers #1680
Comments
It's for that very reason that SW pinning via a mechanism like SRI seems like it would only enable such an attack to persist after I've got my website back—anything which protects a web app against takeover by its future owner also necessarily "protects" a web app against re-takeover by its rightful owner after a compromise. After all, what's the *technical* difference between these?
If you're proposing we use WebExtensions as failsafe-canaries/breakers/SPoF-custodians for high-stakes web applications, aren't there ways to achieve that under the ecosystem as it currently exists, without implementing any new browser functionality proposals? (e.g. auditing ServiceWorker installations before they occur) |
I share the same concerns. I hadn't thought about web extensions webRequest.filterResponseData, but sadly it seems to be supported on Firefox only and might be deprecated in the long run Within the same line it also worries me the fact that pin sets for certificate pinning are safeguarded by the browsers vendors, we are losing control, as developers and web users it's all pretty sad, I'm starting to lose faith in the w3c and other organizations pushing web standards |
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 would in general be quite valuable.
Proposed API: Add an integrity field to the options object passed to ServiceWorkerContainer.register().
Originally proposed in the SRI repo but moving it here as this appears to be the correct repository for discussion. This is also related to #822 but proposes a different, and arguably much simpler solution for a related set of use cases.
The text was updated successfully, but these errors were encountered: