Re: Proposal: Compositional CSP

Hi Stefano,

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
https://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:

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