Skip to main content

Prevent Cross-Site Request Forgery (CSRF) attacks

Cross-Site Request Forgery (CSRF) allows an attacker to perform actions in a different security context, such as another logged-in user. Read here how you can efficiently fix a CSRF vulnerability.

Security assessment​

Security_Assessment_CSRF

CVSS vector: AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N

Vulnerability information​

This type of attack, also known as CSRF or XSRF, Cross-Site Reference Forgery, Hostile Linking, and more, allow an attacker to carry out actions (requests) within an application where a user is currently logged in. It is cross-site or cross-origin because it uses different websites or elements to interfere, i.e., to send requests within an application that originate from outside the application. A CSRF sends an HTTP request whenever a user opens a website containing malicious code to achieve its aim. The code is embedded so that no further actions by the user are required. This kind of attack is widely used in spam emails. The attack starts and forges actions by selecting a malicious URL. The HTTP requests might access, modify, or delete sensitive data and the user is not aware of this activity.

While CSRF attacks mainly occur through user browsers, they can effectively be executed through any file that allows scripting, including word and XML documents, RSS feeds, and more. For additional information, see CSRF Scanner to discover Cross-Site Request Forgery vulnerabilities to which you might be exposed. It only takes 2 minutes to scan your web application, and it is free!

Prevent attacks​

To prevent CSRF injection attacks, you must ensure that an attacker cannot craft an arbitrary request run in the security context of any other user and send from a different website. This is one of the main conditions that need to be in place for a CSRF attack to be successful. Disrupting this condition prevents the possibility of such an attack.

Token-based prevention​

As stated by the OWASP Cross-Site Request Forgery Prevention Cheat Sheet, the most common mitigation technique for cross-site request forgery attacks is using a CSRF token (also known as a synchronizer token or anti-CSRF token). These session tokens are unpredictable and unique values are generated by the application and sent to the client. After that, they are sent back in the request made by the client to the server, which verifies the request.

This introduces an unknown element that can effectively defuse the CSRF attack. Any request not originating from the original form will not include the correct value for the CSRF token and can be easily discarded.

Common CSRF token vulnerabilities​

Yet, some vulnerabilities can arise in using CSRF tokens due to omissions in the procedure. The most common CSRF token vulnerabilities include:

  • Tokens are validated and used only when POST requests and not GET requests are made
  • Validation occurs only if the session token is present, and if it is omitted, verification is also skipped
  • Tokens are not tied to the current user session but are compared to tokens issued at any point by the application
  • Tokens are connected to a cookie but not one that is used to track the current session
  • Applications do not maintain a record of tokens. Instead, the token is included in the cookie, and the application verifies that the token in the request is the same as the one in the cookie.

All of the above constitute vulnerabilities that can open the door to a CSRF attack. To defend against such an attack, CSRF tokens need to be implemented correctly, along with several other mitigation techniques.

Using modern frameworks, tokens-based CSRF protection is typically included or can easily be added to forms and validated by the corresponding middleware. Furthermore, for single-page applications, the CSRF token may be provided by a meta tag which is then read from the JavaScript in the browser and amended to every request.

A double-submit cookie token approach can be used if using a valid token on the server side is impossible. In this cookie-based session handling, when a user visits a website, the site generates a value that is stored as a cookie on the user device, apart from the cookie that serves as a session identifier.

When a legitimate request is submitted to the site, it must contain the same value as included in the cookie. The server then verifies this, and the request parameter is accepted if the values match.

As recommended by OWASP, this approach should be used with a CSRF token strategy and not as a substitute.

The same-site cookie approach restricts the origin from which a cookie can be sent. Thus, CSRF exploits the possibility of making a cross-origin request (and hence same-site cookies). However, limiting requests so they can only be sent from the origin to which a cookie is related prevents the ability to send external requests to an application.

Custom request header​

A technique that is particularly effective for AJAX or API endpoints is custom request headers. In this approach, JavaScript is used to add a custom header. Unfortunately, JavaScript cannot make cross-origin requests with a custom header because of the SOP security restrictions.

This prevents sending a cross-domain request with custom headers, eliminating the possibility of a CSRF attack.

Django​

Django is similarly easy to protect any form by a CSRF-Token using the snippet within the <form></form> tags.

{% raw %} {% csrf_token %} {% endraw %}

To provide the token for use with JavaScript requests, retrieve it from its storage cookie and add it to the request.

var csrftoken = Cookies.get('csrftoken');  
...  
xhr.setRequestHeader("X-CSRFToken", csrftoken);

See the Django documentation for more detailed examples.

Laravel​

To protect forms in Laravel, include the following code within the <form></form> tags.

{% raw %} {{ csrf_field() }} {% endraw %}

For JavaScript requests, the file resources/assets/js/bootstrap.js automatically configures the CSRF-token meta tag, which the Axios HTTP library will use. If you are not using this library, check the Laravel documentation for more information.

Last updated on