Hello, my hacker friends and the whole security community out there. We have discussed a whole lot of random topics previously and we do guess that you people must have learned a lot from there. But today, we thought of doing something different and guess what, it’s the general request which we get from many of newbies in the pentesting field. Of course, experienced people won’t have any problems with it because there is no rocket science involved in it. Still, it would be a very good topic for someone who is just starting in this field. Nevermind, do give it a read and we are open to new suggestions and improvements, so feel free to give us a hand.

As for starters, if you have been regularly going through our blogs, you must have gone through the post on CSRF which we wrote earlier back in October. If you haven’t here is the link to the post. Read that before going through this post. Consider that the 1st post simply. So let’s get back to the point.

Why are we doing this? A blog post for CSRF PoC really? Actually, first let’s see what CSRF actually is.
If you have already gone through the various posts and videos on CSRF, then you must be knowing that Cross Site Request Forgery is an attack which can change the state of a request. It by no means can provide the attacker with your credentials unless it is a chained attack of XSS through CSRF(it’s a different topic though, so let’s keep it simple).

CSRF attacks are only possible for POST requests(though these can also be possible for PUT or DELETE, it’s quite tricky and we haven’t seen them for myself in quite a long time). And now if you are thinking why not GET? Then first read again about CSRF and for the simple answer a GET request is used for getting the resources back from the server, there is no way it can be used to change the state of the request. But for POST requests, for example, when you are adding something to an eCommerce cart or buying something, these are all POST requests. If vulnerable to CSRF, someone can add other items to your cart or change the credentials while you are about to buy something, there are many ways and yes even though CSRF isn’t in the list of OWASP TOP 10 for 2017, it’s not that all web applications have taken measures against it.
If you have gone through the first post, you must have read we are talking about some tokens. Anti CSRF tokens, the name says it all. Consider this anti-CSRF token as something which helps in verifying that the request is from a legitimate user and not a malicious request from an attacker sent on behalf of the user. Now once you have verified that these tokens are not being used in the correct sense, then you must have to write a Proof of Concept for that CSRF vulnerability.

For checking if tokens are not being used correctly, see the previous post and the part where we talk how to get sure of a CSRF vulnerability.

Now if you are checking for CSRF, you must be using a Proxy for that. It can be either Burpsuite or OWASP-ZAP. But since we have mostly been using Burpsuite, and we do think that most of the industry professionals do prefer Burp over ZAP, so we will be considering that you are using Burpsuite and write the different steps.
There are two versions of Burspuite, the free one, and the Professional one.

In the professional version of Burpsuite, we have a tool to create PoC for CSRF.

1. Just Right Click on the request and in the Engagement tools you will find Generate CSRF PoC as shown in the image below.

1. Now just copy the HTML and save it in a file with the extension .html.
2. After that, open the HTML file in the editor and remove the token part from it if you have verified that it’s not required.
3. Right-click the HTML file and change the value fields to anything which you like.
4. Save the file
5. Now right click the file and open with the browser with which you have logged in.
6. It will ask you to Submit Request, just submit it.

If after submitting the request, the values do change on that page of the application, then it’s simply vulnerable to CSRF, proved manually too. Now, this is all good if you have the Burpsuite Professional version.

Let’s see how to work around it if you are using BurpSuite free version or even ZAP. It’s quite easy to do so. Let’s see a sample CSRF PoC from Burpsuite Pro.

It’s not a valid PoC by any chance, it’s just a PoC we created from Burpsuite Pro. Now if you see it properly, it’s just a form and nothing else. You can get the input fields name and the different details by doing Inspect element in the browser or even by looking at the request in Burp. Just change the values inside the inputs and make sure that the form action page is the same as the URL of that page in the application. Again, save it as a .html file and open with the browser with which you have logged in and BOOM!. You will get a working PoC in less than 10 mins.

So we hope, you now know how to make a CSRF PoC, even without the help of tools. We think it will help you in Bug Bounties as well. Now, if you have any queries, feel free to ask us in the comment section.

Until then, keep learning and MERRY CHRISTMAS.!!!

‍