More Guidelines Than Rules: CSRF Vulnerabilities from Noncompliant OAuth 2.0 Implementations [chapter]

Ethan Shernan, Henry Carter, Dave Tian, Patrick Traynor, Kevin Butler
2015 Lecture Notes in Computer Science  
OAuth 2.0 provides an open framework for the authorization of users across the web. While the standard enumerates mandatory security protections for a variety of attacks, many embodiments of this standard allow these protections to be optionally implemented. In this paper, we analyze the extent to which one particularly dangerous vulnerability, Cross Site Request Forgery, exists in realworld deployments. We crawl the Alexa Top 10,000 domains, and conservatively identify that 25% of websites
more » ... g OAuth appear vulnerable to CSRF attacks. We then perform an in-depth analysis of four high-profile case studies, which reveal not only weaknesses in sample code provided in SDKs, but also inconsistent implementation of protections among services provided by the same company. From these data points, we argue that protection against known and sometimes subtle security vulnerabilities can not simply be thrust upon developers as an option, but instead must be strongly enforced by Identity Providers before allowing web applications to connect. In this paper, we consider the extent to which a specific documented vulnerability is embodied in real-world implementations. Specifically, the OAuth 2.0 standard explicitly identifies the potential for Cross Site Request Forgery (CSRF) attacks, which may force an unsuspecting user to perform an "authorized" action without their knowledge (e.g., transmit financial information to a malicious third-party, modify sensitive file contents, etc). The OAuth 2.0 standard is absolutely unambiguous about the danger that such vulnerabilities pose, and notes that both client and server "MUST implement CSRF protection" [18] . Unfortunately, these specific warnings are not heeded by many deployments of this protocol, leaving the implementation of protections as either a suggested task or simply an unmentioned burden for web application developers. As our experiments demonstrate, this lack of strict adherence to the standard leaves a significant portion of OAuth-enabled web applications vulnerable to CSRF attacks. We make the following contributions: -Analysis of Adherence to Standard: We evaluate 13 of the most popular OAuth 2.0 Identity Providers, including Facebook, Google, and Microsoft. We show that only four out of thirteen such providers force CSRF protections as part of their APIs, leaving the remaining nine to merely suggest or simply not mention that protection is necessary. -Measurement Study: We develop a crawler and perform a depth-two analysis of the Alexa Top 10,000 websites [1], visiting more than 5.6 million URLs during our evaluation. Of those we detect as offering OAuth 2.0 services, we show that 25% do not implement standard CSRF protections and appear vulnerable to attack. -Analysis of Case Studies: We provide deeper analysis into four different specific instances in which vulnerable uses of OAuth 2.0 APIs are identified. We show that mistakes are the result of a range of factors, ranging from vulnerable sample code published by Identity Providers to inconsistencies between APIs across a large company. These contributing factors all point to Identity Providers as the logical agents to effect change by mandating compliant implementations. From these observations, we argue that expecting web application developers to understand and implement subtle web security protection mechanisms is a design choice doomed to failure. Specifically, when a known vulnerability identified in the standard can be fixed with a known remediation technique that does not impact performance, it must be a mandatory component of any embodiment of that standard. The remainder of this paper is organized as follows: Section 2 provides background information on the OAuth 2.0 protocol, and discusses CSRF attacks; Section 3 applies CSRF to OAuth, and demonstrates how the use of a challenge-response string can prevent such attacks; Section 4 offers the results of our web crawl; Section 5 details four case studies; Section 6 provides further insights and discussion; Section 7 examines related work; and Section 8 provides concluding remarks. Background At its core, the OAuth protocol allows a user to grant a web application authorized access to his data on a different application [28] . Specifically, it allows a user to grant a Relying Party (RP) the ability to perform a set of operations on an account with an
doi:10.1007/978-3-319-20550-2_13 fatcat:m2ttpocmizdpzji4bl2fk7elfu