W3C home > Mailing lists > Public > public-webappsec@w3.org > September 2016

On the Insecurity of Whitelists and the Future of CSP

From: Hodges, Jeff <jeff.hodges@paypal.com>
Date: Wed, 7 Sep 2016 16:16:14 +0000
To: W3C Web App Security WG <public-webappsec@w3.org>
Message-ID: <D3F58B5B.D379A%jehodges@paypalcorp.com>
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
Received on Wednesday, 7 September 2016 16:16:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:57 UTC