Attack Afternoon – CSRF Countermeasures #2

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.

There are many ways to protect against CSRF attacks. For example, random values generated by the server and built into the form as hidden parameters. After submitting the form, the web server checks the request for the hidden parameter and only accepts the request if it contains the correct parameter. We already introduced this measure in the last post “Attack Afternoon – CSRF Countermeasures #1“. The disadvantage of this measure is that the server must store and process additional data in addition to the session.

Another way to protect against CSRF – stateless – is the Double Submit Cookie method. When the user logs on, a cryptographically strong random value is stored in the user’s browser as an anti-CSRF cookie in addition to the session cookie. The cookie is automatically sent to the server with every request, but does not provide protection against CSRF on its own. The trick of Double Submit Cookie is that the server includes the value of the anti-CSRF cookie as a hidden parameter in every form. Therefore, the value of the anti-CSRF cookie is sent to the server once as a cookie and once as a parameter with each request. The server then only needs to check whether both values are identical. The request is only accepted if this is the case.

An attacker has no access to the value of the cookie and therefore cannot generate HTTP requests that contain the correct value as an additional parameter. CSRF attacks are therefore not possible. More information can be found at: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md#double-submit-cookie

For the exact implementation of the Double Submit Cookie as CSRF protection, there are various possibilities, which depend, among other things, on the architecture of the application. Here, too, errors can be made, which can cancel the CSRF protection. Details about potential attack possibilities can be found here: https://www.owasp.org/images/3/32/David_Johansson-Double_Defeat_of_Double-Submit_Cookie.pdf

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!