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

Re: [CSP] Dynamic CSP

From: Mike West <mkwst@google.com>
Date: Wed, 4 Feb 2015 09:28:48 +0100
Message-ID: <CAKXHy=d=dUcc9-LMaNFrYaytc6O7CLG85-8vP=Q=-3r=4NWKGg@mail.gmail.com>
To: Crispin Cowan <crispin@microsoft.com>
Cc: Yoav Weiss <yoav@yoav.ws>, Deian Stefan <deian@cs.stanford.edu>, Joel Weinberger <jww@chromium.org>, Boris Chen <boris@tcell.io>, Dmitry Polyakov <dpolyakov@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Mon, Feb 2, 2015 at 11:52 PM, Crispin Cowan <crispin@microsoft.com>
wrote:

>  Hi. Sorry for chipping in late to the discussion, I was thinking about
> it.
>
>
>
> We have proposals for a bunch of complex algorithms about how the pinned
> policy and individual page policies interact. Those algorithms fall into 2
> categories: those that may not be flexible enough, and those that make my
> head hurt J
>
>
>
> Instead, may I propose something much simpler: a “pin” that just says “my
> <site> has a CSP, and here it is <pointer>” that forces the browser to go
> get it. Individual pages can over-ride that policy, but the policy applies
> to any pages that don’t have one. Don’t like how that works out? Go update
> your site’s policies, but *none* of your actual policies are pinned, so
> you have complete power to update anything you want whenever you want.
>

I don't think this addresses the use case that Yoav and Dmitry are pointing
to. Also, https://w3c.github.io/webappsec/specs/csp-pinning/ is relevant to
your suggestion (note that positive feedback from Microsoft (and Akamai!)
on https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0003.html
would be appreciated!)

Consider a single-page site that loads in content via XHR or `fetch()`.
Currently, setting a policy is only possible if it includes _every_
resource that might be loaded by the application in any of its many states.
That is, you'd need to whitelist all the admin resources, even though 99%
of the users aren't ever going to touch the admin tools.

This leads to overly broad policies that don't protect much of anything.
The question, then, isn't "How do we get a policy?", but "How do we allow a
page to modify the policy that's currently active in a trusted way?"

Yoav's suggestion is that we mark requests in some way as "CSP altering".
That seems reasonable.

My suggestion was that we split the policy into a baseline that can't be
changed, and a mutable layer that can be changed (along with an API to do
so).

I'm not thrilled with either of these, honestly. However, I think it's
worth exploring these variants to see if we come up with something good. :)

>
-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.)
Received on Wednesday, 4 February 2015 08:29:36 UTC

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