Hello guys, I am back again with another writeup on my very recent bug finding on HackerOne Private VDP. In this writeup I am gonna tell you about how I bypassed an IDOR vulnerability and in the end also gonna share some other methods to bypass it so stay tuned.

IDOR is not always about changing the id parameter as there are various ways we can find that vulnerability, but most of us just try to change the ID parameter and after getting 401 (unauthorized access) and other errors we give up and move to other functionality. But that’s a wrong approach, try to give some time to the same bug, do some research on google and try to exploit it. Now without any further delay let’s start with the main story.

GET SET HACK

On August 4, I received a private VDP invite on HackerOne with a limited scope. It was kindda sports platform where we can create a team for a particular sports which allows us to add members and manage our team as a coach. I started with some recon and subdomain enumeration but didn’t found any intresting subdomain or any endpoint. Then I moved for manual walkthrough on the main domain of the website and started testing for some bugs like CSRF and XSS but got no luck. After that I saw an intresting option called “Retire Team” under Team settings option.

I decided to play with this functionality and fired up my burp. The request I saw was something like:

POST /account/teamsetting/retired_team?team_id=12345

My mind was shouting out loud “IDOR IDOR IDOR IDOR”. I immediately created a victims account and create a victims team, changed the victim’s team id in place of attacker’s team id but the response in my burp repeater was not in my favour, It showed me Unauthorised access error, there I didn’t give up and move on, Instead I did some research on how to bypass it and found some intresting ways and started trying them out, One of which got me a 200 OK response which eventually leads to retire team of any user. What I did was put %20 in the end of id parameter like:

POST /account/teamsetting/retired_team?team_id=victim’s_id%20

I was happy and excited at the same time as there was no rate limit an attacker can bruteforce the team_id parameter and mass retire the team’s of many user.

Reported the bug and waited for the response of the triage team. After 6 days they hit me up saying…

Marked Duplicate 😡😡

1. Parameter Pollution

By supplying multiple values for a single parameter, one may create a scenario where idor can be exploited. Change request from:

GET /api/card?custom_id=<attacker_id>

to:

GET /api/card?custom_id=<attacker_id>&custom_id=<victm's_is>

2. Appending special characters and random strings

Simply replacing ids might get you a 401, access denied or invalid request. So, in this case appending special characters (/) or strings such as %20, %09, %0b, %0c, %1c, %1d, %1e, %1f etc. might give you an Idor. Turn request from

GET /profile/update/12345

to

GET /profile/update/12345%20

This may break the application’s logic.

3. Changing the request method

If one HTTP request method doesn’t work, you can try plenty of others instead: GET, POST, PUT, DELETE, PATCH, and so on.

4.Placing ids to requests without ids

Even if the request URL is not using input parameters, place parameters to each request and observe whether it is making any difference. For example, if this request displays all your card details:

GET /api/card

What will happen if the attacker appends the user id as mentioned below?

GET /api/card?custom_id=<victim_id>

Even if web applications sometime hide information related to parameters, by observing the adjacent requests, you can add ids randomly.

I have decided to give back to the hacking community whatever I have learned so far, I will be actively controbuting with these kind of writeups so make sure to follow me.

Let’s be friend’s, feel free to connect with me and if u guys have any doubts or recomendation my DM’s are open.

Follow me for regular updates on Bug Bounty and cyber security.

>>>>>>>>>>>>>>>>>LINKEDIN<<<<<<<<<<<<<<<<<

>>>>>>>>>>>>>>>>>TWITTER<<<<<<<<<<<<<<<<<