- From: Deian Stefan <deian@cs.stanford.edu>
- Date: Thu, 29 Jan 2015 18:52:39 -0800
- To: Joel Weinberger <jww@chromium.org>, Boris Chen <boris@tcell.io>, Mike West <mkwst@google.com>
- Cc: Dmitry Polyakov <dpolyakov@google.com>, "public-webappsec\@w3.org" <public-webappsec@w3.org>
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