W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2014

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

From: Brian Smith <brian@briansmith.org>
Date: Mon, 21 Jul 2014 16:58:55 -0700
Message-ID: <CAFewVt5p41Q_p_i-8M1EEEPO3jjtSDHR4hL-ea4w9qZynfrDVA@mail.gmail.com>
To: Jeffrey Yasskin <jyasskin@google.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Anne van Kesteren <annevankesteren@gmail.com>, Jake Archibald <jakearchibald@google.com>, Alex Russell <slightlyoff@google.com>
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,

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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:39 UTC