base under attack
ethical hacking, penetration testing, IT security and other news

Introduction to CSRF

Cross-site request forgery, or CSRF, is a common attack vector for web-based applications. In a nutshell, it allows the attacker to execute [destructive] actions in an application (through a HTTP request) on your behalf. It makes the assumption that you are already authenticated and have a valid session, and then makes the request either transparently or by tricking you into making the request yourself (such as through a misleading link).

The attack could be carried out in the following way:

1. You authenticate to the web application by logging in, and initiate a session that is stored in a cookie or otherwise persisted somehow.

2. You visit a malicious website or read a malicious email, while your session is still active.

3. The malicious site initiates a request to the web application where you are still logged in, through a method such as:

a. An image tag that makes a request - <img src=”http://example.com/app/user/delete/1″>

b. An iframe

c. A direct link

The impact of this attack is that the attack can execute destructive or otherwise malicious actions in the web application using your existing session. Examples include deleting a record from the database, updating or manipulating other data, or otherwise making unauthorized changes to the state of the application.

Ruby on Rails CSRF Protection

As of version 2, Ruby on Rails ships with a system for preventing CSRF attacks. It uses an implementation of form based authentication tokens - which are submitted as a hidden field along with POST requests. This effectively prevents the attacker from making a cross site request, as the attacker does not know the unique token which is to be submitted with each form.

CSRF protection can be activated by placing the following line in your controller (prefererably application.rb - so all controllers will inherit it)

protect_from_forgery :secret => ‘choose your own secret here’

Once this line is in place, the Rails form helpers will automatically insert the authenticity tokens in your forms. In the event that an unauthorized request in made (i.e., the token is incorrect), Rails will throw a ActionController::InvalidAuthenticityToken exception.

Application Design Considerations

It is important to understand that this CSRF protection only works with POST requests, not GET requests. If you are using a REST-style implementation in your Rails app, this will protect PUT and DELETE requests as well, since Rails just “fakes” these requests by using a POST along with a hidden field.

In order to effectively protect your application from CSRF, it is important to use only POST, PUT, or DELETE requests for destructive actions, or any other actions that change the state of the application. GET requests should only be used for “safe” and non-destructive actions, such as a “show” or “index” method.