Bypassing Unpredictable CSRF Token.

First lets see what is CSRF (Cross Site Request forgery) when a bad actor tricks a website into doing something behalf on you without your permission. Websites use special codes called CSRF tokens to stop this.

There are few different validation process to different request process, in this we are going to look into,

• Validation when it depends on the request method

Some website used to correctly validate Tokens on POST method but when attacker change method to GET website skip's validation process, so attacker can skip token validation an make changes on the victims website.

Example:-

-> POST /change-email HTTP2.0

XXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXX [email protected]&csrf_token=nnnnnnnnnnnndjdjdkgjgkjkej48

-> GET /change-email HTTP2.0

XXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXX [email protected]&csrf_token=nnnnnnnnnnnndjdjdkgjgkjkej48

Note - In the example where an email change request was involved, the CSRF token played a crucial role. While altering the CSRF token would lead to its rejection by the server, attackers can exploit vulnerabilities by changing the request method (POST->GET) to bypass server defences. This highlights the need for comprehensive CSRF protection, incorporating checks not only for CSRF token validity but also for the request method to strengthen defences against such attacks.

• Validation depends on the CSRF token being present

Some web application used to correctly validate CSRF_token when it presents in there request but completely ignore when token were omitted.

Example :-

-> POST /change-email HTTP2.0

XXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXX [email protected]&csrf_token=nnnnnnnnnnnndjdjdkgjgkjkej48

-> POST /change-email HTTP2.0

XXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXX

[email protected]

Note - when server had a request which contains a CSRF_token server will check does the server generated the particular token, if it is server will grant access to change the Email address, but what if attacker completely remove the token parameter from request body? if it is there no validation method to be found server will allow attacker to access and change the requested email to be change. This highlights the need for rigorous validation checks on the server side to ensure the presence and validity of the CSRF token in every incoming request.

• CSRF token is not tied to the user's session

Certain web applications utilize a global token pool stored on the server, containing session tokens. When a user requests a token, the server retrieves one from this pool. However, if an attacker uses their session token to change a victim's email, the server will grant access since the token is found in the global pool.

Example :-

-> POST /change-email HTTP2.0

XXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXX [email protected]&csrf_token=nnnnnnnnnnnndjdjdkgjgkjkej48

Note- When an attacker intercepts a request to change their email address using tools like Burp Suite, they may notice that a CSRF token is present in the request body. Since this token hasn't been used yet, it remains valid. Exploiting this, the attacker can manipulate the system to change the victim's email because the server only checks if the token has been used from the global pool, not if it's valid for the current session. This emphasizes the need for more stringent validation mechanisms to prevent such unauthorized access.

• CSRF tokens is duplicated in the cookie

Developers employ a CSRF cookie to mitigate the bypassing techniques mentioned earlier. This CSRF cookie holds the same value as the CSRF token. In a security mechanism known as "double submit," the web application verifies if the value in the cookie matches that in the token. If either value changes, the request fails. Even if the attacker uses their token, if it doesn't match the value in the victim's cookie, the request still fails.

Example :-

-> POST /change-email HTTP2.0

XXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXX

cookie: csrf_token=nnnnnnnnnnnndjdjdkgjgkjkej48 [email protected]&csrf_token=nnnnnnnnnnnndjdjdkgjgkjkej48

-> POST /change-email HTTP2.0 XXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXX

cookie: csrf_token=hello

[email protected]&csrf_token=hello

Note - Due to server only matches CSRF_Cookie with the CSRF_token value. in this server only check values instead of validity. so attacker only has to Send POST request with just changing Values of both Cookie & token to bypass the server.

There are so many different techniques to bypass CSRF but above mentioned techniques are most commonly used by attacker. as we know everyone thinks different in there own way.