Where We Stand (or Fall): An Analysis of CSRF Defenses in Web Frameworks Xhelal Likaj Soheil Khodayari Giancarlo Pellegrino Saarland University CISPA Helmholtz Center for CISPA Helmholtz Center for Saarbruecken, Germany Information Security Information Security [email protected] Saarbruecken, Germany Saarbruecken, Germany [email protected] [email protected] Abstract Keywords Cross-Site Request Forgery (CSRF) is among the oldest web vul- CSRF, Defenses, Web Frameworks nerabilities that, despite its popularity and severity, it is still an ACM Reference Format: understudied security problem. In this paper, we undertake one Xhelal Likaj, Soheil Khodayari, and Giancarlo Pellegrino. 2021. Where We of the first security evaluations of CSRF defense as implemented Stand (or Fall): An Analysis of CSRF Defenses in Web Frameworks. In by popular web frameworks, with the overarching goal to identify Proceedings of ACM Conference (Conference’17). ACM, New York, NY, USA, additional explanations to the occurrences of such an old vulner- 16 pages. https://doi.org/10.1145/nnnnnnn.nnnnnnn ability. Starting from a review of existing literature, we identify 16 CSRF defenses and 18 potential threats agains them. Then, we 1 Introduction evaluate the source code of the 44 most popular web frameworks Cross-Site Request Forgery (CSRF) is among the oldest web vul- across five languages (i.e., JavaScript, Python, Java, PHP, andC#) nerabilities, consistently ranked as one of the top ten threats to covering about 5.5 million LoCs, intending to determine the imple- web applications [88]. Successful CSRF exploitations could cause re- mented defenses and their exposure to the identified threats. We mote code execution [111], user accounts take-over [85, 87, 90, 122], also quantify the quality of web frameworks’ documentation, look- or compromise of database integrity—to name only a few in- ing for incomplete, misleading, or insufficient information required stances. Developers can protect web applications from CSRF at- by developers to use the implemented CSRF defenses correctly. tacks by implementing one of the many client-side and server- Our study uncovers a rather complex landscape, suggesting that side defense mechanisms proposed by the research community while implementations of CSRF defenses exist, their correct and (e.g., [99, 104, 112, 114, 124, 126, 133, 134]). Alternatively, develop- secure use depends on developers’ awareness and expertise about ers can use off-the-shelf CSRF defenses as implemented byweb CSRF attacks. More than a third of the frameworks require devel- frameworks, such as the ones provided by popular frameworks opers to write code to use the defense, modify the configuration like Django for Python, Spring for Java, and ASP.NET for C#. Web to enable CSRF defenses, or look for an external library as CSRF frameworks are key components for developing web applications, defenses are not built-in. Even when using defenses, developers providing convenient and powerful abstractions to separate low- need to be aware and address a diversity of additional security risks. level functionalities, e.g., databases and web page generation, from In total, we identified 157 security risks in 37 frameworks, of which the application’s logic. However, such a convenience comes at a 17 are directly exploitable to mount a CSRF attack, leveraging imple- great cost: a vulnerability in the framework will negatively affect mentation mistakes, cryptography-related flaws, cookie integrity, the security of many web applications. and leakage of CSRF tokens—including three critical vulnerabili- CSRF vulnerabilities are a major concern for web applica- ties in CakePHP, Vert.x-Web, and Play. The developers’ feedback tions, with a steep increasing number of reported instances ev- indicate that, for a significant fraction of risks, frameworks have ery year [58]. Yet, this class of vulnerabilities have received divergent expectations about who is responsible for addressing a marginal attention by the research community, where most them. Finally, the documentation analysis reveals several inadequa- of the previous effort focused largely on defense mechanisms cies, including not mentioning the implemented defense, and not (e.g., [99, 104, 112, 114, 124, 126, 133, 134]) and vulnerability de- showing code examples for correct use. tection (e.g., [101, 122, 129]. To date, we know none-to-little about CCS Concepts the security of the CSRF defense implementations and their suscep- tibility against improper use. ! • Security and privacy Web application security; In this paper, we undertake, to the best of our knowledge, the first security evaluation of CSRF defense as implemented by popular Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed web frameworks, comprehensively and systematically covering the for profit or commercial advantage and that copies bear this notice and the full citation source code, defenses’ design, documentation, and the operational on the first page. Copyrights for components of this work owned by others than ACM aspects, with the overarching goal to identify additional explana- must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a tions to the steady increase of such an old vulnerability. Starting fee. Request permissions from [email protected]. with a thorough review of academic and non-academic literature, Conference’17, July 2017, Washington, DC, USA we enumerate existing CSRF defenses and threats against them, © 2021 Association for Computing Machinery. ACM ISBN 978-x-xxxx-xxxx-x/YY/MM...$15.00 identifying 16 distinct defenses and 18 potential threats. Then, we https://doi.org/10.1145/nnnnnnn.nnnnnnn evaluate the source code of the 44 most popular web frameworks across the top five programming languages for web applications defenses—the most widely implemented defense—such as token (i.e., JavaScript, Python, Java, PHP, and C#) covering about 5.5 mil- generation, transportation, and validation. In general, while token- lion LoCs, intending to determine the implemented defenses and based defenses use robust generation algorithms (i.e., cryptographi- their exposure to the identified threats. Finally, we also quantify the cally secure pseudorandom number generators, cryptographic algo- quality of web frameworks’ documentation, looking for incomplete, rithms, and implementations), the randomness of tokens is sub-par. misleading, or insufficient information required by developers to Furthermore, if tokens leak, virtually all implemented defenses are implement and use the implemented CSRF defenses correctly. exposed to token replay attacks as they reuse tokens across multiple Insights—Our study uncovers a complex landscape, suggesting requests. Only one framework implements a per-request unique that while implementations of CSRF defenses exist, their correct and token, rendering replay hard in practice. Also, we identified and secure implementation depends on developers’ awareness about already reported three critical vulnerabilities in CakePHP, Vert.x- CSRF attacks, threats to CSRF defenses, and specific behaviors of Web, and Play, leading to a complete CSRF defense bypass. Finally, the implementations. both our security analyses and developers’ feedback reveal that, for a considerable fraction of security risks, frameworks’ developers Insight #1: Almost all frameworks offer a CSRF defense—either have divergent expectations from applications’ developers about built-in or via external libraries, with the majority enforcing a their responsibility for addressing the risks. token-based protection mechanism, one of the most robust CSRF defenses. For example, over 53% and 41% of the frameworks use Insight #4: Lastly, the documentation of most of the frameworks double submit cookies and synchronizer tokens to mitigate CSRF with a CSRF defense is inadequate. For example, the documentation attacks, respectively. Also, all frameworks (except Li3) use robust does not explain the implemented defense name or any kind of CPRNG for token generation. Even more promising, almost half description (16 out of 39 frameworks with a defense), does not show of the frameworks (i.e., 19) enforce a defense-in-depth mechanism the correct use via code examples (seven out of 39 frameworks), nor by applying two or more layers of defenses in sequence. For exam- adequately describe the API calls and the configuration space of the ple, we observe that ten frameworks enable SameSite cookies by CSRF defense (eight out of 39 frameworks). To make it even worse, default—a promising defense-in-depth mechanism which can miti- in the vast majority of the cases (27 out of 39 frameworks), the gate a number of CSRF attacks. Similarly, we observed that seven documentation does not discuss nor address the security implication frameworks give state to the double submit cookie that is stateless of the threats considered in this study, leaving entirely up to the in nature, making it immune to cookie tossing and jar overflow developers’ judgment the implementation of robust defenses. attacks. Finally, we noticed that frameworks offer defenses that can Contributions—To summarize, this paper makes the following protect web applications from attackers with stronger capabilities contributions: than web attackers. For example,