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

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.

Received on Tuesday, 22 July 2014 17:21:08 UTC