A Server- and Browser-Transparent CSRF Defense for Web 2.0 Applications∗
Total Page：16
File Type：pdf, Size：1020Kb
A Server- and Browser-Transparent CSRF Defense for Web 2.0 Applications∗ Riccardo Pelizzi and R. Sekar Stony Brook University ABSTRACT ies for another site (say, bank.com). However, browsers en- Cross-Site Request Forgery (CSRF) vulnerabilities consti- force no restrictions on outgoing requests: if a user visits an tute one of the most serious web application vulnerabilities, evil.com web page, possibly because of an enticing email ranking fourth in the CWE/SANS Top 25 Most Danger- (see Figure1), a script on this page can send a request to ous Software Errors. By exploiting this vulnerability, an at- bank.com. Moreover, the user's browser will automatically tacker can submit requests to a web application using a vic- include bank.com's cookies with this request, thus enabling tim user's credentials. A successful attack can lead to com- Cross-site Request Forgery (CSRF). A CSRF attack thus promised accounts, stolen bank funds or information leaks. enables one site to \forge" a user's request to another site. This paper presents a new server-side defense against CSRF Using this attack, evil.com may be able to transfer money attacks. Our solution, called jCSRF, operates as a server- from the user's account to the attacker's account [26]. Al- side proxy, and does not require any server or browser mo- ternatively, evil.com may be able to reconfigure a firewall difications. Thus, it can be deployed by a site administrator protecting a home or local area network, allowing it to con- without requiring access to web application source code, or nect to vulnerable services on this network [2,3,6]. the need to understand it. Moreover, protection is achieved Since CSRF attacks involve cross-domain requests, a web without requiring web-site users to make use of a specific application can thwart them by ensuring that every sensitive browser or a browser plug-in. Unlike previous server-side request originates from its own pages. One easy way to solutions, jCSRF addresses two key aspects of Web 2.0: ex- do this is to rely on the Referrer header of an incoming tensive use of client-side scripts that can create requests to HTTP request. This information is supplied by a browser URLs that do not appear in the HTML page returned to the and cannot be changed by scripts, and can thus provide a client; and services provided by two or more collaborating basis for verifying the domain of the page that originated a web sites that need to make cross-domain requests. request. Unfortunately, referrer header is often suppressed by browsers, client-side proxies or network equipment due to privacy concerns [1]. An alternative to the Referrer header, 1. INTRODUCTION called Origin header [1], has been proposed to mitigate these The stateless nature of HTTP necessitates mechanisms privacy concerns, but this header is not supported by most for maintaining authentication credentials across multiple browsers. As a result, it becomes the responsibility of a web HTTP requests. Most web applications rely on cookies for application developer to implement mechanisms to verify the this purpose: on a successful login, a web application sets a originating web page of a request. cookie that serves as the authentication credential for future A common technique for identifying a same-origin request requests from the user's browser. As long as this login ses- is to associate a nonce with each web page, and ensuring sion is active, the user is no longer required to authenticate that all requests from this page will supply this nonce as herself; instead, the user's browser automatically sends this one of the parameters. Since the SOP prevents attackers cookie (and all other cookies set by the same server) with from reading the content of pages from other domains, they every request to the same web server. are unable to obtain the nonce value and include it in a re- The same origin policy (SOP), enforced by browsers, en- quest, thus providing a way to filter them out. Many web sures confidentiality of cookies: in particular, it prevents application frameworks further simplify the incorporation of one web site (say, evil.com) from reading or writing cook- this technique [25,9, 14]. Nevertheless, it is ultimately the ∗This work was supported in part by ONR grant N000140710928, responsibility of a web application developer to incorporate NSF grant CNS-0831298, and AFOSR grant FA9550-09-1-0539. these mechanisms. Unfortunately, some web application de- velopers are not aware of CSRF threats and may not use these CSRF prevention techniques. Even when the develo- per is aware of CSRF, such a manual process is prone to Permission to make digital or hard copies of all or part of this work for programmer errors | a programmer may forget to include personal or classroom use is granted without fee provided that copies are the checks for one of the pages, or may omit it because of a not made or distributed for profit or commercial advantage and that copies mistaken belief that a particular request is not vulnerable. bear this notice and the full citation on the first page. To copy otherwise, to As a result, CSRF vulnerabilities are one of the most com- republish, to post on servers or to redistribute to lists, requires prior specific monly reported web application vulnerabilities, and is listed permission and/or a fee. ACSAC ’11 Dec. 5-9, 2011, Orlando, Florida USA as the fourth most important software vulnerability in the Copyright 2011 ACM 978-1-4503-0672-0/11/12 ...$10.00. Malicious Bank Bank Attacker Victim Browser Server Server Database Please visit evil.com Click on link GET evil.com Send response $(‘invisible form’).submit() POST bank.com – data + cookies Valid session ID Transfer money Figure 1: Illustration of a CSRF attack CWE Top 25 list [7]. are aimed at identifying same-origin requests. How- Prompted by the prevalence of CSRF vulnerabilities and ever, there are many instances where one domain may their potential impact, researchers have developed techniques trust another, and want to permit cross-origin requests to retrofit CSRF protection into existing applications. No- from that domain. Such cross-origin requests are not Forge [17] implements CSRF protection using the same basic supported by existing server-side solutions, and there nonce-based approach outlined earlier. On the server-side, does not seem to be any natural way to extend them to it intercepts every page sent to a client, and rewrites URLs achieve this. found on the page (including hyperlinks and form destina- We therefore present a new approach for CSRF defense tions) so that they supply the nonce when requested. Reque- that does not suffer from any of the above drawbacks. Our stRodeo [16] is conceptually similar but is deployed on the solution, called jCSRF, is implemented in the form of a client-side rather than the server side. Unfortunately, since server-side proxy. Note that on web servers such as Apache these techniques rely on static rewriting of link names, they that support a plug-in architecture, jCSRF can be imple- don't work well with Web 2.0 applications that construct mented as a web server module, thus avoiding the drawbacks web pages dynamically on the browser. More generally, ex- associated with proxies such as additional performance over- isting CSRF defenses suffer from one or more of the following heads and HTTPS compatibility. drawbacks: jCSRF operates by interposing transparently on the com- 1. Need for programmer effort and/or server-side modifica- munication between clients and servers, modifying them as tions. Many existing defenses are designed to be used by needed to protect against CSRF attacks. As a server-side programmers during the software development phase. In proxy, it avoids any need for server-side changes. jCSRF addition to requiring programmer effort, they are often also avoids client-side changes by implementing client-side specific to a development language or server environ- processing using a script that it injects into outgoing pages. ment. More importantly, they cannot be deployed by a It can protect requests for resources that are already present site administrator or operator that doesn't have access in the web page served to a client, as well as requests that are to application source code, or the resources to undertake dynamically constructed subsequently within the browser by code modifications. scripts. Finally, it incorporates a new protocol that enables support of legitimate cross-domain requests. 2. Incompatibility with existing browsers. Some techniques jCSRF protects all POST requests automatically, without require browser modifications to provide additional in- any programmer effort, but as we describe later, it is diffi- formation (e.g., the referrer or origin [1] header), while cult (for our technique and those of others) to protect against others rely on browsers enforcement of policies on cross- GET-based CSRF without some programmer effort. More- origin requests (e.g., NoScript [19], CsFire [8], SOMA over, GET-requests are supposed to be free of side-effects as [20], RequestRodeo [16]). These approaches thus leave per RFC2616 [11], in which case they won't be vulnerable to server administrators at the mercy of browser vendors CSRF. For these reasons, jCSRF currently does not protect and users, who may or may not be willing to adopt these against GET-based CSRF. browser modifications. 3. Inability to protect dynamically generated requests. Ex- 2. APPROACH OVERVIEW isting server-side defenses, including NoForge [17], As described before, the essence of CSRF is a request to a CSRFMagic [25], and CSRFGuard [23], do not work web server that originates from an unauthorized page.