Re: [CSP] Dynamic CSP

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.)