Attack Afternoon – CSRF Countermeasures #1

The last post of this series presented one of the most important attacks on web applications: “Cross-Site Request Forgery” (CSRF).

Short repetition of the CSRF attack vector: If a web application identifies users via session cookies, it is the user’s browser who takes care that these are attached to every HTTP request while the user is logged in to the application. An attacker can now try to send requests to this web application, for instance if he lures the user into visiting a manipulated web site. A web application that is susceptible to CSRF will only check if the session cookie (which automatically gets attached by the user’s browser) is valid. In this case it executes the attacker-triggered action in the context of the user’s session without the user being aware of it. So in general, all web applications that manage session state via cookies face the threat of being vulnerable to CSRF and need to implement protection measures against this attack vector.

One possibility to prevent CSRF is the usage of an anti-CSRF token. The application generates a (cryptographic) random value which is long enough for every session. This value is written into a hidden form field within the HTML page, for instance. As a consequence, this token is only sent back to the server if the user submits this HTML form. The token is not attached by the browser automatically (as is the case for cookies). Whenever the application receives a form submit, it also receives the hidden form field containing the anti-CSRF token and checks whether it is identical with the value stored for the respective user session.

If an attacker tries to perform a CSRF attack now he can of course still issue HTTP requests with arbitrary content and the browser will still attach the user’s session cookie. But the attacker cannot guess the anti-CSRF token connected to the user session because this token only exists on the HTML page in the user’s browser (to which the attacker has no access). The application will reject such a request and does not execute any action triggered by the attacker.

Luckily, many web application frameworks provide standard functionality for generating, storing and validating such tokens. However, it is important that this functionality is active and configured correctly throughout the entire application.

Another countermeasure is presented in one of our next Attack Afternoons. Stay tuned!

Do you already have a CSRF protection and want to have it checked? Please feel free to contact us!