Proposal: Compositional CSP

# Stefano Calzavara (7 days ago)

Dear WebAppSec members,

our research group at Università Ca' Foscari Venezia has been working on CSP during the last few months. Based on the analysis of real-world scenarios, we observed that the static nature of CSP white-lists creates troubles at configuring CSP correctly. Strict CSP (based on nonces) is definitely a step in the right direction, but we believe it does not solve all the issues we found in the wild, such as HTTP redirects and advertisements. We are thus proposing Compositional CSP, an extension of CSP where the enforced content security policy is built from an initial policy written by the page developers and the policies supplied by the providers of the included contents.

The results of our research will be presented at USENIX Security 2017, you can find a pre-print of the paper attached to the present email. I hope you will enjoy the reading and that our idea could be inspiring to address the expressiveness issues of CSP we identified. Do you think Compositional CSP could be helpful in real browsers?

Best,

Stefano

Contact us to advertise here
# Artur Janc (3 days ago)

Thanks for sharing the proposal! I read your paper and wanted to share some comments:

First of all, the problem you're tackling -- the insecurity of CSP whitelists -- is definitely important, and the solution based on separating the responsibility for defining the policy between the developer and widget authors seems decidedly more flexible than the status quo. Introducing this separation could make the job of developers easier and make policies more maintainable, since the developer wouldn't have to worry about changes to the resources loaded by their widget (assuming adoption of your proposal by their authors).

Second, I like how your proposal fits into the existing state of CSP, in that you've considered the backwards compatibility and how it might be deployed in practice, and paid attention to conceptual similarity with current CSP. If we had the ability to define whitelists more flexibly, I imagine that this could also go hand in hand with alternative proposals for adopting CSP, such as the nonce-based approach, and allow developers to enforce both kinds of restrictions as they see fit.

The main area where I see difficulties is the granularity of whitelist definitions. That is, currently a large majority of developers define their whitelists at the granularity of an origin, without enumerating individual JS resources. The reason for doing so is that in many complex applications it is non-trivial to list all scripts which are loaded by the application, even without taking into account scripts indirectly loaded by widgets. While a developer could enumerate all their directly loaded scripts, this introduces a significant maintenance burden because the policy would have to be continuously updated as the application changes. So even if we have composition, developers would still likely whitelist the origins of their non-widget resources, commonly 'self' and CDNs.

For similar reasons it is not always feasible for widget authors to know the exact locations of scripts which might be loaded by their widgets at runtime -- locations of the resources might depend on dynamic configurations, messages from the embedding origin, etc. As an example, the top origins of "Script Providers" in Table 2 in your paper are www.googletagmanager.com and apis.google.com. The former is a container which allows the loading of user-defined analytics scripts and other resources, and the server doesn't know which resources will be fetched when the script executes. The latter is an entry point for exposing a wide variety of APIs which the developers can use once they include the loader, and it also doesn't a priori know which modules will be loaded. In neither of these cases is it easy to define the exact subresource locations for the widget; and if the author defaults to an origin-level whitelist, this results in an insecure policy, just as currently when the developer whitelists the entire widget origin.

Perhaps another complication is the situation where the widget uses JSONP or a similar pattern (as is the case e.g. in apis.google.com/js/api.js?onload=user_callback). Since this resource must be allowed by the policy, neither the developer nor the widget author can prevent an attacker with an HTML injection from using the same endpoint to execute arbitrary functions.

Overall, I like where your proposal is going, and I think composition is a useful concept. However, I'm not entirely convinced that solving the problem of composition without solving the problem of source expression granularity (and the adoption/maintenance costs of doing so) will result in policies which have significantly better security properties than what we currently see. Perhaps tackling the whitelist granularity issue could be an interesting complement to your current work ;-)

Cheers, -Artur

On Fri, Jun 9, 2017 at 10:16 AM, Stefano Calzavara calzavara@dais.unive.it

wrote:

# Stefano Calzavara (2 days ago)

Artur.

Thank you very much for your comments, much appreciated! I see where you are coming from and I do agree with you that policy granularity is an issue in the current state of CSP. However, I also think that part of the complexity may be tamed by the development of automated tools for policy writing, which is something partly addressed by current research (not by us).

I would love to discuss these issues more in detail with you and anyone else who is interested in this kind of problems. Let's keep in touch, if you like, and anyone who has something to say on the topic is very welcome to add something more!

Cheers,

Stefano

Il 13 giu 2017 11:45, "Artur Janc" aaj@google.com ha scritto:

Want more features?

Request early access to our private beta of readable email premium.