Re: On the Insecurity of Whitelists and the Future of CSP

I commented in our call last week that I didn't think strict-dynamic
addressed all the issues brought up in the paper, but we got on another
topic and I'm not sure I ever indicated what I meant by that.

The fact that so few policies in the wild are good speaks to me of two
things:

1. Making policy that works with current websites is hard.  strict-dynamic
should help with this issue.
2. We haven't clearly articulated how to use CSP and what threat models it
works with.  Basically we have a serious usability problem for folk doing
deployment.  That's the part I'm not sure we're making enough headway in.

I think if we care at all about the security of the web, we need to address
#2 as well as #1.  I don't think our issue is so much that the information
isn't there, but more that the spec is long and (by necessity) it has to
focus a lot on edge cases that make it easy for a reader to get confused or
mislead.  I know we had some talks about CSP-Lite and Brad's started work
on non-normative documents explaining concepts.  But I'm also worried that
part of our problem is that deployment doesn't tend to happen until after
standardization for many groups, and we're not getting feedback until
it's... well, not quite too late, but later than it would need to be for
optimal results.

I'm not sure what the solution would look like.  Probably a combination of
things: Improved docs, some user education, some attempt to recruit a few
more invited experts who do regular deployment of security policy, better
tools and tests, something else?  But now that the shortcoming has been
quantified so clearly, we have the ability to track progress and perhaps
set some goals for what we'd hope to see in policies in the wild in a year
or two.

 Terri

On Wed, Sep 7, 2016 at 1:14 PM, Artur Janc <aaj@google.com> wrote:

