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: Jeffrey Yasskin <jyasskin@google.com>
Date: Mon, 21 Jul 2014 18:27:24 -0700
Message-ID: <CANh-dXkr0q5y8YtFP3aT3Q6=MOn1s=HxcXNCqgfktNLAnHjxqA@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
On Mon, Jul 21, 2014 at 4:58 PM, Brian Smith <brian@briansmith.org> wrote:
> 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?

Sure, so after the attack you set "script-src /scripts/" on all
requests. The update request arrives for the malicious Service Worker,
but that's the protected resource, not any of the kinds of fetches
listed in http://w3c.github.io/webappsec/specs/content-security-policy/#directive-script-src
after "Whenever the user agent fetches a URI", so script-src doesn't
block it under the current spec.

I think it'd be plausible to say that a non-matching script-src (or
maybe child-src?) on the service worker scriptURL request should cause
the request to fail. (It's basically equivalent to my straw man, just
re-uses existing syntax with new semantics.) Is that the direction
this group wants to go?

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

It's quite bad, but I think it's impossible to do without both a
privileged network position and either a non-HTTPS site or a malicious
CA, and shift-refresh fixes it once the user has left the MitM. With
Service Workers, shift-refresh avoids the service worker for the
current fetch and may be spec'ed to force [[Update]], but the service
worker comes back on the next load unless the update unregisters it.

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

Those are also plausible. application/javascript-serviceworker is
reminiscent of text/cache-manifest.
https://tools.ietf.org/html/rfc4329#page-10 doesn't define a
serviceworker parameter: is that the sort of thing we'd want to add
here? In what ways is a new content-type better than a new CSP
directive?

Thanks,
Jeffrey
Received on Tuesday, 22 July 2014 01:28:11 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:06 UTC