Hi, I hope you’re doing well. In this article I am going to illustrate few different type of CSRF attacks.


© veracode.com



To start with, A CSRF attack forces a victim who is authenticated in to forward a request to a vulnerable web application, which then executes the requested action on the victim's behalf without the victim's knowledge or consent.

At a glance, to find CSRF vulnerability I always look for a functionality where as user info can be changed. Three major functions to focus while looking for CSRF issues. 

  • Create
  • Modify
  • Remove 

Always look for a function where these certain things can be done. 


Conditions

One thing I scare of when it comes about CSRF vulnerability which is Bearer authentication (also called token authentication). As the user must send this token in the Authorization header when making requests to protected resources, CSRF will not work here. To be more specific if the Bearer Token doesn’t require as authorization we can give a try for CSRF issues without any hesitation. 

Chaining with HTMLi/XSS will make your CSRF finding more impactful and easy to exploit.

Additionally, in order to determine which user made the request, the application must depend on the session cookies. There shouldn't be any additional security measures, like 2FA, in place to check user requests.

Samesite cookie attribute is important to understand in terms of CSRF attack. I would recommend to have a look at https://portswigger.net/web-security/csrf/samesite-cookies


Exploitation

My all time favorite techniques to find CSRF vulnerability. 


1. Bypassing CSRF token (blank)

A lot of modern applications use CSRF token in post body in order to protect actions and prevent such issues. But removing the CSRF token (i.e., sending empty value in the POST request, Email=eternyle@azizhakim.com&CSRFtoken=&Submit) may bypass the CSRF protection. 



2. Bypassing CSRF token (removing the entire parameter)


As like as token empty method, removing the CSRF token parameter with value (i.e., sending without whole CSRF parameter, Email=eternyle@azizhakim.com&Submit) may bypass the CSRF token which presents in the POST request.



3. Changing request method from POST to GET

Alright, let’s assume we have a function like “User Profile Information” to test CSRF vulnerability. To modify my own account’s information, a POST method is presented along with CSRF token. 


Now simply right click on Burp Suite and then click on “Change request method”. The request method will be changed also parameters with value will be included in the GET request. screenshot If this GET method works without CSRF token, bingo you’re good to go!



4. Modifying token value

Always try to modify token value, you never know if it turns out real for another user.


5. Sitewide token

You never know if the CSRF token in POST method works "sitewide" for all the authenticated users. Don't forget to try USER-ABC token for USER-XYZ.


According to me, HTTP request method is one of the game changer when it comes about CSRF attacks. Never hesitate to test such way. For example, If it's a PUT/DELETE/POST method, just change it to "GET" method and make sure include the parameter with value if it requires.


To conclude If you're lucky you may get a way to bypass but for being lucky you got to try.