These days bug bounty hunters have been finding many low-hanging fruits and a lot of them want to go beyond those bugs. This blog is for those who want to find some well-paid bugs which need a little more observation and time. I have put my methodologies and ideas to find them, and you might want to learn a bit of JS and scripting to find them as well. Let’s dig into it:)

I will put 5 bug/bug types that you CAN find if you observe requests/responses well and these bugs can help you a lot in paying your bills. I have found a lot of them, and I still look for these things when I get into any application. Here are the bug types: -

• IDORs
• Stored XSS
• Internal SSRFs
• Account takeovers
• SQL injections

💎 IDORs:- Everyone looks for IDORs but I’m quite sure more than 80% of people are just looking for numerical values. However, IDORs are more than “?id=12345”. For IDORs, you need to observe every value which can give you a different result if we change it. For example, a normal parameter could look like this:-

?user=somesusername

OR a JSON request could look like this: -

“email” : “[email protected]”

Here, what we can do is we can change the username to admin and try if we can get some information for the admin. In the second case, change the email address to [email protected] and you might get the results for admin. I had a similar request where I could view the email address and SSN number for all the users admins had created just when I changed the email address to [email protected]. My payout for this bug was around 1200 USD.

💎 Stored XSS: - Here, I am not talking about a classical Stored XSS where you can store a comment in the comment section and get a popup for all users. If you observe closely, you could check all the functionalities which store data and show them to all the users. You can think about a lot of scenarios that could lead to stored XSS and due to their impact, usually, payouts are great. In my case, I had a stored XSS where I could send the payload as a broadcast message to every person since I was an admin and whoever gets the message, gets an XSS. On Synack they paid me $980 for this one. Also, you can check for stored Dom-based XSS which are rare but can be found if checked properly.

Check this code:-

Here, if a website is using the same functionality and it is getting stored on the server-side, we can go ahead and try stored Dom XSS. You can check this lab from Portswigger as well: - Stored Dom XSS.

💎 Internal SSRFs:- Internal SSRFs are usually high-paying bugs if you can show them some critical things apart from port scans. There are many ways to find internal SSRFs. Some things which I check is uploading some images kind of stuff where if the data is going through some location URL, I can try mine and check if I am getting the pingback. Also, PDF converters are a valuable resource to generate internal SSRFs. Basically, we try to find out all the locations and see if we get any responses there, either on our servers or collaborator servers.

Also, we can check them in headers as well. Sometimes we add an external header for eg. X-Forwarded-Host and assign it the collaborator payload. These are a few ways you can check for them.

💎 Account takeovers: - There are many ways you can do an account takeover and as the name says, you can assume it will be a high-paying bug since you are owning someone else’s account, and this is a clear business and PII loss. We have a lot of blogs on account takeovers so a quick view on some mostly used techniques for account takeovers: -

• Privilege escalation
• Password reset
• Security misconfiguration
• Broken access control
• Broken authentications

There are many more ways, but these are some of those which can be used to check account takeovers.

💎 SQL injections: - SQL injections have been always on the checklist for every bug bounty hunter since you can directly get into the database and fetch information from it. So, if you haven’t started looking for it, start doing it. I once had 3 SQL injections on the same program on Synack and each of them got accepted for around $3k. So, you always get paid well for SQL injections. However, these days you won’t find a lot of error-based SQL injections, but time-based ones are still there, and people are finding it a lot.

For time-based SQL injections, you must check every endpoint carrying a value and try your time-based SQL injections there. It could be anything where your payload can fit in. So, keep an eye on endpoints and parameters.

You can always try Portswigger labs for SQL injections and trust me those are super helpful for a start-up flyer.

All these bugs, which I have mentioned, are available to find in every app and the newer features and code implements come, they arise a lot in them. The only thing you need to do is to spend a lot of time observing them and you might end your week/month on a high note:)

This will be it for this blog and I hope you get something from it. If you do, share it with the community and let people learn something as well. I will put resources I have used in this blog so that you can go ahead and check them out.

Happy hacking!

Peace:)

Portswigger SQL injection labs: Click here

Understanding DOM for storing data: - Click here

Stored Dom based XSS: - Click here

Hackerone reports for account takeovers: - 1, 2 and 3