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

Forwarding this to the list on behalf of it's senders.

+Simone Onofri <simone@w3.org> Perhaps you could ask someone on the W3C
side to look into posting permissions on the list?

-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