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

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