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> wrote:

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