Re: [CSP] Dynamic CSP

On Wed Jan 21 2015 at 10:04:25 PM Boris Chen <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> 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.
>>
>> 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.

>
>> -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 Mon, Aug 11, 2014 at 11:14 PM, Dmitry Polyakov <dpolyakov@google.com>
>> wrote:
>>
>>> Hi,
>>>
>>>
>>> I’m a developer working on an implementation and deployment of Content
>>> Security Policy for YouTube web clients.
>>>
>>> Recently, I faced a problem with CSP, so let me describe my use case
>>> before diving in further.
>>> On YouTube.com we mostly deliver page content using a framework that
>>> allows us to update the page in chunks via XHRs. That includes
>>> navigating between “pages”. We only load content and resources that
>>> need to be updated and preserve everything else to improve latency. We
>>> call this structured page fragments, or “spf”. (The framework itself
>>> is available here https://github.com/youtube/spfjs)
>>> That means that whenever we serve the first spf-enabled page to a
>>> client, in order to define content security policy, we need to include
>>> _the entire_ list of all the resources YouTube.com pages could
>>> utilize, connect to, iframe, embed and so on. With the current
>>> infrastructure that we have in place, and our extensive integrations,
>>> that becomes a _really_ long list.
>>>
>>> I believe a large amount of web sites, especially high-traffic ones,
>>> are adopting this “web application" model, in which new content is
>>> mostly fetched via XHRs as opposed to loading new pages.
>>>
>>> Given that, it seems to me that there should be a way to refresh a
>>> delivered policy on a given page dynamically (i.e. without reloading
>>> that page). By "refreshing" I mean removing the enforced policy(ies)
>>> and enabling a new one(s), as opposed to strengthening enforced
>>> policies (with the use of meta elements for example).
>>>
>>>
>>> For example, it could be in a form of another directive,
>>> refresh-uri: uri-reference
>>> that would allow clients to issue requests to refresh-uri (via XHR or
>>> adding/updating a corresponding meta element(s), or making a browser
>>> send a request every time history is updated by the current document,
>>> or something else) that will return a new policy to enforce (i.e.
>>> Content-Security-Policy and/or Content-Security-Policy-Report-Only
>>> headers) and a 204 status. I’m not sure about security implications
>>> here. The obviously unclear thing would be retaining nonces (or
>>> updating them somehow).
>>>
>>> Another thing that would help reducing the policy indirectly is adding
>>> nonces or something like nonces to other directives (maybe hashes
>>> too). In this case nonces would serve a bit different purpose than
>>> allowing unsafe-inline execution.
>>>
>>> Unfortunately, I don’t know of prior discussions on these topics, so
>>> maybe there were already some clever solutions proposed.
>>>
>>>
>>> Please let me know what do you think.
>>> Dmitry.
>>>
>>
>>
>