CSRF – An underestimated attack method

Cross Site Reference Forgery works by including malicious code or a link in a page that accesses a web application that the user is believed to have authenticated. If the session for that web application has not timed out, an attacker may execute unauthorized commands.

Most Rails applications use cookie-based sessions. Either they store the session id in the cookie and have a server-side session hash, or the entire session hash stays on the client-side. In either case the browser will automatically send along the cookie on every request to a domain, if he can find a cookie for that domain. The controversial point is, that it will also send the cookie, if the request comes from a site of a different domain. Let’s start with an example:


  • Bob browses a message board and views a post from an attacker where there is a crafted HTML image element. The element references a command in Bob’s banking application, rather than an image file (note that .src is meant to be src).

  • <img .src=”http://www.bank.com/transfer?account=bob&amount=1000&destination=attacker”>

  • Bob’s session at www.bank.com is still alive, because he didn’t log out a few minutes ago.

  • By viewing the post, the browser finds an image tag, which it tries to load from www.bank.com. As explained before, it will also send along the cookie with the valid session id.

  • The web application at www.bank.com verifies the user information in the corresponding session hash and transfers the money to the attackers account. It then returns a result page which is an unexpected result for the browser, so it will not display the image.

  • Bob doesn’t notice the attack, only a few days later he finds out about the strange transfer.

It is important to notice that the actual crafted image or link doesn’t necessarily has to be situated in the web application’s domain, it can be anywhere – in a forum, blog post or email.


See the figure at shiflett.org to see how CSRF works.


CSRF appears very rarely in CVE (Common Vulnerabilities and Exposures), less than 0.1% in 2006, but it really is a ‘sleeping giant’ [Grossman]. This is in stark contrast to the results in my (and others) security contract work – CSRF is an important security issue.



CSRF Countermeasures

First of all, GET and POST have to be used according to the W3C. Secondly, a security token in non-GET requests will protect your application from CSRF.

The HTTP protocol basically provides two main types of requests – GET and POST (and more, but they are not supported by most browsers). The World Wide Web Consortium (W3C) provides a checklist for choosing HTTP GET or POST:


Use GET if:

  • The interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup).

Use POST if:

  • The interaction is more like an order, or

  • The interaction changes the state of the resource in a way that the user would perceive (e.g., a subscription to a service), or

  • The user be held accountable for the results of the interaction.


The verify method in a controller can make sure that specific actions may not be used over GET. Here is an example to verify that the transfer action will be used over POST, otherwise it redirects to the list action.


verify :method => :post, :only => [ :transfer ], :redirect_to => { :action => :list }


With this precaution, the attack from above will not work, because the browser sends a GET request for images, which will not be accepted by the web application.

But this was only the first step, because POST requests can be send automatically, too. Here is an example for a link which displays harmless.com as destination in the browser’s status bar. In fact it dynamically creates a new form that sends a POST request (.href is meant to be href).


<a .href=”http://www.harmless.com/” onclick=”var f = document.createElement(‘form’); f.style.display = ‘none’; this.parentNode.appendChild
(f); f.method = ‘POST’; f.action = ‘http://www.example.com/account/destroy’; f.submit();return false;”>To the harmless survey</a>


Or the attacker places the code into the onmouseover event handler of an image (again, .src is meant to be src):


<img .src=”http://www.harmless.com/img” width=”400″ height=”400″ onmouseover=”…” />


There are many other possibilities, including Ajax to attack the victim in the background. The solution to this, is to include a security token in non-GET requests, which will be checked on the server-side. In Rails 2 this is a one-liner in the application controller:


protect_from_forgery :secret => “123456789012345678901234567890”


This will automatically include a security token, calculated of the current session and the server-side secret, in all forms and Ajax requests generated by Rails. You won’t need the secret, if you use CookieStorage as session storage. It will raise an ActionController::InvalidAuthenticityToken error, if the security doesn’t match what was expected.


Note that cross-site scripting (XSS) vulnerabilities bypass all CSRF protections. XSS gives the attacker access to all elements on a page, so he can read the CSRF security token from a form or directly submit the form.  This is how the Samy MySpace worm did it.