What is Cross Site Request Forgery (CSRF)?
A CSRF attack can force a user to perform unwanted actions on a web application. CSRF assumes that the user is already authenticated. Attackers typically use social engineering to trick users into clicking a link that performs actions that can benefit the attacker.
For example, on an eCommerce website, the attacker can cause the user to inadvertently make a purchase. On a bank website, the attacker can cause the user to transfer funds. If the user has administrative access to a web application, CSRF can be used to compromise the entire application.
In this article:
How CSRF Attacks Work
A website consists of client-side code, typically written in HTML and JavaScript, and server-side code, which depends on the framework used to build the website. Client-side code allows users to perform actions like navigating to different URLs, submitting HTML forms, and triggering AJAX requests via JavaScript. The server-side code intercepts the data sent in the HTTP request and handles it appropriately.
These server-side actions can also be triggered by forged HTTP requests, unless you explicitly protect them. CSRF attacks occur when a malicious attacker tricks the victim into clicking on a link or executing code that triggers a forged request. The malicious code is hosted on another domain controlled by the attacker, therefore the attack is known as “cross site” request forgery.
To protect yourself from CSRF, you need to do two things. Make sure your GET requests have no side effects, and only allow non-GET requests from your client code.
6 CSRF Protection Best Practices
1. Use Same-Site Cookies
CSRF attacks are only viable because cookies are sent with any requests sent to an origin related to that cookie. You can create a flag for a cookie, which converts it into a same-site cookie.
Threat actors can send a same-site cookie only if a user made a request from the cookie’s origin. However, it is not possible when a request is made across domains. The request source and the cookie have the same origin if the following conditions are met:
- They have the same protocol and host, but they do not share the same IP address.
- When applicable, they can also share the same port.
Not all browsers support same-site cookies (see a full compatibility chart), and a same-site cookie will default to a regular cookie when a visitor uses an older browser. It means same-site cookies are more suited as an added layer of defense, and you should only use them with other CSRF security mechanisms.
2. Use CSRF Tokens
A popular approach to stop CSRF is using a challenge token. A challenge token is connected with a specific user and is sent as a concealed value in all state-changing forms via the web application. This token is an anti-CSRF token, also known as a synchronizer token.
Here is how the anti-CSRF token works:
- The web server creates a token and retains it
- The token is statically created as a concealed field of the form
- The user submits the form
- The token is a part of the POST request information
- The application compares the token created and stored by the application with the token transferred in the request
- If these tokens are the same, the request is validated
- If these tokens are different, the request is rejected
This CSRF protection approach is known as the synchronizer token pattern. It secures the form from CSRF attacks because a cybercriminal also has to guess the token to trick a target into creating a valid request. Attackers cannot readily guess the token, and they cannot create it according to a predictable pattern. To improve protection, invalidate the token after a timeout period, or every time the user logs out.
Anti-CSRF tokens are typically exposed via AJAX – they are sent as request parameters or headers alongside AJAX requests. To be successful, an anti-CSRF mechanism must be cryptographically protected.
It is also recommended to utilize anti-CSRF options in development frameworks, rather than having developers create their own mechanisms. This reduces mistakes, makes implementation smoother, and in the end improves security.
3. Require Stronger Authentication for Sensitive Actions
Many websites require a secondary authentication measure or need reconfirmation of login details when a user carries out a sensitive action – for example, on a password reset page. Generally, the user needs to enter their old password before they create a new password.
This approach protects the user who could remain logged in by accident and minimizes the likelihood of CSRF attacks.
4. Mitigate Login CSRF
CSRF vulnerabilities can occur on login forms even when users are not logged in. For example, an attacker could employ CSRF to adopt an authenticated identity of the target on an eCommerce site using the attacker’s account. If the victim then enters their credit card details, an attacker could purchase items via the target’s stored credentials.
You can mitigate login CSRF by establishing pre-sessions that include tokens in the login form. You can use a pre-session only before a user is verified – do not reuse it after the user is authenticated. Instead, you should destroy the session and create a new one to avoid session fixation attacks.
If you do not trust subdomains within your master domain in your threat model, it is challenging to mitigate login CSRF. In this case, you can use strict subdomain and path level referrer header verification to mitigate CSRF on login forms.
5. Use Representational State Transfer (REST) Principles
Representational State Transfer (REST) is a set of design principles that assign actions (create, view, update, delete) to various HTTP verbs. Using REST-ful designs helps your site scale and keeps your code clean. REST demands that GET requests are only utilized for viewing resources.
Maintaining your GET requests side-effect-free will minimize the damage that maliciously created URLs can achieve. Consequently, an attacker has to work harder to create damaging POST requests.
6. Leverage Web Application Security Testing
After you have effectively resolved a vulnerability in a web application that could enable a CSRF attack, vulnerabilities can still occur later on. These vulnerabilities occur because developers update the application and change its code.
Given this, it is recommended that you continually test and scan your web applications for any vulnerabilities, including those connected with CSRF attacks. You should use web applications security tools.
CSRF Protection with Bright Security
Bright helps you automate the detection and remediation of many vulnerabilities including CSRF early in the development process, across web applications and APIs.
By shifting DAST scans left, and integrating them into the SDLC, developers and application security professionals can detect vulnerabilities early, and remediate them before they hit production. Bright completes scans in minutes and achieves zero false positives, by automatically validating every finding. This allows developers to adopt the solution and use it throughout the development lifecycle.
