Introduction to Cross Site Request Forgery (CSRF)

Cross Site Request Forgeries are a relatively common problem in web applications. Especially applications that involve Javascript/Ajax are more likely to be vulnerable to CSRF vulnerabilities.

What is Cross Site Request Forgery - CSRF

When you take an action online - submitting a blog post, delete a photo, registering on a site, transferring money in a bank account - you are making a request to a site to perform that action for you. Several things happen automatically when you make a request to a site: lots of data is sent using either a "POST" or "GET" method of the HTTP protocol and your browser sends along any cookies you have for the site. The cookies contain your session identification for the site which is how the site knows who you are and what permissions you have.

A CSRF occurs when a malicious user can trick you into making a specific kind of request to a site that you did not really intend to make AND when the site performs that action without confirming your intent. A simple example follows:

  1. Your site has a list of accounts and presents links to delete accounts. That link points to a URL like which contains the account identifier for the account to be deleted (2 in this example)
  2. A malicous attacker determines that you are an admin on the site and becomes your "friend" on a social networking site like twitter. They post a message to twitter @your_attention with a TinyURL that redirects to
  3. By the time you realize where the redirect is going, you've already deleted account #2. Depending on the system that may also delete all of the content associated with account #2.

Major bummer.

The solution to this problem is a secret value associated with the action that is not easy to calculate called a token. When the form or link to take an action like deleting the account is sent to the browser the site sends along a string that includes something unique and only known by the site and the user. When the request is submitted the site validates that the token is still present and is appropriate for the action being taken. If it doesn't validate, the action is denied.

Video of CSRF in action

This video gives an example of CSRF. The problem is not in Drupal, but is in Tumblr. Tumblr does not confirm the intent of users using a CSRF token when a user deletes a submitted question.

In other operations on the site, Tumblr uses a session specific token that is the same during an entire session. This token is sent as a POST parameter and confirmed on the server side prior to accepting the operation.

Protect Against Cross Site Request Forgeries in Drupal

The next step, of course, is to Protect your Drupal module against CSRF