Web security: CSRF

Twelfth post in the web security series.

Cross-site request forgery (CSRF) is a quite common attack where basically an attacker manage to do some actions on your website on behalf of a regular user.

For instance, on a bank website, it could be to make the user transfer money to an other bank account. The idea is that the user is logged on your website and somehow (through an image on an other website, javascript excuting a post request, through a link in an email…) the user's browser is doing a request (POST or GET) with all the request arguments/post data to perform an action on your website. Since the user is logged with a valid session, the request is processed normally like it was the user doing it.

There are several ways to mitigate this kind of attack, the most common one being to never do actions that change the server state on a GET request (in fact the HTTP protocol says exactly that) and that a token is included in each POST request. The token is generated once when the session starts and is added as an hidden field in each form, when the form is submitted, the server verifies that the token has the same value as the one stored in the session.

Note:

CSRF is always possible (and you can't do much about it) if there are XSS vulnerabilites on your website. For critical actions, you can also ask the user to enter his password again.

Links:

• Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
• Do Your Anti-CSRF Tokens Really Protect Your Web Apps from CSRF Attacks?
• Cross-Site Request Forgeries