Re: Extending CSP nonces and hashes and allowing the specification of finer-grained directives to accommodate web workers

> On 18 Mar 2025, at 09:48, Mike West <mkwst@google.com> wrote:
> 
> Forwarding this to the list on behalf of it's senders.
> 
> +Simone Onofri Perhaps you could ask someone on the W3C side to look into posting permissions on the list?
> 

on it

> -mike
> 
> 
> ---------- Forwarded message ---------
> From: Francis Dolière Somé <doliere.some@cispa.de>
> Date: Tue, Mar 11, 2025 at 10:46 PM
> Subject: Extending CSP nonces and hashes and allowing the specification of finer-grained directives to accommodate web workers
> To: Mike West <mkwst@google.com>
> 
> 
> Dear Mike,
> 
> We hope you're doing well. We tried to submit this request to the CSP3 editors using the W3C mailing list, but for some reason, the mail was rejected. We would really like feedback on this proposal and to know if the community would be interested in discussing it further. You will find below the original mail we tried to send! Thanks in advance for your time and any feedback.
> 
> <<
> In a recent study, we analyzed and concluded that CSP is limited in its expressiveness and applicability to web worker contexts, i.e., shared, dedicated, and service workers. In particular, the finer-grained elements of the mechanism, namely nonces, and hashes, cannot be specified in policies deployed on workers. 
> In a follow-up study involving the analysis of millions of workers in the wild, we found numerous instances of server-side and client-side XSS in these contexts, involving URL parameters flowing into JavaScript response bodies or the specific importScripts method of workers, vulnerable messages, and web push notifications events, etc. Among the countermeasures we experimented with, in particular with a proof-of-concept (PoC) using an HTTPS Proxy that would play the role of a browser supporting our proposal:
> 
> Nonces and hashes can be specified as additional attributes when spawning workers or importing additional scripts in their contexts. The example below shows the case of the service worker registration API 
> navigator.serviceWorker.register("/sw.js", {
> scope: "/",
> nonce: "r@nd0m5679",
> integrity: "sha384-B@5E64"
> })
> 
> Besides the `scope` and other standard attributes, one could indicate nonces and hashes that must be present in the CSP or match the workers’ responses before browsers can effectively create them. These changes are fully backward compatible with worker APIs, as non-supporting browsers would ignore them. We extended the same idea to the `importScripts` API as follows:
> 
> importScripts("//cnd.com/lib.js", {
> nonce: "r@nd0m5679",
> integrity: "sha384-B@5E64",
> crossorigin: "anonymous"
> })
> 
> For the familiar reader, the importScripts API only accepts strings as arguments, not object literals. So, the change we introduce is not backward compatible. A solution would be to implement this change using a different global method name or, more likely, adapt the importScripts function to accept object literals with security attributes. 
> 
> The enforcement of nonces and hashes would follow the same logic as for web pages: to be honored, nonces specified on the workers’ APIs must be present on the worker-src directive (or its fallback child-src, script-src, and default-src directives). As for hashes, the values of the `integrity` attributes must match the digests of the responses before they are executed. The same logic would apply to the importScripts API, provided the baseline CSP is the underlying worker’s.
> 
> 
> Finally, following and bearing from the current trend in CSP3, which is in the specialization of directives (e.g., script-src-elem and script-src-attr that fallback to script-src in web pages), the worker-src directive could be specialized into `service-worker-src` (for service workers), `shared-worker-src` (for shared workers) and `dedicated-worker-src` (for dedicated workers) that all fallback to worker-src when missing. This proposal is also fully backward compatible, as non-supporting browsers would ignore the new directives. Yet, the primary intuition is that not all workers have the same capabilities. Service workers, for instance, are way more privileged than shared workers, who, in turn, are more persistent than dedicated workers. In the current specification, a weak worker-src directive conjugated with a website with vulnerable workers’ endpoints allows the attacker to choose the types they would spawn (i.e., more likely service workers to be more impactful). Developers would then play more cautiously and securely with the different finer-grained directives and restrict the various types of workers accordingly.
> 
> 
> We have working demos where we demonstrated the feasibility of all these features from a browser and developer perspective. We would be happy to share them with the interested reader. We are pleased to follow up and discuss these materials further.
> >>
> 
> Thanks 
> Best regards,
> 
> Dolière Francis Somé
> Research Group Leader
> CISPA Helmholtz Center for Information Security

Received on Tuesday, 18 March 2025 08:51:17 UTC