Cross-Site Request Forgery (CSRF) is a type of web application security vulnerability that allows an attacker to execute unwanted actions without the knowledge of the victim on a web application in which the victim is authenticated. It works by tricking a victim's browser into making a request to a web application on behalf of the attacker.

The attack is typically done by embedding a malicious link or form on a website that the victim is likely to visit. When the victim clicks on the link or submits the form, the browser sends a request to the web application on behalf of the attacker, using the victim's authentication cookies. The web application then processes the request as if it came from the victim, allowing the attacker to perform actions such as changing the victim's password or making a fraudulent transaction, or any other actions that can be performed in the application.

Imagine that you're logged into your online banking account, and you click on a link in an email or on a website that you trust. Once the attacker’s web page is loaded, the page can automatically make a request to your online bank account to transfer money out to the attacker’s account without you knowing.

Impact

The impact of a CSRF attack can be severe, as it allows an attacker to perform any action on behalf of the victim. For example:

1.     Making fraudulent transactions - CSRF can be used to perform transactions from a victim’s account by tricking the victim into visiting an attacker-controlled web page.

2.     Modifying account settings - An attacker can use CSRF to change a victim’s account settings like email, password or other personal information.

3.   Performing sensitive actions on behalf of the user - An adversary can use CSRF to create, update or delete data. For example, making a purchase on an application using the victim’s account or posting a message or comment to a post on behalf of the victim.

Past CSRF Incidents

Here are some notable CSRF incidents that affected several big tech companies:

1. PayPal: In 2008, security researchers discovered a vulnerability in PayPal that allowed attackers to make unauthorized purchases using the victim's account. The vulnerability was caused by the lack of proper CSRF protection on PayPal's website. Attackers were able to craft a malicious link that, when clicked by the victim, would make a request to PayPal to purchase a product using the victim's account. Because the victim was already logged in to PayPal, the request was executed with the victim's privileges, resulting in an unauthorized purchase.

2. LinkedIn: In 2011, a CSRF vulnerability was discovered on LinkedIn that allowed attackers to gain unauthorized access to user accounts. The vulnerability was caused by a lack of CSRF protection on certain forms, which allowed attackers to craft a malicious link. When clicked by a logged-in LinkedIn user, it would automatically perform an action on the user's behalf, such as sending an invitation to connect to another user. The vulnerability was quickly patched by LinkedIn once discovered, but it is not known how many users were affected.

3. Yahoo!: In 2013, a vulnerability was discovered in Yahoo! that allowed attackers to reset the users’ passwords. The vulnerability was caused by a lack of proper CSRF protection in the password reset process. Attackers were able to craft a malicious link that, when clicked by the victim, would make a request to Yahoo! to reset the victim's password. Since the victim was already logged in to Yahoo!, the request was executed with the victim's privileges, resulting in the attacker being able to reset the victim's password and gain access to their account.

4. Google: In 2016, a vulnerability was discovered in Google that allowed attackers to remotely execute code in the context of a Google account. The vulnerability was caused by a lack of proper CSRF protection in certain parts of Google's website. Attackers were able to craft a malicious link that, when clicked by the victim, would make a request to Google that would execute code in the victim's browser. The executed code would then make a request to Google with the victim's privileges, allowing the attacker to perform unauthorized actions. 

5. MyEtherWallet: In 2018, MyEtherWallet, a popular online wallet for Ethereum and other cryptocurrencies, was targeted by a CSRF attack. The attacker used phishing techniques to trick users into visiting a malicious website that included a hidden script to steal their private keys. As a result, several users lost their funds to the attacker.

Challenges, Bypasses & Mitigations 

Challenges identifying CSRF

If requests are sent as JSON body

Once the vulnerable endpoint is identified using Burp Suite or any other way, the next step is to craft a JSON request. This can be done by crafting an HTML page that makes the JSON request when loaded.

• Check if the application accepts the below Content-Type request with JSON POST data. These are the default Content-Type values. 

  • text/plain

  • application/x-www-form-urlencoded

  • application/multipart/form-data

Note: Now we cannot make cross-site requests through the JavaScript code since the latest browsers do not send the cookie header in the cross request (request through the JavaScript code) if the SameSite cookie attribute is not explicitly set to None - a security feature of modern browsers. However, we can make the request using the HTML form for JSON POST data.

If the CSRF token is present in the request

There are several ways that an attacker can bypass the CSRF tokens and exploit CSRF vulnerabilities:

• Send the request with a blank token value.

• Send the request after removing the variable and value of the token from the request.

• Use token prediction which involves guessing, brute-forcing, decoding and creating new tokens.

