S 4.403 Prevention of Cross-Site Request Forgery (CSRF, XSRF, Session Riding)

Initiation responsibility: Persons responsible for individual applications, IT Security Officer

Implementation responsibility: Developer, Administrator

Within the framework of a CSRF attack (Cross-Site Request Forgery), a user is provided with a command for a web application (e.g. in the form of a link in a guest book) by an attacker. If the user clicks this link, the command is sent to the web application and executed in the context of this user. If the user is logged in to the web application, the trust relationship of the user regarding the web application is exploited and the command is executed with the rights of the user.

In order to make such attacks more difficult, the web application should support security mechanisms allowing for a differentiation between intended site calls of the user and accidentally redirected commands of third parties. The following security safeguards are intended to prevent critical activities being executed accidentally due to CSRF attacks.

Use of an additional token

Within the framework of a CSRF attack, a valid HTTP request must be simulated and transmitted to the victim. Such an HTTP request may be imaged by an URL to the web application, for example (e.g. http://webapp.tld/addUser?name=benutzer). For this, the attacker must know the required request parameters, e.g. GET and POST variables, for the call. These parameters can generally be determined easily.

As a protection against a CSRF attack, a secret token can be implemented that can only be guessed by the attacker with difficulty. Every time the site of the web application is called, this token is transmitted in forms (Double Submit Cookies) as a parameter in URLs or as a hidden element (Hidden-Field). During each client request, the web application checks whether the transmitted token corresponds to the value stored for the session. In the event of an error, the requested access is denied. Without knowing this token, an attacker cannot simulate a valid HTTP request.

Although the SessionID is a confidential date and therefore could be used as a token for providing protection against CSRF attacks, a separate token should preferably be created. In this case, similar requirements should be applicable to the token as are applicable to the SessionID.

If CSRF protection is implemented, it is recommendable to use the function from frameworks already used if these offer a corresponding implementation.

For web applications with high protection requirements, creating the token for each request in such a way that the client is provided with a new token for each web application call, which then must be used in the subsequent request, should be taken into consideration.

Before critical activities are executed (e.g. state-changing requests such as a password change), the user should be re-authenticated by the web application. This way, these functions cannot be performed unnoticed, but an interaction with the user is required. Web applications with high protection requirements should use an authentication method with several authentication factors (e.g. TAN, chip card).

Alternatively, the user may be redirected to a site requiring user interaction when calling critical activities before the activity can be performed (e.g. entering a random character string). Only after the user has performed the interaction (e.g. proper character string entered) will he/she be redirected and the initial request processed. Instead of the character string, other mechanisms requiring user interaction may also be used (e.g. CAPTCHAs or riddle questions, see also S 4.405 Preventing resources (DoS) of web applications from being blocked).

The referrer field in the HTTP request (the URL of the website the user was redirected to the current site from) may be used as a further security feature. A request of a user of a web application often is only valid if the referrer field contains an URL of the proper web application. This way, it can be assumed that the request was generated by clicking a link of the web application.

In this, it must be taken into consideration that the referrer field may be disabled or filtered (e.g. for data privacy reasons) and that the safeguard therefore cannot be implemented for all web applications.

Bypassing protection mechanisms

Security mechanisms for protection against CSRF attacks based on the referrer field or additional tokens (see section Using an additional token) may be bypassed by Cross-Site-Scripting attacks. Therefore, the proper filtration of user accounts (see S 4.393 Comprehensive input and output validation for web applications) is decisive for the efficiency of the security mechanisms regarding the protection against CSRF attacks.

At least one of the two review questions should be implemented in order to provide protection against CSFR attacks.

Review questions:

© Federal Office for Information Security. All rights reserved.