We have implemented our request filtering algorithm in a proof-of-concept add-on for the Firefox browser and used this implementation to conduct an extensive practical evaluation. First, we have created simulations for both the common attack scenarios as well as for the two functional scenarios  (third party payment and centralized authentication) and verified that they behaved as expected. Second, in addition to these simulated scenarios, we have verified that the prototype supports actual instances of these scenarios, such as for example the use of MyOpenID authentication on sourceforge.net. Third, we have constructed and performed a CSRF benchmark, consisting of 70 CSRF attack scenarios to evaluate the effectiveness of our CSRF prevention technique. These scenarios are the result of a CSRF-specific study of the HTTP protocol, the HTML specification, and the CSS markup language to examine their cross-origin traffic capabilities, and include complex redirect scenarios as well. Our implementation has been evaluated against each of these scenarios, and our prototype passed all tests successfully.



Our countermeasure drastically reduces the attack surface for CSRF attacks. Without CSRF countermeasures in place, an origin can be attacked by any other origin on the Web. With our countermeasure, an origin can only be attacked by another origin to which it has delegated control explicitly by means of a cross-origin POST or redirects. It is difficult for an attacker to cause unintended delegations.

Third-party service mashups. This category consists of various third-party services that can be integrated in other Websites. Except for the single sign-on services, this is typically done by script inclusion, after which the included script can launch a sequence of cross-origin GET and/or POST requests towards offered AJAX APIs. In addition, the service providers themselves often use cross-origin redirects for further delegation towards content delivery networks. As a consequence, the origin A including the third-party service S becomes vulnerable to CSRF attacks from S. This attack surface is unimportant, as, in these scenarios, S can already attack A through script inclusion, a more powerful attack than CSRF.

In addition, advertisement service providers P that further redirects to content delivery services D are vulnerable to CSRF attacks from D whenever a user clicks an advertisement. Again, this attack surface is unimportant: the delegation from P to D correctly reflects a level of trust that P has in D, and P and D will typically have a legal contract or SLA in place.

Multi-origin Websites. Quite a number of larger companies and organizations have Websites spanning multiple origins (such as live.com – microsoft.com and google.be – google.com). Cross-origin POST requests and redirects between these origins make it possible for such origins to attack each other. For instance, google.be could attack google.com. Again, this attack surface is unimportant, as all origins of such a multi-origin Website belong to a single organization.

Content aggregators. Content aggregators collect searchable content and redirect end-users towards a specific content provider. For news feeds and document repositories (such as the ACM digital library), the set of content providers is typically stable and trusted by the content aggregator, and therefore again a negligible attack vector. Redirecting search engines register the fact that a Web user is following a link, before redirecting the Web user to the landing page (e.g. as Google does for logged-in users). Since the entries in the search repository come from all over the Web, our CSRF countermeasure provides little protection for such search engines. Our analysis identified 4 such origins in the data set: google.be, google.com, comicrank.com, and ohnorobot.com.

False positives. Some fraction of the cross-origin requests is caused by network access gateways (e.g. on public Wifi) that intercept and reroute requests towards a payment gateway. Since such devices have man-in-the-middle capabilities, and hence more attack power than CSRF attacks, the resulting attack surface is again negligible.

URL shorteners. To ease URL sharing, URL shorteners transform a shortened URL into a preconfigured URL via a redirect. Since such URL shortening services are open, an attacker can easily control a new redirect target. The effect is similar to the redirecting search engines; URL shorteners are essentially left unprotected by our countermeasure. Our analysis identified 6 such services in the data set: bit.ly, gravatar.com, post.ly, tiny.cc, tinyurl.com, and twitpic.com.