> This paper is based on the results that we've discussed a bit at the last
> F2F, and which were the original motivation for 'strict-dynamic' -- they
> came up in some of the discussions we had here around the feature, so many
> folks are probably familiar with the details.
>
> The best outcome I can hope for is if we could consider the past failings
> of CSP and think about how we can fix them to build something more useful.
> There are lessons that can be applied right away in CSP3 (e.g. promoting
> nonces/hashes as a better script blessing mechanism), and some general
> takeaways to consider when designing its successor (e.g. avoiding
> unnecessary complexity, improving developer understanding of the mechanism
> and the security benefits it offers, less ugly syntax, etc).
>
> There's probably also a meta-discussion to be had around the types of
> threats we're trying to mitigate, and an attempt to map how various parts
> of CSP or other specs address them. For example, there's almost never a
> security benefit of setting img-src, and it adds maintenance overhead and
> risks breakage when URLs change, but it's present in a large majority of
> policies; refocusing on the few bits that actually improve security would
> be really beneficial for the ecosystem.
>
> As a final meta-note I think so far we've been fairly lucky as an industry
> that malicious exploitation of XSS has been fairly limited (for many
> reasons; long story). However, we're giving webapps access to more powerful
> APIs and keep blurring the line between the web and native apps (we're
> already in a situation where XSS in some webapps is equivalent to remote
> code execution on the user's device) so these attacks will become more
> compelling. The web platform should really have stronger defenses against a
> class of vulnerabilities that's simultaneously the most common and the most
> damaging; solving other problems but not addressing this one means we're
> not serving our users as well as we should.
>
> -A
>
> On Wed, Sep 7, 2016 at 6:16 PM, Hodges, Jeff <jeff.hodges@paypal.com>
> wrote:
>
>> Apologies if this has already been posted here, I looked and didn't see
>> that it had...
>>
>> CSP Is Dead, Long Live CSP! On the Insecurity of Whitelists and the Future
>> of Content Security Policy
>> <https://static.googleusercontent.com/media/research.google.
>> com/en//pubs/ar
>> chive/45542.pdf
>> <https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/45542.pdf>
>> >
>>
>> Lukas Weichselbaum
>> Michele Spagnuolo
>> Sebastian Lekies
>> Artur Janc
>>
>>
>> ABSTRACT
>> Content  Security  Policy  is  a  web  platform  mechanism  de-
>> signed to mitigate cross-site scripting (XSS), the top security
>> vulnerability in modern web applications [24].  In this paper,
>> we take a closer look at the practical bene ts of adopting
>> CSP and identify signi cant  aws in real-world deployments
>> that result in bypasses in 94.72% of all distinct policies.
>> We base our Internet-wide analysis on a search engine cor-
>> pus of approximately 100 billion pages from over 1 billion
>> hostnames; the result covers CSP deployments on 1,680,867
>> hosts with 26,011 unique CSP policies { the most compre-
>> hensive  study  to  date.   We  introduce  the  security-relevant
>> aspects  of  the  CSP  speci cation  and  provide  an  in-depth
>> analysis  of  its  threat  model,  focusing  on  XSS  protections.
>> We identify three common classes of
>> CSP bypasses
>> and ex-
>> plain how they subvert the security of a policy.
>> We  then  turn  to  a  quantitative  analysis  of  policies  de-
>> ployed  on  the  Internet  in  order  to  understand  their  secu-
>> rity  bene ts.   We  observe  that  14  out  of  the  15  domains
>> most commonly whitelisted for loading scripts contain
>> un-
>> safe endpoints
>> ; as a consequence, 75.81% of distinct policies
>> use script whitelists that allow attackers to bypass CSP. In
>> total, we  nd that 94.68% of policies that attempt to limit
>> script  execution  are  ine ective,  and  that  99.34%  of  hosts
>> with CSP use policies that o er no bene t against XSS.
>> Finally,  we  propose  the
>> 'strict-dynamic'
>> keyword,  an
>> addition to the speci cation that facilitates the creation of
>> policies based on cryptographic nonces, without relying on
>> domain whitelists. We discuss our experience deploying such
>> a
>> nonce-based
>> policy in a complex application and provide
>> guidance to web authors for improving their policies.
>>
>>
>>
>> 6.  CONCLUSION
>> In this paper, we presented an assessment of the practical
>> security bene ts of adopting CSP in real-world applications,
>> based on a large-scale empirical study.
>> We performed an in-depth analysis of the security model
>> of CSP and identi ed several cases where seemingly safe poli-
>> cies provided no security improvement.  We investigated the
>> adoption of CSP on over 1 billion hostnames, and identi ed
>> 1.6 million hosts using 26,011 unique policies in the Google
>> search index.
>> Unfortunately,  the  majority  of  these  policies  are  inher-
>> ently insecure. Via automated checks, we were able to demon-
>> strate that 94.72 % of all policies can be trivially bypassed
>> by an attacker with a markup-injection bug.  Furthermore,
>> we analyzed the security properties of whitelists.  Thereby,
>> we found that 75.81 % of all policies and 41.65 % of all strict
>> policies contain at least one insecure host within their white-
>> lists.  These numbers lead us to the believe that whitelists
>> are impractical for use within CSP policies.
>> Hence,  we  proposed  a  new  way  of  writing  policies.   In-
>> stead  of  whitelisting  entire  hosts,  we  recommend  enabling
>> individual scripts via an approach based on CSP nonces.
>> In order to ease the adoption of
>> nonce-based
>> CSP, we fur-
>> thermore  proposed  the
>> 'strict-dynamic'
>> keyword.   Once
>> speci ed within a CSP policy, this keyword enables a mode
>> inside  the  browser  to  inherit  nonces  to  dynamic  scripts.
>> Hence, if a script trusted with a nonce creates a new script at
>> runtime, this new script will also be considered legitimate.
>> Although  this  technique  departs  from  the  traditional  host
>> whitelisting approach of CSP, we consider the usability im-
>> provements signi cant enough to justify its broad adoption.
>> Because this is designed to be an opt-in mechanism, it does
>> not reduce the protective capabilities of CSP by default.
>> We expect that that the combination of a nonce-based ap-
>> proach and the
>> 'strict-dynamic'
>> keyword will allow devel-
>> opers and organizations to  nally enjoy real security bene ts
>> o ered by the Content Security Policy.
>>
>>
>>
>> end
>>
>>
>>
>