Finding a Unique Kind of IDOR

Good day fellow Hackers, today I wanted to share an interesting kind of IDOR that I found recently during my VAPT assessment. I hope you learn something new here.

I was doing VAPT of a web application, it had two different URLs. Due to privacy concerns I have censored the images and URLs of the application.

First URL: [Let’s assume this URL to be https://dashboard.example.com/]. The application is about creating your own applications which will be compatible with mobile devices as well using the inbuilt templates.

Second URL: [Let’s assume this URL to be https://store.example.com/]This application allows your creating application from First URL to over this URL.

So, as a creator we can create our Mobile Applications on dashboard.example.com and then host those applications on store.example.com.

This IDOR is divided into two different parts, the first part includes the collecting the user IDs from the application and second part is to fetch the sensitive data of the users by supplying the user IDs.

Here, the user ID is not guessable like numerical value, usernames or email rather it is a kind of hexadecimal value of 24 characters in length.

Now we have to gather or enumerate as much user IDs we can.

While testing the store.example.com, I found that the user IDs of user who uploaded this Mobile application is returned via API call. So, from here an attacker can gather all the user IDs of users that have uploaded the mobile Applications on store.example.com.

User clicks on details for a particular application.

The back-end API call for this details looks like:

The user ID of the user who uploaded this Mobile Application is reflected in the response.

Now, we know that we can get all the user IDs that are present on store.example.com.

On the dashboard.example.com, the scenario is like the user creates the account and then he can create the applications here and that can be further hosted on store.example.com.

While testing on dashboard.example.com, I got this URL https://backend.example.lk/auth/getAppCreator/{userID} in burpsuite and returns sensitive information of the user like username, password in the bcrypt encryption, phone number, email, etc. are returned in the response.

Firstly I thought, this only returns my information as I was logged in to the application, but that was not the case. The application returned the same response in the incognito window as well. So, an attacker doesn’t even needs to login to the application. He can just enumerate the user IDs in the application and then get all the sensitive data of the users by just entering the gathered user ID in the following URL:

https://backend.example.lk/auth/getAppCreator/{userID}

We have gathered all the user IDs of the users from the first step and we got an sensitive URL from second step. So, now to complete the IDOR vulnerability, we have to merge these two steps and gets the sensitive data of the users.

I hope you learned something new from this blog. If so let’s connect on LinkedIn, Twitter.