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

On Mon, Jul 21, 2014 at 4:12 PM, Jeffrey Yasskin <jyasskin@google.com> wrote:
> 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.

Even without ServiceWorker, you really need to block
user1/evil_thumbnail.js from executing *any* code, right? It seems
unlikely to me that a website would feel comfortable executing any
code within user1/evil_thumbnail.js *except* ServiceWorker stuff. So,
why wouldn't the new CSP path support be sufficient?

> 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.

Again, AFAICT these concerns aren't ServiceWorker or even JS-specific.
If somebody's managed to replace your homepage with a cached-forever
response using plain old HTTP, then that's also supremely terrible,
right?

> * 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.

I think doing either of the following instead would be better than
adding a new Content-Type header name Service-Worker":

    Content-Type: application/javascript; serviceworker="1"
    Content-Type: application/javascript-serviceworker

Cheers,
Brian

Received on Monday, 21 July 2014 23:59:22 UTC