Others (unclassified). For some of the requests in our data set, the origins involved in the request were no longer online, or the (partially anonymized) data did not contain sufficient information to reconstruct what was happening, and we were unable to classify or further investigate these requests.  Experimental analysis shows that the trusted delegation assumption is realistic. Only 10 out of 23.592 origins (i.e. 0.0042% of the examined origins) – the redirecting search engines and the URL shorteners – perform delegations to arbitrary other origins. They are left unprotected by our countermeasure. But the overwhelming majority of origins delegates (in our precise technical sense, i.e. using cross-origin POST or redirect) only to other origins with whom they have a trust relationship.

The most straightforward protection technique against CSRF attacks is serverside mitigation via validation tokens. In this approach, Web forms are augmented with a server-generated, unique validation token (e.g. embedded as a hidden field in the form), and at form submission, the server checks the validity of the token before executing the requested action. At the client-side, validation tokens are protected from cross-origin attackers by the same-origin policy, distinguishing them from session cookies or authentication credentials that are automatically attached to any outgoing request. Such a token-based approach can be offered as part of the Web application framework, as a server-side library or filter, or as a server-side proxy. Recently, the Origin header has been proposed as a new server-side countermeasure.

With the Origin header, clients unambiguously inform the server about the origin of the request (or the absence of it) in a more privacy-friendly way than the Referer header. Based on this origin information, the server can safely decide whether or not to accept the request. In follow-up work, the Origin header has been improved, after a formal evaluation revealed a previously unknown vulnerability.  Unfortunately, the adoption rate of these server-side protection mechanisms is slow, giving momentum to client-side mitigation techniques as important (but hopefully transitional) solutions. In the next paragraphs, we will discuss the client-side proxy RequestRodeo, as well as four mature and popular browser addons (CsFire, NoScript ABE, RequestPolicy, and CSD4).

RequestRodeo is a client-side proxy. The proxy applies a client-side token-based approach to tie requests to the correct source origin. In case a valid token is lacking for an outgoing request, the request is considered suspicious and gets stripped of cookies and HTTP authorization headers. RequestRodeo lies at the basis of most of the clientside CSRF solutions, but because of the choice of a proxy, RequestRodeo often lacks context information, and the rewriting technique on raw responses does not scale well in a Web 2.0 world. CsFire extended the work and strips cookies and HTTP authorization headers from a cross-origin request. The advantage of stripping is that there are no side effects for cross-origin requests that do not require credentials in the first place. CsFire operates autonomously by using a default client policy which is extended by centrally distributed policy rules. Additionally, CsFire supports users in creating custom policy rules, which can be used to blacklist or whitelist certain traffic patterns. Without a central or user-supplied whitelist, CsFire does not support the payment and central authentication scenario.

NoScript ABE, or Application Boundary Enforcer, restricts an application within its origin, which effectively strips credentials from cross-origin requests unless specified otherwise. The default ABE policy only prevents CSRF attacks from the internet to an intranet page. The user can add specific policies, such as a CsFire-alike stripping policy, or a site-specific blacklist or whitelist. If configured with, ABE successfully blocks the three attack scenarios but disables the payment and central authentication scenario. RequestPolicy protects against CSRF by blocking all cross-origin requests.

In contrast to stripping credentials, blocking a request can have a very noticeable effect on the user experience. When detecting a cross-origin redirect, RequestPolicy injects an intermediate page where the user can explicitly allow the redirect. RequestPolicy also includes a predefined whitelist of hosts that are allowed to send cross-origin requests to each other. Users can add exceptions to the policy using a whitelist. RequestPolicy successfully blocks the three attack scenarios (by blocking instead of stripping all cross-origin requests) and requires interactive end-user feedback to enable the payment and central authentication scenario.

In addition, the expected content type of the response is taken into account to detect false negatives during execution. Although the visibility check closely approximates the end-user intent, their technique fails to support the script inclusions of third-party service mashups. Moreover, without taking into account the delegation requests, expected redirect requests will be falsely detected as CSRF attacks, although these requests are crucial enablers for the payment and central authentication scenario.


The divine scriptures are God’s beacons to the world. Surely God offered His trust to the heavens and the earth, and the hills, but they shrank from bearing it and were afraid of it. And man undertook it.
Back to top button