CSRF token? Why not try to bypass it?

Cross-Site Request Forgery (aka CSRF) attack is one of the common web application security vulnerabilities. The application uses an anti-CSRF token to prevent this attack, but due to improper validation of these tokens at the server-side, an attacker may bypass this protection. Even though the application has an anti-CSRF token present, there is still a space to try out the token validation checks at the time of penetration testing. This blog talks about the same, followed by what can be done to protect against a bypass.

Introduction:

CSRF is a type of attack which makes users perform unintended actions on a website in which they are currently authenticated. With social engineering, an attacker may fool the users of a website into performing certain actions.

Impact:

Assume the victim is prone to social engineering. In this case, a successful CSRF attack can make the users execute state-changing requests like changing their password, personal information such as email ids, transferring funds to an undesired person’s account, and so on. If the victim has admin privileges, the CSRF attack can even take over the entire website.

There are many types of impact that can occur due to this vulnerability, which also depends on the functionality, a web application provides. Some are:

1. Change email id or password resulting in a full account takeover.
2. Fund transfer to an unknown person.
3. Change personal information like name, address, etc.

Prerequisite: 

The only primary requirement to successfully execute a CSRF attack is that the victim(s) must be authenticated.

Attack Scenario:

An attacker looks for a parameter that represents the anti-CSRF token. If it is not present, then the attack might be possible, and if that token is used, the attacker may try to bypass it. 

For example:

Suppose a web application has a functionality to change the email address of a logged-in user. It might be similar to the request shown below.

Scenario 1:

POST /change_email

REQUEST BODY:

id=1&email=NEW_EMAIL_ID

There is no anti-CSRF token in the above request, and it can be used directly to change the email id of the victim, which is currently authenticated. 

Scenario 2:

POST /change_email

REQUEST BODY:

id=1&email=NEW_EMAIL_ID&csrftoken=12345

CSRF token is present, but the validation of the CSRF token at the endpoint was at fault. How can one get to know about the broken CSRF validation? An attacker can do it by removing the ‘csrftoken’ parameter or by giving a blank ‘csrftoken’ parameter. Both examples can be seen below.

POST /change_email

REQUEST BODY:

id=1&email=NEW_EMAIL_ID

OR

POST /change_email

REQUEST BODY:

id=1&email=NEW_EMAIL_ID&csrftoken=

If any of the above requests successfully change the email ID of the victim whose id=1, then the attack is successful.

By creating a payload file of any of the above requests shown in the example, an attacker can change the email id of the victim. Next, the attacker can put his/her email ID in the ‘email’ parameter, and then he can use the ‘forgot password’ functionality to take over the victim’s account.

Some other tricks to bypass CSRF are but not limited to:

• By creating your own CSRF token, by changing some of its original bits
• By reusing the original anti-CSRF token
• Weak cryptography leads to generating the anti-CSRF token.
• By guessing anti-CSRF token 
• Change the POST request method to GET request method to bypass the CSRF token.

Figure 1: CSRF attack flow

Remediations:

1. Creating a CSRF token and validating it at the server-side is an effective mechanism to protect against such an attack. CSRF tokens should be:
   1. Unique for each user session
   2. It should be a secret
   3. It should be unpredictable
2. Never pass the CSRF tokens using cookies since if the site is vulnerable to XSS, then it is possible to extract the tokens along with the session cookie(s).