Cross-Site Request Forgery (CSRF) is a type of attack that occurs when a Web site, e-mail, blog, instant message, or malicious program causes a user's Web browser to perform an unwanted action on a trusted site when the user is authenticated. A CSRF attack works because browser requests automatically include all cookies, including session cookies. Therefore, if the user is authenticated to the site, the site cannot distinguish between legitimate authorized requests and counterfeit authenticated requests. This attack is foiled if proper authentication mechanism is used, which implies the need for a challenge-response mechanism that verifies the identity and authority of the requester.
The impact of a successful CSRF attack is limited to the capabilities exposed by the vulnerable application and the privileges of the user. For example, this attack could lead to a transfer of funds, change of a password, or a purchase using the user's credentials.
In short, the following principles should be followed to defend against CSRF:
Check whether the development framework used has built-in CSRF protection and use it;
If the framework does not have built-in CSRF protection, add CSRF tokens to all state change requests (requests that cause actions on the site) and validate them in the backend;
For static software, use the synchronizer token scheme;
For stateless software, use double-sending cookies:
Remember that any Cross-Site Scripting (XSS) vulnerability can be used to defeat all CSRF mitigation techniques!
Token-based mitigation.
The synchronization token scheme is one of the most popular and recommended methods to mitigate CSRF.
Synchronizer token defenses have been integrated into many frameworks. It is highly recommended to check if the framework you are using has an option to get CSRF protection by default before trying to build a custom token generation scheme. For example, .NET has built-in protection that adds a token to resources vulnerable to CSRF. The user is responsible for proper configuration (such as key and token management) before using these built-in CSRF protections that generate tokens to protect CSRF vulnerable resources.
Synchronizer token diagram.
CSRF tokens must be generated server-side. They can be generated once per user session or per request. Per-request tokens are more secure than per-session tokens because the time interval in which an attacker can exploit stolen tokens is minimal. However, this can lead to usability issues. For example, the functionality of the browser's "Back" button is often hampered because the previous page may contain a token that is no longer valid. Interaction with this previous page will cause a false-positive CSRF security event on the server. In the per-session token implementation, after the initial token generation, the value is stored in the session and used for each subsequent request until the session expires.
When a request is issued by the client, the server-side component must check the existence and validity of the token in the request against the token found in the user's session. If the token is not found in the request or if the value provided does not match the value in the user session, the request must be aborted. Additional actions, such as logging the event as a potential CSRF attack in progress, should also be considered.
The CSRF tokens must be:
Unique per user session;
secret;
unpredictable (random value generated by a secure method).
CSRF tokens prevent CSRF because without tokens the attacker cannot create valid requests to the backend server.
CSRF tokens should not be transmitted using cookies.
The CSRF token can be added through hidden fields, headers, and can be used with forms and AJAX calls. Make sure the token is not transmitted in the server logs or URL.