• Send the request replacing the CSRF token with a Null byte character (%00).

• Send the request replacing the token with the same length random token.

• Try to edit the token, for example, remove special characters (glassdoor CSRF bug).

• Steal tokens using Cross Site Scripting (XSS) or other means.

• Token replay i.e. reusing a previously obtained token, e.g. stealing it from the victim’s browser.

• Try sending a token obtained for another user.

If the Referer header or Origin header is checked

Look for bypasses for domain validation. This method works only if the domain validation is weak.

• If example.com is the domain, try with:

  • testexample.com

  • test-example.com

  • example.test.com or similar. If that's working, then buy a similar domain and host an HTML form that submits the CSRF request on it.

Other possible bypasses

Try one of the following bypasses according to their request condition:

• Try changing the value of the parameter with 1, aaa, etc.

• Try with the same length parameter value with arbitrary strings.

• If a header is used that acts as a CSRF token, try removing that header from the request.

•  If the parameter/parameter(s) values are validated on the server side, try changing the request methods from POST to GET.

Example attack scenarios

These are some vulnerabilities we found recently on production web applications.

1. On a web application, there was an option to delete the user's account but it was a JSON request:
   DELETE /Accounts/delete/ HTTP/1.1

Host: example.com
    The below payload was then used to force the logged-in user to delete their account.
    <a href="aa"onmouseover='$.ajax({url:"https://example.com/Accounts/delete",type: "DELETE",data:"",success: function(response){alert(1);}});'>aaaa</a>

2. A web application allows a user to link their bank account and create virtual cards that can be used for transactions. There was a GET request which will make the user log in. The request looks like this: https://example.com/redirect/{Base64encodedstring}%22/%2F{path}
   Below is the attack scenario:

   1. The attacker logged into their account.

   2. The attacker then created the GET request and sent it to the victim.

   3. The victim loads the request on their browser.

   4. The victim is logged into the attacker’s account without their knowledge.

   5. When the victim visits example.com, the victim is asked to link their bank account.

   6. In this instance, the victim will think it was their own account and not the attacker’s.

   7. Linking of the bank account will be added to the attacker’s account instead without the victim’s knowledge.

   8. Now the attacker can use the account and steal money using the cards from the victim’s bank account.

Mitigations

Implement SameSite cookies

One way to mitigate CSRF attacks is by using the SameSite attribute in cookies. A cookie's SameSite attribute allows users to choose whether or not a cookie should be delivered with a cross-site request. The SameSite attribute can be used in the following ways to minimize CSRF exposure:

1.     Strict mode: By setting the SameSite attribute to Strict, the browser will not include the cookie in any requests originating from another site. This mode provides the strongest protection against CSRF attacks.

2.     Lax mode: If the SameSite attribute is set to Lax, then the browser will include the cookie in requests that originate from another site, but only if two conditions are met:       

• The request uses the GET method. Requests with other methods, such as POST, will not include the cookie. 

• The request resulted from top-level navigation by the user, such as clicking a link. Other requests, such as those initiated by scripts, will not include the cookie.

Note: Some applications do implement sensitive actions using GET requests. In such cases, the Lax mode is not a viable mitigation.

Validate CSRF tokens

1.     CSRF tokens should be unique, random, and unpredictable.

2.     Tokens should be tied to the current user session, and old CSRF tokens should not work after signing out.

3.     Validate each bit of the CSRF token.

4.     Create non-decodable and non-sequential CSRF tokens.

Other recommendations for preventing CSRF attacks

1.     Don’t allow performing sensitive actions using the GET method.

2.     Test the web application and make sure there is no other vulnerability present which an attacker can leverage to steal tokens.

3.     While validating the Referer header, validate with a safelist of domains.

4.     Implement CSRF with custom headers, such as ANTI-CSRF Header: XXXX.

Tools for testing CSRF

• XSRFProbe (https://github.com/0xInfection/XSRFProbe) - Checks all the forms for CSRF protection on a given URL and generates CSRF Proof of Concept(PoC).

• CSRFT (https://github.com/PaulSec/CSRFT) -  An HTTP server in NodeJS that will communicate with the victim and send a payload that will be executed using JavaScript.

• Bolt (https://github.com/s0md3v/Bolt)   - Bolt does the crawling of the website for all HTML forms and performs automated CSRF testing.

About the Author

Safaras K A is an Associate Security Engineer with Certus Cybersecurity and is an expert penetration tester with particular experience in application systems (application protocol interfaces, frontend/backend servers), fine-tuning WAF security policies and patch detected vulnerabilities and identifying misconfigurations across various cloud services such as IAM, AWS Cognito, and S3.