Hey guys welcome to my blog so today we are going to discuss about CSRF protection bypass and in previous I discussed about CSRF attacks and finding CSRF vulnerability so please check out the below article

What is CSRF: https://evilox.medium.com/explanation-of-csrf-cross-site-request-forgery-bc6a5042bcbf

Finding CSRF: https://evilox.medium.com/unmasking-basic-csrf-bug-hunter-5003dbe44466

As websites implement stronger security measures to combat CSRF attacks, the need for understanding the techniques used to bypass these protections becomes crucial. This article delves into the evolving web security landscape, shedding light on the ongoing efforts to break through modern CSRF defenses. Furthermore, it goes beyond theory by providing practical demonstrations using PortSwigger’s lab environment. By exploring the challenges faced by both attackers and defenders, we can gain valuable insights into CSRF protection bypass and fortify our defenses against this persistent threat.

What is a CSRF token?

CSRF token is nothing but a unique secrete key generated by the server-side application and shared with the client to protect from the CSRF attack

And if the client does not provide the CSRF token correctly it will reject the request

CSRF_Token=80FassfjkddmmOhi9M9wyna8tadnsaak3ODOR8d6u

If the implementation is Correct it will protect from CSRF attacks but if it is not it can be bypassed using some of the techniques so let us discuss

Here we are solving the portswigger lab

Some of the applications correctly valid the token based on request if it POST it is valid but when we change it to GET it is not valid it one of the common flaws in the many application

So first go to the lab and sign up with credentials and there you can able to see the Change email ID functionality

So update the email ID and capture that request and next send to the repeater

Next change the request method from POST to GET in burpsuite

Using the CSRF POC generator you can able to draft the payload or try to draft the payload manually using the previous article

Next, remove the CSRF token (but it is not necessary for this challenge)

In real time you need to load this HTML file on the browser for the report but for this challenge, there is an exploit server so open that server and paste it into the body section

Next store that exploits and deliver to the victim

Now the lab get solved

Lab: CSRF where token validation depends on token being present

In this lab, the application has a proper CSRF token but it not validating when the user removes that token

Here you can able to see the CSRF token so just remove that token

Next draft the payload for CSRF using the CSRF POC generator and copy and paste that onto the exploit server

Now Store that exploit and deliver that exploit to the victim

And Lab gets solved………….

CSRF where token is not tied to user session

In this lab, they have given the two accounts to bypass the CSRF protection but here you can able to use the CSRF token for one time only, and the same email id will not accept

First login to the two accounts in the normal window

Incognito window

In any account Update the email and capture the request with the CSRF token

Next, generate the CSRF POC using Burp and copy and paste it into your local file

Open with incognito with another account and now you can able to notice that email-id will get changed

Using this you can able to confirm that there is CSRF vulnerability exist

so to solve this the Lab copy and paste the payload into the exploit server and store and deliver the exploit to the victim

Note: you need to use the fresh CSRF token and Mail ID which is not already used (if want this do the process again)

So now your lab gets solved…………………………

I hope you will understand this article if you like this please give applause to this article which will motivate me lot and follow up evilox for more updates