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

Hi

ServiceWorkers are ridiculously powerful and so I actually advocate for
both: request headers and response headers.

For request headers, how about a "CH-Context: ServiceWorker"? That makes
more sense to me than "Service-Worker: script" and it also follows the
client hint format.

For response, since SW shouldn't wait on CSP2.1, how about a simple header
that someone can send to disable all SWs registered on the domain?
"ServiceWorker: None" or something like that?

In an ideal world, we would insist on what Brian suggested---a different
content type. An invariant on the web platform is that "text/html" (and its
siblings) are the only content-types that grant code execution
capabilities. ServiceWorker will add text/javascript to that list, which is
giving new powers for existing files.

Additionally, Jeffrey mentioned that path-based restrictions don't work.
While this is mostly true, a lot of services rely on capability URLs and
registering a SW will allow an attacker to learn about all the URL requests
on that domain, which could leak capability values and allow for tracking.
For example, controlling a js file and a html page or injection didn't let
me track all urls the user will visit in the future (24hrs?).

Not sure what the right trade off is. Given the previous lessons from
AppCache that you mentioned, the request and response headers to grant
control make sense to me.

Although, I do wonder: is it really that hard to ask github to let devs set
content type sometimes?

cheers
Dev
 On Tue, Jul 22, 2014 at 3:02 AM, Mike West <mkwst@google.com> wrote:
> On Tue, Jul 22, 2014 at 1:12 AM, Jeffrey Yasskin <jyasskin@google.com>
wrote:
>> 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.
>
> This is conceptually similar to 'frame-ancestors' in that it allows a
> subresource to control the way it's used by an embedder. I haven't
> thought through all the impacts, but it seems like something that's
> pretty reasonable to consider.
>
> Are there cases beyond "Don't use this file as a service worker!" in
> which this would be useful?

I don't know of any offhand. It's also not obvious that the exact list
of fetch contexts is the right set of keywords for this directive (or
even that the fetch contexts have their final values). Another
approach might be to add a new kind of directive-value where "context
not-serviceworker not-image" would allow the resource to be used in
any context except serviceworker and image. Then we could define only,
say "any" and "not-serviceworker" or "not-child", and leave further
use cases for the future. I'm not entirely happy with this option
either.

>> * 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.
>
> Brian's Content-Type proposal makes more sense to me than a new HTTP
> header entirely. I think it makes sense regardless of whether we adopt
> a 'context' directive.

It turns out that requiring a dedicated Content-Type isn't great: it
requires that a host like github that already uses origins for
isolation add explicit support for Service Workers before any of their
users can use it. Apparently this was a big problem for appcache. A
CSP directive or "Service-Worker: script" header instead requires
hosts that use paths for isolation to change, and this as a security
fix. It's not obvious to me that this is the right security/usability
tradeoff, but it's plausible because paths don't work for isolation
anyway.

Also note that the "Service-Worker: script" header would be in the
request, while the Content-Type header would be in the response, so
they're not precisely comparable.

IIUC, the main benefit of a request header over a response header
(either CSP or Content-Type) is that the request header shows up in
server logs before the XSS is even detected, while CSP reports only
show up after the blocking CSP is added.

>> * What CSP directive and values make sense for this?
>> * Which spec should define this initially, CSP or Service Workers?
>
> It should end up in CSP if that's the route we decide to take, but
> there's no harm in defining it in SW to begin with. Given that CSP2
> just hit LC, putting it into SW is almost certainly a faster way to
> get it into an implementable state.

SG.