RE: [CSP] Dynamic CSP

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 ☺

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’m not sure, but I think this is also what Yoav is suggesting.

From: Yoav Weiss [mailto:yoav@yoav.ws]
Sent: Monday, February 2, 2015 2:45 AM
To: Deian Stefan
Cc: Joel Weinberger; Boris Chen; Mike West; Dmitry Polyakov; public-webappsec@w3.org
Subject: Re: [CSP] Dynamic CSP

Can we define a way for the origin server to send back a shiny new policy that the browser will then take into effect (even if it's less restrictive than the previous policy)?

Maybe a combination of a JS API that would tell the browser "accept a new policy from this XHR/Fetch request", a "gimme new policy" request header and a "new CSP policy" server header (as Boris suggested)?

On Fri, Jan 30, 2015 at 3:52 AM, Deian Stefan <deian@cs.stanford.edu<mailto:deian@cs.stanford.edu>> wrote:
Joel Weinberger <jww@chromium.org<mailto:jww@chromium.org>> writes:

> On Wed Jan 21 2015 at 10:04:25 PM Boris Chen <boris@tcell.io<mailto:boris@tcell.io>> wrote:
>
>> This appears to be a growing challenge. Looking at Facebook and LinkedIn,
>> we've noticed a similar design pattern.
>>
>> Looking superficially at spfjs, perhaps the ideal solution would be to
>> send "CSP fragments" to update the page's CSP along with the page fragments
>> that are updating the page. Could a new http csp response header for the
>> XHR call be created for this purpose?
>>
>>
>>
>>
>> On Wed, Jan 21, 2015 at 9:24 PM, Mike West <mkwst@google.com<mailto:mkwst@google.com>> wrote:
>>
>>> Hi Dmitry! Bubbling this back up, as it didn't get much traction when you
>>> initially posted.
>>>
>>> Dynamic policies are indeed a challenge. The issue is simple: if an
>>> attacker can execute script on your page, she can open up your policy to do
>>> whatever she likes. That seems like something we should avoid, as it would
>>> significantly reduce the protections CSP provides.
>>>
>>> That said, it's clear that a static policy is hard to implement for truly
>>> dynamic sites that load in content from a variety of sources. I don't have
>>> any good ideas in this area.
>>>
>>> The refresh-url concept is an interesting one, but it relies on a
>>> synchronous request to fire and return before we can make security
>>> decisions about whether to allow resource loads. It's not clear that that's
>>> the right answer, if only from a performance perspective.

If the policy will always be less-restricting, is there a reason
it needs to be synchronous?

>>>
>>> One thing that comes to mind would be to define a new header,
>>> `Mutable-Content-Security-Policy`, or something similar, and perhaps only
>>> allow it in combination with a (loose) `Content-Security-Policy` header.
>>> It's not clear that that would really help your use case, however, but it
>>> would mitigate the issue of an attacker loosening a policy; for instance, a
>>> site could always enforce a policy like `default-src 'self'`, and then
>>> layer a more granular mutable policy on top. That mutable policy could be
>>> anything, but wouldn't be able to loosen itself beyond the policy set in
>>> the existing header. Does that sound like a sane thing to explore for CSP3?
>>>
> I sort of have the opposite view of a Mutable-Content-Security-Policy
> header, where I think it would make sense to allow programmatic changes to
> the CSP if and only if there is strong CSP XSS protections (namely no
> 'unsafe-inline' and 'unsafe-eval') as that would be a pretty good
> suggestion that executing scripts are the ones the developer intended (and
> not an attacker), thus changes to the CSP would be from the developer and
> not an attacker.
>
> But, yeah, this is a hard problem all around.

Assuming that such an API would always allow code to make the policy
more restricting, the Mutable-CSP proposal seems like a reasonable
direction towards loosening CSP. +1 for exploring this in CSP3

One of my concerns is how this will impact DOM API if we allow code to
get at the current CSP? [1]

Deian

[1] https://lists.w3.org/Archives/Public/public-webappsec/2015Jan/0318.html