Re: [CSP] Dynamic CSP

Joel Weinberger <jww@chromium.org> writes:

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

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

Received on Friday, 30 January 2015 02:53:11 UTC