Csfire: Transparent Client-Side Mitigation of Malicious Cross-Domain Requests
Total Page:16
File Type:pdf, Size:1020Kb
CsFire: Transparent client-side mitigation of malicious cross-domain requests Philippe De Ryck, Lieven Desmet, Thomas Heyman, Frank Piessens, and Wouter Joosen IBBT-DistriNet Katholieke Universiteit Leuven 3001 Leuven, Belgium fphilippe.deryck,[email protected] Abstract Protecting users in the ubiquitous online world is becoming more and more important, as shown by web application security { or the lack thereof { making the mainstream news. One of the more harmful attacks is cross-site request forgery (CSRF), which allows an attacker to make requests to certain web applications while impersonating the user without their awareness. Existing client-side protection mechanisms do not fully mitigate the problem or have a degrading effect on the browsing experience of the user, especially with web 2.0 techniques such as AJAX, mashups and single sign-on. To fill this gap, this paper makes three con- tributions: first, a thorough traffic analysis on real-world traffic quanti- fies the amount of cross-domain traffic and identifies its specific proper- ties. Second, a client-side enforcement policy has been constructed and a Firefox extension, named CsFire (CeaseFire), has been implemented to autonomously mitigate CSRF attacks as precise as possible. Evalu- ation was done using specific CSRF scenarios, as well as in real-life by a group of test users. Third, the granularity of the client-side policy is improved even further by incorporating server-specific policy refinements about intended cross-domain traffic. 1 Introduction Cross-Site Request Forgery (CSRF) is a web application attack vector that can be leveraged by an attacker to force an unwitting user's browser to perform actions on a third party website, possibly reusing all cached authentication cre- dentials of that user. In 2007, CSRF was listed as one of the most serious web application vulnerability in the OWASP Top Ten [15]. In 2008, Zeller and Felten documented a number of serious CSRF vulnerabilities in high-profile websites, among which was a vulnerability on the home banking website of ING Direct [23]. One of the root causes of CSRF is the abuse of cached credentials in cross- domain requests. A website can easily trigger new requests to web applications in a different trust domain without any user intervention. This results in the browser sending out cross-domain requests, while implicitly using credentials cached in the browser (such as cookies, SSL certificates or login/password pairs). From a server point of view, these implicitly authenticated requests are legitimate and are requested on behalf of the user. The user, however, is not aware that he sent out those requests, nor that he approved them. Currently, a whole range of techniques exist to mitigate CSRF, either by pro- tecting the server application or by protecting the end-user (e.g. via a browser extension or a client-side proxy). Unfortunately, the server-side protection mech- anisms are not yet widely adopted. On the other side, most of the client-side solutions provide only limited protection or can not deal with complex web 2.0 applications, which use techniques such as AJAX, mashups or single sign-on (SSO). As a result, even the most cautious web user is unable to appropri- ately protect himself against CSRF, without compromising heavily on usability. Therefore, it is necessary to construct more robust client-side protection tech- niques against CSRF, capable of dealing with current and next-generation web applications. This paper presents the following contributions. First, it describes the results of an extensive, real-world traffic analysis. This analysis shows how many of the requests a browser makes are cross-domain and what their properties are. Second, we define CsFire, an autonomous client-side protection policy, which is independent of user-input or server-provided information. This policy will determine which cross-domain traffic is considered harmful and will propose an appropriate action, such as blocking the request or removing the implicit authentication credentials from the request. The paper also discusses how this policy can be enforced within the Firefox browser. Finally, this autonomous policy can be extended by server-specific refinements, to achieve a more flexible and fine-grained enforcement. This research builds upon previous work [13]. The main achievements with respect to the previous preliminary results are (1) a much finer-grained pol- icy allowing a secure-by-default solution without service degradation, and (2) a thorough evaluation of the proposed prototype. The remainder of this paper is structured as follows. Section 2 provides some background information on CSRF, explores the current state-of-the-art and de- fines the requirements of client-side mitigation solutions. Next, the detailed traf- fic analysis results are presented, along with the autonomous client policy, in Section 3. Section 4 describes the client-side solution in great detail. The re- finements with server-specific policies and its implementation are discussed in Section 5. Our solution is evaluated extensively by means of test scenarios, along with a group of test users. The evaluation results can be found in Section 6. In Section 7, the presented work is related to alternative mitigation techniques and, finally, Section 8 summarizes the contributions of this paper. 2 Background This section provides some background information on CSRF and available countermeasures. We will also define the requirements for client-side mitigation against CSRF. 2.1 Cross-Site Request Forgery (CSRF) HTTP is a stateless client-server protocol [5], which uses certain methods to transfer data between web servers and browsers. The two most frequently used HTTP methods are GET and POST. Conforming to the HTTP specification, GET methods are used to fetch data from the server, whereas POST methods are used to update server state. In practice however, GET and POST methods are used interchangeably, and both can trigger server-side state changes. Because of the stateless nature of HTTP, session management is built on top of HTTP. This is typically done by means of cookies, which are small amounts of session-specific data, created by the server application and stored in the browser. Alternative approaches such as URL rewriting or hidden form parameters exist as well [17]. This session-specific data is sent back with each request to that particular web application, without any user intervention. Similarly, HTTP basic authentication attaches encoded credentials to each individual request to enable server-side authentication and authorization. For user convenience, the credentials are typically cached within the browser, and are only requested once for the lifespan of the browser session. Other (albeit lesser used) authentication schemes include client side SSL and IP-based access control [9], of which the latter is mainly used on intranets. This paper will focus on the first two authentication mechanisms. To perform a successful CSRF attack, a number of conditions need to be met: 1. The target website must use implicit authentication, such as through cookies or HTTP authentication, as mentioned above. 2. The targeted user must already have been authenticated to the target web application, and the user's browser must have cached the authentication credentials. 3. An attacker forces the user's browser to make an HTTP request to the target web application. When all three conditions are met, the browser will automatically add the im- plicit authentication, making the request appear as a legitimate one to the target server. In general, CSRF attacks happen cross-domain, where an attacker tricks the user into connecting to another site. Strictly speaking, CSRF can also occur within the same domain, e.g. due to a script injection vulnerability or when multiple users can host a web site within the same domain (universities, ISP's, . ). The focus of this paper lies on the cross-domain CSRF attacks. 2.2 Existing countermeasures A number of CSRF protection techniques exist, by either protecting the server application or by protecting the end-user. This section briefly discusses both. Client-side countermeasures The most widespread countermeasure is the Same Origin Policy (SOP) [22], implemented in most browsers. This policy limits ac- cess to DOM properties and methods to scripts from the same `origin', where origin is usually defined as the triple <domain name, protocol, tcp port>1. This prevents a malicious script on the website evil.com from reading out session identifiers stored in a cookie from homebanking.com, for example. Unfortunately, the protection offered by the SOP is insufficient. Although the SOP prevents the requesting script from accessing the cookies or DOM properties of a page from another origin, it does not prevent an attacker from making requests to other origins. The attacker can still trigger new requests and use cached credentials, even though the SOP prevents the attacker from processing responses sent back from the server. On top of SOP, client-side countermeasures exist to monitor and filter cross- domain requests. They typically operate as a client-side proxy [9] or as an exten- sion in the browser [18,23]. These countermeasures monitor outgoing requests and incoming responses, and filter out implicit authentication or block cross- domain requests. Unfortunately, these client-side mitigation techniques suffer from various problems, as will be discussed in Section 7. Server-side countermeasures A number of server-side mitigation techniques ex- ists as well, of which the most popular class is the use of secret tokens [4,10,16]. Each response from the server embeds a secret token into the web page (e.g. a hidden parameter in an HTML form). For each incoming request, the server ver- ifies that the received token originated from the server, and is correctly bound to the user's session. Since the SOP prevents the attacker from reading responses from other origins, this is an effective server-side countermeasure.