Insecure Direct Object Reference falls under the category for Broken Access Controls as per OWASP TOP 10 (2017 Edition). This issue usually occurs due to weak implementation of the application’s access control logics which links an identifier or an object to a particular asset say user_id parameter defines which user’s data is to be updated. IDORs are compared to server-side issues, are widely observed, and easy to identify. However, often IDORs can be tricky and an application that looks very much robust might also have IDORs.

Hi fellow hackers and bounty hunters, I hope you all are doing good. After a long, I started back to look for vulnerabilities and recently encountered an interesting IDOR vulnerability which ended up as a Critical (P1) issue. In this blog, I will be discussing the same issue.

I started looking for issues on an old target’s subsidiary, let’s say targetsub.com
I logged into the account after 3–4 months so, upon successful login, it asked me to change the password as it’s their policy to rotate password every few months. On the password change page, the URL looked something like this:

https://www.targetsub.com/change-password/?id=90

Looking at the ?id= parameter, I tried to change values but no success. Later on, after changing the password with the normal flow, I logged in to the application and navigated back to the change password page.

Now, this time the URL looked something like this:

https://www.targetsub.com/change-password/

This time the ?id= parameter was not present. Now, it was a little strange for the application with the same endpoint to use two different flows. Next, I moved to my account page and the URL looked something like this:

https://www.targetsub.com/myaccount/

Further, I modified the URL by adding ?id= parameter with a value 88 and the new URL looked like this:

https://www.targetsub.com/myaccount/?id=88

Now, I was able to access the details of the user with id=88. At this point, I was able to change the email of the user. Further, I created another account and change it’s Email to attacker email. Now I can call a password reset link on the attacker-controlled email and without user interaction, I was able to perform a full account takeover.

Takeaways:

1. Always check all possible flows for every endpoint. Sometimes you may find an interesting flow that can be utilized elsewhere in the application.
2. Whenever you see /myaccount or similar endpoints with no reference to the user’s unique identifier, try to fuzz with the common identifier parameters like uid, id, user_id, oid, etc.