How do you actually find bugs? (My 2 year experience)

This is just a brief intro into a book I am writing regarding how do you use the knowledge you got from teaching resources and how to apply all of it into finding your first bug. Keep in mind that this book is currently in writing process and will be out soon so I recommend you follow me on Instagram https://instagram.com/dead0verflow or follow me here to get an email once it is out. Some you who follow me will be having the book for free so make sure you do follow me. The price will be something like $1.99 just so that I get something from putting time into it, I don’t actually need that money. So with that said, Let me show a small intro into a short book I am writing! Quick note that I will be using actual vulnerabilities on actual targets I found to showcase my methods in this book just so you can rely that my methods work!

I will be explaining how to hunt for bugs and explain methods I use to find them. Here I will be explaining my method for CSRF hunting since it is a bug most of you are familiar with. In the book there will be a lot more like XSS, IDOR or even WebSocket vulnerabilities you can hunt for!

So lets just start!

CSRF — Cross Site Request Forgery

I will do a brief explanation of every vulnerability just to remind you in case you don’t have a clear vision or you just forgot.

Cross-Site Request Forgery (CSRF) is a type of security vulnerability that occurs when an attacker tricks a user’s browser into making an unintended and unauthorized request. This usually happens when a user is authenticated on a website, and the attacker can exploit this trust to perform actions on behalf of the user without their consent.

The way I exploit CSRF is really simple and I love to hunt for these vulnerabilities because it is really easy and almost every time, my method, yields me a vulnerability.

So, you have found your target, in my case, my target will be some random website.

Firstly, when you are on your target website, you should open up Chrome developer tools by pressing F12 or Right-click and click Inspect or CTRL+Shift+i.

After you have opened the developer tools, navigate over to Network tab. This tab is responsible for any HTTP requests that are being made on your target website.

Then just start playing around with the website. This website is a chat based website so lets try to send a message. When I try to delete a message, this request has been made to the target website’s API.

If you click on the request you can see what has happened.

I blurred out the domain just to protect the identity of a website.

Now you can test to see if you can send messages on behalf of other users via CSRF vulnerability. Right click on the request, click Copy and then click Copy as fetch.

Now lets test to see if there is a CSRF vulnerability.

Go to another website, I recommend you go to example.com and open again developer tools but this time navigate over to the console tab.

Now I will paste what I have copied earlier in the console.

However, you might see mode property here. Make sure the mode property is set to no-cors. Also make sure the cridentials is set to include

Now just hit enter and see what happens.

As you can see, this request has failed, meaning this website has proper protection against requests that are sent from another domain, in my case from example.com.

So what now? I didn’t find a CSRF and should I stop looking for them? I mean this website probably has protected every API endpoint, right? No! Always test for more. I will now see if I can add a message reaction like a smiley face or sad face from another domain. Lets test that out!

So I will make a message reaction on this website and there is a HTTP request made.

I will again click Copy and Copy as fetch, go to example.com, set mode to no-cors and try sending the request.

Now I will hit enter to send this request from example.com.

Notice how there is no error showing up. Let me switch to the network tab to see if the request received a 200 Status code.

As you can see, this request was authorized and now let me check if I added a reaction to a target message.

And sure enough, I did!

This is a CSRF vulnerability where an attacker can create an exploit website which once the victim visits, it will automatically send a message reaction request to a certain message and add a reaction on victim’s behalf to that message if the victim is logged in.

The console tab executes code as if it was executed on a page where the developer tools are opened. So, this just means the example.com sent an authorized and authenticated request to add a reaction to a whole different website and it worked. You can now try different things for example updating profile information then see which request did that in the network tab, copy it, go to example.com, open console and paste the request, change the mode to no-cors and try sending it from example.com. If it works, then you found a vulnerability, if it doesn’t then look for something else, just like I did.

I did report the vulnerability but it got closed as informational since it isn’t a high priority bug however, using this technique, I found another CSRF on this website which was far more serious than this one. That vulnerability is currently being fixed.

Hopefully this briefly summarizes how I hunt for CSRF vulnerabilities and hopefully you will learn something from this. If you have any questions, you can reach out to me via email ihusanovic3@gmail.com or on Instagram @dead0verflow https://instagram.com/dead0verflow

I will be answering any questions you may have!