People's Newsroom

PROTECTING USERS AGAINST CROSS-SITE REQUEST FORGERY

CsFire prevents cross-origin requests from violating the session integrity, by using an in-browser request filtering algorithm to distinguish between expected and unexpected cross-origin requests. By means of a bounded-scope model checking tool, we verified the effectiveness of our algorithm against the threat model of a CSRF attack, also known as the Web attacker. Based on the research prototype from both papers, we continued development on CsFire, and released it as a freely available browser add-on, initially for Mozilla Firefox, and later for Google Chrome as well. CsFire attracted the attention of security and privacy-aware Web users, causing the user base to grow organically to about 2,500 to 3,000 daily users at the time of this writing. In August 2010, CsFire was even featured as one of the security tools on the software DVD of the German computer magazine CHIP. CsFire has also inspired further research on the integrity of Web sessions. It is extended that the request filtering algorithm with a lightweight version of the Cross-Origin Resource Sharing (CORS) policy, resulting in a final decision whether to allow authentication data or not. Web performance proposes a provably sound mechanism to protect session integrity, which is implemented in their browser add-on SessInt. The authors acknowledge the problem of false positives and refer to CsFire’s policies as a potential solution for a more fine-grained approach. Finally, a recent standardization proposal introduces Entry Point Regulation for Web Apps, which is a browser-enforced policy that restricts cross-origin requests to a pre-defined list of entry points. This approach is comparable to CsFire’s configurable policies, where an application’s entry points can be marked as Allowed, and other requests as Blocked.

In hindsight, we can conclude that CsFire pushes the balance between usability and security to its limits, by deploying a sophisticated detection policy, while offering strong protection against CSRF attacks, as illustrated by the thousands of daily users. In the 4 years since CsFire’s release, we have noticed that the dynamics of the Web have become even more interconnected and tightly integrated, which CsFire can address with the server-driven policy rules. However, as this trend is likely to continue in the coming years, it may be useful to investigate a new security model, which goes beyond the commonly-used origins. By dividing the user’s sites into different zones, for example, a low-security zone and a sensitive information zone, CsFire can prevent unexpected interactions between these zones, while allowing sites within the same zone to freely interact with each other. Such an approach also applies to corporate scenarios, where browsers are used to visit sites in a public internet zone and a private intranet zone, and where unexpected interactions between both are undesired.

AUTOMATIC AND PRECISE CLIENT-SIDE PROTECTION AGAINST CSRF ATTACKS

A common client-side countermeasure against Cross-Site Request Forgery (CSRF) is to strip session and authentication information from malicious requests. The difficulty however is in determining when a request is malicious. Existing client-side countermeasures are typically too strict, thus breaking many existing Websites that rely on authenticated cross-origin requests, such as sites that use third-party payment or single sign-on solutions. From a security perspective, Web browsers are a key component of today’s software infrastructure. A browser user might have a session with a trusted site A (e.g. a bank, or a Webmail provider) open in one tab, and a session with a potentially dangerous site B (e.g. a site offering cracks for games) open in another tab. Hence, the browser enforces some form of isolation between these two origins A and B through a heterogeneous collection of security controls collectively known as the same-origin policy. An origin is a (protocol, domain name, port) triple, and restrictions are imposed on the way in which code and data from different origins can interact. This includes for instance restrictions that prevent scripts from origin B to access content from origin A. An important known vulnerability in this isolation is the fact that content from origin B can initiate requests to origin A, and that the browser will treat these requests as being part of the ongoing session with A. In particular, if the session with A was authenticated, the injected requests will appear to A as part of this authenticated session. This enables an attack known as Cross-Site Request Forgery (CSRF): B can initiate effect requests to A (e.g. a bank transaction, or manipulations of the victim’s mailbox or address book) without the user being involved.

CSRF has been recognized for several years as one of the most important Web vulnerabilities, and many countermeasures have been proposed. Several authors have proposed server-side countermeasures. However, an important disadvantage of server-side countermeasures is that they require modifications of server-side programs, have a direct operational impact (e.g. on performance or maintenance), and it will take many years before a substantial fraction of the Web has been updated. Alternatively, countermeasures can be applied on the client-side, as browser add-ons. The basic idea is simple: the browser can strip session and authentication information from malicious requests, or it can block such requests. The difficulty however is in determining when a request is malicious. Existing client-side countermeasures are typically too strict: they block or strip all cross-origin requests of a specific type (e.g. GET, POST, any). This effectively protects against CSRF attacks, but it unfortunately also breaks many existing Websites that rely on authenticated cross-origin requests. Two important examples are sites that use third-party payment (such as PayPal) or single sign-on solutions (such as OpenID). Hence, these existing client-side countermeasures require extensive help from the user, for instance by asking the user to define white-lists of trusted sites or by popping up user confirmation dialogs. This is suboptimal, as it is well-known that the average Web user cannot be expected to make accurate security decisions.

It is automatic in the sense that no user interaction or configuration is required. It is precise in the sense that it distinguishes well between malicious and nonmalicious requests. More specifically, through a systematic analysis of logs of Web traffic, we identify a characteristic of non-malicious cross-origin requests that we call the trusted-delegation assumption: a request from B to A can be considered non-malicious if, earlier in the session, A explicitly delegated control to B in some specific ways. Our filtering algorithm relies on this assumption: it will strip session and authentication information from cross-origin requests unless it can determine that such explicit delegation has happened.

First, formalize the algorithm and the trusted-delegation assumption in Alloy, building on the formal model of the Web proposed by, and we show through bounded-scope model checking that our algorithm protects against CSRF attacks under this assumption. Next, we provide experimental evidence that this assumption is realistic: through a detailed analysis of logs of Web traffic, we quantify how often the trusted-delegation assumption holds, and show that the remaining attack surface for CSRF attacks is very small. Finally, we have implemented our filtering algorithm as an extension of an existing client-side CSRF protection mechanism, and we show that our filtering does not break typical non-malicious cross-origin collaboration scenarios such as payment and single sign-on. In summary, the contributions of this chapter are:

  • The design of a novel client-side CSRF protection mechanism based on request filtering.
  • A formalization of the algorithm, and formal evidence of the security of the algorithm under one specific assumption, the trusted-delegation assumption.
  • An implementation of the countermeasure, and a validation of its compatibility with important Web scenarios broken by other state-ofthe-art countermeasures.
  • An experimental evaluation of the validity of the trusted-delegation assumption.
Back to top button