How I Found an IDOR Vulnerability in a Public Program on HackerOne

Hello Everyone,

I hope you all are doing great. I am a cybersecurity enthusiast, and I have been in this field for the last few years, learning about different things and participating in CTFs on TryHackMe and HackTheBox. Sometimes, I try bug hunting as well. I am also an undergraduate student in software engineering, so I try to manage my time and do bug hunting whenever I can.

In this blog post, I will talk about an easy-to-find vulnerability known as IDOR.

Understanding IDOR (Insecure Direct Object Reference) Vulnerability

IDOR, or Insecure Direct Object Reference, is a common and serious web application vulnerability. It happens when an application exposes its internal objects, like files, directories, database records, or key values, through user inputs. This allows attackers to change those inputs and access data they are not supposed to see.

In simple terms, imagine you have a locker with a number on it. If you know someone else’s locker number, you can open their locker and access their belongings. This is similar to how IDOR works in web applications. When user input is not properly validated, an attacker can change the reference value and gain access to data they shouldn’t see.

In simpler words, you can just change the id=123 to id=124, and if the endpoint or web app is vulnerable to an IDOR attack, you will get the other user’s information back.

I hope you have gotten an idea of it, so now let’s get started.

I saw a new program on HackerOne, so I tried to hunt on it. I created two accounts so I could test for IDOR or broken access control vulnerabilities. The reason behind creating two accounts is that I can play around with options like PUT and DELETE without harming any real users on the web application, allowing me to test these options too.

I opened Burp Suite and started crawling the website, testing every functionality I could, and the requests were generating in the background. After surfing through the website for quite some time, I thought to check the requests.

Upon checking, I found an interesting endpoint:

GET /example/152131482/user_stats/?page_locale=en HTTP/2
Host: api-gateway.example.com

I have written “example” instead of the website name as I don’t want to disclose the website name.

In this request, I was able to see other user information that shouldn’t be visible to other users, including their order_numbers, account_age, pro_user status, and other related information.

I tried changing the user ID to my other account and was able to see that account’s information too. However, when I tried changing the last digits of the number, like from 152131482 to 152131483, I got a “user not found” error.

This happened because the ID followed a specific pattern. Therefore, I needed valid user IDs to proceed.

In this case, I had two options: either I could brute-force it to see other user information, or I could see if the user IDs were leaking somewhere. Since I had already surfed the website, I decided to check other requests.

Upon investigating, I found a product page where different users had commented. By intercepting and analyzing the response, I was able to see the user IDs of every user who commented on that product page.

As you can see from the images below:

So now I got the user IDs and the vulnerable endpoint, which I already had. When I changed the IDs in the above endpoint, I was able to get their information too. So, I wrote a report and submitted it with full details and a video POC.

And I got this response:

I was expecting it to be something like that because of my previous experience in bug hunting, as it is very competitive right now. But it was a nice experience.

I hope you learned something from this blog post.

Happy Hacking!