Raccoon: Automated Verification of Guarded Race Conditions in Web Applications Simon Koch Tim Sauer Institute for Application Security (TU Braunschweig) Institute for Application Security (TU Braunschweig) Braunschweig, Germany Braunschweig, Germany [email protected] [email protected] Martin Johns Giancarlo Pellegrino Institute for Application Security (TU Braunschweig) CISPA Helmholtz Center for Information Security Braunschweig, Germany Saarbrücken, Germany [email protected] [email protected] Abstract 1 Introduction Web applications are distributed, asynchronous applications that The general intention of Web applications is to accommodate a can span multiple concurrent processes. They are intended to be potentially large number of concurrent requests. This requirement used by a large amount of users at the same time. As concurrent comes with a significant challenge: maintaining shared data con- applications, web applications have to account for race conditions sistently across all processes. Such data can range from mundane that may occur when database access happens concurrently. Unlike things such as the amount of visits over the last hour to business vulnerability classes, such as XSS or SQL Injection, dbms based critical information such as the remaining amount of a gift voucher. race condition flaws have received little attention even though To ensure consistency of data, e.g. ensure that a voucher is not their impact is potentially severe. In this paper, we present Rac- used for more money than it is worth, web application developers coon, an automated approach to detect and verify race condition deploy guards in form of conditional statements. Such a guard vulnerabilities in web application. Raccoon identifies potential ensures that an action, e.g. a value reduction, can only occur if the race conditions through interleaving execution of user traces while current state of the data allows for it. tightly monitoring the resulting database activity. Based on our However, interleavings of concurrent read and write operations methodology we create a proof of concept implementation. We can circumvent that guard and leave data in an inconsistent state. test four different web applications and ten use cases and discover These inconsistencies can be effectively exploited by attackers to six race conditions with security implications. Raccoon requires perform a wide range of attacks, e.g., double spending vouchers neither security expertise nor knowledge about implementation in Instacart1, and duplicate money transfers between gift cards in or database layout, while only reporting vulnerabilities, in which Starbucks2—to mention two past instances in popular websites. the tool was able to successfully replicate a practical attack. Thus, As opposed to popular web vulnerabilities such as XSS and SQL Raccoon complements previous approaches that did not verify injection, the detection of guarded race condition (GRC) vulnera- detected possible vulnerabilities. bilities in web applications has been marginally addressed. Prior work has mainly focused on the problem of reasoning on SQL logs CCS Concepts to detect potential vulnerabilities [1, 2]. • Security and privacy → Web application security; Infor- However, detection of potential GRC is not enough due to possi- mation accountability and usage control. ble protective web application logic and the underlying database Keywords structure that can prevent a detected potential GRC from manifest- ing. Neither the web application logic nor the complete database Race Conditions, Web Application Security Testing structure is entirely accounted for in current detection approaches ACM Reference Format: and thus a detected vulnerability is possibly not exploitable after Simon Koch, Tim Sauer, Martin Johns, and Giancarlo Pellegrino. 2020. Rac- all. A usable methodology has to minimize occurrences of detected coon: Automated Verification of Guarded Race Conditions in Web Appli- possible but actually not exploitable vulnerability candidates. The cations. In The 35th ACM/SIGAPP Symposium on Applied Computing (SAC current state-of-the-art in GRC detection leaves it to the tester to ’20), March 30-April 3, 2020, Brno, Czech Republic. ACM, New York, NY, USA, 10 pages. https://doi.org/10.1145/3341105.3373855 manually verify that the suspected vulnerability actually manifests itself in an exploitable vulnerability. Permission to make digital or hard copies of all or part of this work for personal or For well-explored vulnerability classes, such as XSS or SQL in- classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation jection, this process is manageable, as it is usually formulaic and on the first page. Copyrights for components of this work owned by others than the independent of the semantics of the application. In contrast, man- author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or ual verification of a GRC is notoriously difficult. It requires good republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. understanding of the web application’s execution model and how SAC ’20, March 30-April 3, 2020, Brno, Czech Republic race conditions affect it. While the developer of the application © 2020 Copyright held by the owner/author(s). Publication rights licensed to ACM. ACM ISBN 978-1-4503-6866-7/20/03...$15.00 1See https://hackerone.com/reports/157996 https://doi.org/10.1145/3341105.3373855 2See https://sakurity.com/blog/2015/05/21/starbucks.html SAC ’20, March 30-April 3, 2020, Brno, Czech Republic Simon Koch, Tim Sauer, Martin Johns, and Giancarlo Pellegrino most likely has the latter, they probably lack the required security in and between requests [1]. They verified their results by hand expertise. A security expert should know the specifics of GRCs but using either brute force or inserting a small network delay in the rarely knows the fine-grained details of the tested application’s communication between web application and database server. We functionality. extend their idea of delaying the communication by focusing the We now take a step forward and present a methodology that en- delay on only the queries of interest and using this for an automated ables developers and security experts alike to automatically detect testing tool. Additionally, Warszawski et al. reported an GRC for and verify GRCs in web applications. We follow up with implement- voucher usage in the eCommerce web application OpenCart and, ing this methodology as the novel race condition verification tool thus, provided a partial ground truth for the evaluation of Raccoon. Raccoon to show the practicality of the methodology. Zheng et al. developed a context- and path-sensitive interproced- To the best of our knowledge, Raccoon is the first tool providing ual static analysis to detect atomicity violations on shared external a comprehensive and automated approach concerning GRCs cov- resources in PHP and are able to infer potential GRCs [7]. They ering all the necessary steps from detection up to verification. We conducted their verification of detected vulnerabilities by hand. report on the effectiveness of Raccoon by assessing four real-size They report on a GRC in the coupon usage in OpenCart and, thus, web applications and ten use cases. We discover six GRCs with provided a partial ground truth for the evaluation of Raccoon. security implications using Raccoon. Paleari et al. were the first to report dbms based GRCs in web Our Contributions: applications a valid security concern in the scientific literature. In • We isolate and define the programmatically verifiable guarded their work they propose an algorithm based on SQL query traces race conditions (GRC) to detect GRCs. They introduce the notion of interdependence • We present the first comprehensive automated security test- between SQL queries as a way to detect possible GRCs and define ing methodology to detect and verify GRCs in web applica- an algorithm to detect interdependent SQL queries [2]. Finally, tions they manually verified their results. Their algorithm represents • We implement Raccoon, a prototype implementation of our the current GRCs candidate generation module of Raccoon. We, methodology3 thus, extend the approach of Paleari et al. by embedding it into an • We apply Raccoon against four real-size web applications automated verification facility. and discover six GRCs all of which have security implications The listed work is mainly concerned with a methodology for the detection of possible GRCs. They perform the remaining work, i.e., We introduce our methodology and results as followed: First data gathering, testing, and verification manually. Consequently, we discuss the related work (Sec. 2). We continue by going into our methodology that only requires a tester to provide user ac- the background details of GRC and state the challenges that we tions, a web application and allows plugging in arbitrary detection addressed (Sec. 3). We follow up by stating our general approach algorithms is a novel contribution to the field of race condition on solving the challenges (Sec. 4) and describe how we actually vulnerabilities in web applications. implemented it (Sec. 5). We then report on the application of our Dynamic Web Application Testing using User Traces implementation