W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2015

Re: Service workers and CSP

From: Mike West <mkwst@google.com>
Date: Tue, 27 Jan 2015 14:38:16 +0100
Message-ID: <CAKXHy=fBPOXs6yN2WWndcQ9XzPhHU0yDzmWYvTqpObBQfeh=Bg@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: WebAppSec WG <public-webappsec@w3.org>, Jake Archibald <jaffathecake@gmail.com>, Alex Russell <slightlyoff@google.com>, Jungkee Song <jungkees@gmail.com>
1. Hopefully this interaction will clarify itself when we get around to
rewriting CSP in terms of Fetch. That's on my todo list, it just keeps
getting bumped further down. Working on it.

2. I think our vague plan was to check outgoing requests as well as
incoming responses, similar to what we've ended up with for MIX. That is,
we would attempt to prevent the SW from giving us something for a
particular request that wouldn't have been allowed as an outgoing request.

I don't really understand the issue with `event.default()`. Why does that
passthrough mechanism not work?

-mike

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

On Tue, Jan 27, 2015 at 2:22 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> Given a worker A and its service worker SW the path to the network is:
>
>   A -> SW -> network
>
> Both A and SW can have a CSP policy.
>
> If SW's fetch event is not handled the effective path to the network is:
>
>   A -> network
>
> An equivalent to that was going to be event.default() but that does
> not work: https://github.com/slightlyoff/ServiceWorker/issues/607
>
> This means that enabling SW makes A's CSP policy a lot less useful. I
> think we already acknowledged this to some extent. I'm mostly sending
> this to make sure I have not missed anything.
>
> Note that the things we previously thought we could rely on have not
> changed:
>
> * A synthetic Response object has no url so could be blocked by A
> similar to eval et al.
> * If a Response object has a url it is the one from the network.
>
> The caveat here is that at the moment we do overwrite this url field
> similar to how redirects are handled (step 6 of the main fetch
> algorithm). If CSP cannot hook adequately around there we might need
> to have an "original url" slot on Response objects or something like
> that.
>
>
> --
> https://annevankesteren.nl/
>
>
Received on Tuesday, 27 January 2015 13:39:13 UTC

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