[CSP] Directive to disallow a response from being used as a Service Worker

In https://github.com/slightlyoff/ServiceWorker/issues/224 we've been
discussing ways to prevent XSS exploits from installing malicious
service workers and to recover if one does. For example, imagine that
I manage to copy a file I control to
https://example.com/user1/evil_thumbnail.js and then run code on
https://example.com/ that calls
navigator.serviceWorker.register('/user1/evil_thumbnail.js'). We'd
like to have ways to prevent that register() call from working, and to
be able to unregister the resulting service worker after the XSS is
discovered.

One way to do this would be to define a CSP directive that says in
what contexts (http://fetch.spec.whatwg.org/#concept-request-context)
the protected resource may be used. As a straw man, a site could send

Content-Security-Policy: context 'script' 'sharedworker' 'worker';
report-uri /csp-failure

for most of its .js files but

Content-Security-Policy: context 'serviceworker'

for the few paths it intends to be used as Service Worker scriptURLs.
The [[Update]] algorithm in the Service Worker spec would then say
that a CSP failure causes the service worker to be unregistered.

Note that this directive would be different from a serviceworker-src
directive on an HTML file which could reject the initial call to
navigator.serviceWorker.register(). serviceworker-src can make XSS
harder to take advantage of, but it can't help recover from XSS since
the malicious service worker might prevent the HTML file from ever
being requested again.

* Are CSPs the right way to do this? Issue 224 also discusses a
"Service-Worker: script" header that could be sent with the service
worker script request, which would be an alternate way to let servers
handle XSS.
* What CSP directive and values make sense for this?
* Which spec should define this initially, CSP or Service Workers?

Thanks,
Jeffrey

Received on Monday, 21 July 2014 23:13:43 UTC