Cross Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) is a cyberattack technique that forces a user to submit a request to a web application they have currently authenticated. CSRF is also referred to as session riding (sea surf) and hostile linking. CSRF is also classified as a flaw under the OWASP Top 10 A5 category.

CSRF can exploit a vulnerability in a web application to differentiate the source and validity of a user request. Additionally, threat actors often use social engineering techniques to maneuver an authenticated user into executing malicious actions. For example, malicious but seemingly legitimate links in an email can help the threat actor co-opt the victim’s identity and access privileges.

CSRF attacks can harm the target organization’s reputation, result in the theft of financial resources, and hurt the specific user exploited.  CSRF attacks have been utilized against websites such as Gmail, Facebook, and many others.

A CSRF attack seeks to submit a user change such as submitting a transaction, changing a password, deleting a record, or more. CSRF attacks may be launched from social media platforms. In this case, the target victim is lured to click a malicious URL containing an unauthorized request for a specific web application. The malicious request also includes authorization credentials such as session cookies for the particular web application. If the user is in an active session with the application, the stolen cookies fool the application into believing this is an authorized request submitted by the user. Thus, the threat actor successfully exploits the web application. 

CSRF target functionality that results in a change of state change on the server. They can also result in the theft and loss of data. Once a CSRF attack is successful, a threat actor can initiate a transfer of funds, make fraudulent purchases, change passwords, and more. Pretty much do anything that is authorized functionality for users that access the website.

In practice, how does this work?

Users often attempt to access a website that has already logged in – perhaps from another browser window. As a result, the browser will often automatically include credentials associated with the website along with their request. These credentials often include the victim’s session cookie, basic authentication credentials, IP address, and more. 

Once again, the web apps must fail to understand the difference between a valid request and a malicious fake request. One good example is to consider the setup for CSRF in support of a fraudulent bank application. In this example, the threat actor seeks to set up fraudulent financial transfers to move money out of the victim’s account. 

The threat actor must generate a malicious URL for the exploit to launch the attack, lure the victim into clicking the malicious URL. The victim must also have an active session currently active. Once the victim clicks on the malicious URL, they receive within their browser the results. These, in turn, cause the browser to open the URL automatically, and then the transfer of funds is initiated. The transfer would go to an account and in an amount specified by the attacker.

It is important to note that an active session is required for the targeted application. The malicious URL must be done correctly – the syntax must be valid. If anything is wrong, the targeted application will ignore or reject the malicious false request.

How can we stop these sorts of CSRF attacks?

Most importantly, applications must determine if an HTTP request is generated as part of a legitimate transaction. One best practice to prevent this is a CSRF token. A CSRF token is a long, randomly generated token uniquely generated for each user’s session. Well-designed applications generate and tag these CSRF tokens for every user session. At the end of the session, the token must expire. Best practice requires that the CSRF tokens are part of the HTML form. Therefore, they should not be stored in session cookies. It is also best practice to generate the CSRF tokens using a technique such as a cryptographic random number generator.

Applications may make use of the HTTP Referer header to attempt to defend against CSRF attacks. This use of the header verifies that the request originated from the application’s domain. Unfortunately, this approach is vulnerable to bypass.

It is also highly beneficial to scan and test your web applications for security vulnerabilities. Pen testing can help you rapidly understand the relative vulnerability of your exposed applications.

Other resources that can help with CSRF attacks

The OWASP code review guide article shows you how to review code for CSRF vulnerabilities. In addition, OWASP provides additional details in this CSRF code issues reference guide. Finally, OWASP includes a testing guide that shows you how to test for CSRF vulnerabilities.

Want to learn more? Check out our FREE Bugcrowd University to sharpen your hacking skills.
Organizations the world over need your help!Join our researcher community to connect with hundreds of organization programs focused on finding their security vulnerabilities. Our vast directory includes programs for all skill levels, across many industries and from around the world.