Cross-Site Request Forgery (CSRF) - What Is It, How to Prevent It

CSRF is a web vulnerability that has appeared in the OWASP Top 10 several times. However, it has long been overlooked by the security community, even though it is capable of launching powerful attacks.

This blog will go over the CSRF vulnerability and CSRF attacks in depth, as well as how to prevent them. 

What is CSRF?

Cross-Site Forgery Request (CSRF/XSRF), or Sea Surf is an attack that leverages the trusted relationship between the browser and an API or website to forge requests and then steal sensitive data, get privileged access to private systems and cause further damage. The attacker typically targets actions that only privileged users can perform. Also known as Session Riding, CSRF is a web security flaw that manipulates a web browser into performing an unintended action. A CSRF attack exploits a web application vulnerability if it cannot distinguish between a user-generated request and a request generated by a user without their permission. 

How Does Cross-Site Request Forgery Work?

When a harmful web site, email, blog, instant message, or program causes an authenticated user's browser to carry out an unwanted action on a trusted website/web application, a CSRF attack takes place. This attack uses the cookies that are automatically stored by the browser. As a result, the browser cannot tell the difference between a legitimate request and a forged one. 

The primary goal of a CSRF attack is to coerce the user into submitting an unauthenticated request to alter the state of the server. These requests may include, but are not limited to, submitting or deleting a record, initiating a transfer of funds, making a purchase, changing a password, and/or sending a message.

Hackers commonly turn to social engineering platforms to launch such attacks. This fools the user into visiting a URL containing a malicious, and unauthorized request for a specific web application. The targeted web app then receives this malicious request from the user’s browser. If the user is currently logged in to a web application, the application will consider this new request as an authorized request provided by the user. This is how the attacker is able to exploit the application’s CSRF vulnerability. 

To carry out a successful CSRF attack, the following conditions must be met:

• The user must be logged into an active session with the vulnerable app or website
• The attacker must use a valid and state-changing URL to carry out the attack
• The attacker must use the correct URL parameters so that the request doesn’t get rejected by the target application/website 
  

Common CSRF Vulnerabilities: CSRF Tokens

Before getting into CSRF vulnerabilities, let’s understand what a CSRF token is. 

A CSRF token is a distinct, secret, unpredictable value generated by the server-side application and sent to the client in a way that it is included in the client's following HTTP request. When the subsequent request is made, the server-side application verifies that it contains the expected token and rejects the request if the token is unavailable or incorrect. Errors in this verification process are some of the most common causes for CSRF vulnerabilities. Check out the most common CSRF vulnerabilities below: 

The presence of a token is required for validation

Some applications bypass the verification process if the token is not present. This means that as long as the hacker can find and delete the piece of code containing token data, the app will not perform token validation. 

The CSRF token is not linked to the user session

Some applications have a set collection of tokens. As long as a token from this set is used, the app accepts it. However, these tokens are not linked to specific users. So the attacker can acquire any token from the collection and use it to mimic a real user. 

Token validation varies depending on the HTTP method

HTTP methods allow communication between the client and server. POST, GET, PUT, PATCH, and DELETE are some of the most common and primarily used HTTP methods for creating, reading, updating, and deleting operations respectively. In some apps, token validation only works for certain HTTP methods. For instance, CSRF validation might work only with the GET method and not with the POST method. In such cases, the attacker can switch between HTTP methods to bypass the verification process. 

 
The CSRF token is stored in the cookie



In some applications, there isn’t a record of previously used tokens or the tokens that are already being used. Instead, the token’s parameters are usually stored in the user’s cookie. This way, an attacker can create a duplicate cookie with the user’s token, in the format of the application and insert it into the user’s browser to launch the CSRF attack. Since the malicious cookie’s parameters match the ones of the user’s, this request will be validated by the application.  

CSRF Prevention

The most basic method of preventing CSRF is to use CSRF tokens. These tokens don’t allow hackers to create a fully valid HTTP request that can be fed to the user. However, make sure to avoid the errors from the previous section while implementing CSRF tokens. In addition, here are some more preventive actions you can take: 

Advanced Validation Techniques

When all of the form's parameters are identified, an attacker can launch a CSRF attack. In order to prevent a CSRF attack, you can add an extra parameter with a value that is unknown to the attacker, but the server requires validation.

SameSite Cookie Attribute

The SameSite attribute allows you to specify if and how cookies are sent in cross-site requests. An application can prevent the standard browser behavior of automatically adding cookies to requests irrespective of their origin, by setting the SameSite attribute on session cookies.

CSRF Defense Based on User Interaction

User validation techniques can be especially helpful when it comes to cases such as financial transactions. For instance, adding a CAPTCHA ensures that the user is a human and not a robot. Similarly, a one-time cookie can be used to make sure that the current active session is being used by the user and not the attacker. This one-time, unique token is typically sent to the user’s email address or phone number where it is validated against data previously provided by the user. Re-authentication is another method that can be used to distinguish between a CSRF session and a legitimate user. 

Login Form CSRF

Many times developers will assume that there is no risk of a CSRF attack during login since the user has not yet been authenticated. However, attackers can still perform login CSRF attacks. These attacks can be mitigated by starting a session before user authentication, and asking for the token at the login form. Additionally, strict subdomain and path-level referrer header verification can also be used to mitigate login form risk. 

Regular Security Testing

Regularly scanning and testing your websites and web applications helps you identify and address security vulnerabilities such as CSRF vulnerabilities. 

EvolveAPP can help your organization to orchestrate and automate the integration of application security testing into your DevOps pipelines. By running regular, automated, and repeatable application security tests you can stay on top of the latest vulnerabilities and manage critical risks throughout the year.

Conclusion

Currently, CSRF ranks #10 in the OWASP Top 10 vulnerabilities. However, it continues to have massive potential to cause damage on any platform where data can be altered. Implement the above-mentioned fixes to secure your website/web application from CSRF attacks. Book a demo with our expert security team to explore more application and website security solutions.