Re: Proposal: Compositional CSP

Hi, 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:

> 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
>>
>
>
> "Nota automatica aggiunta dal sistema di posta.
> Please note that the above message is addressed only to individuals filing
> Italian income tax returns."
>