People asking me, how I make so much submissions on one target.
The answer is easy: If you stick to a specific target, you will be able to understand the functionality in depth, and this knowledge provides you the opportunity to make the most out of a specific bug, since different endpoints means multiple reports.
Let’s get one easy example. We have a webshop application. There are two user levels: an administrator with all the privileges, and a low privileged user, with only an opportunity to log in the application.
You have just discovered that you are able to add a specific element with the low privileged user as well.
Happiness, you just found an IDOR. If you feel the rush, that you want to report it immediately, DON’t do this. Let’s make yourself a coffee or a tea, and give yourself some time to clear your mind. After the short refresh, sit back to your computer, and enumerate the whole functionality.
In our example, the IDOR you found gives you the opportunity to add a product to a store. You still not reported it! 🙂
When you look at the post request, you can see that the URI is “/api/v2/addproduct” with some parameters in the body, like “name”, “price”, “stock” and “manufacturer”. When the request is being sent, the webapplication sends you a 302 redirect HTTP response, and forwards you to “/shop/product?id=1”. Obviously, with the low privileged user, you won’t be able to view this entity, since you don’t have the proper rights to display the product. This information gives us the fact that all the products have a unique identifier, what is a simple incremental value (GG WP EZ)
Let’s check out, what can we do with the administrator! We arrived at the product’s edit page, where we can modify the parameters mentioned above. Catch the request with a proxy utility, when the administrator modifies the name of the product. The POST request is being sent to “/api/v2/productnameedit” endpoint with the body containing two parameters: “name” and “productID”.
Now replay the request with the low privileged user’s session identifier! Yeah! We got 200 OK! Second IDOR located. You will hate me, but don’t rush, wait with the reporting! Just store the information, and proceed with the other functions!
The next function, we can see with the admin is to modify the price of the product. Same situation like with the product name. Catch the request, observe the endpoint and replay with the low privileged user! The endpoint of the request is “/api/v2/productprice”, with a body containing “price” and “productID”. Awesome, third IDOR located!
Now, let’s drink some coffee and go on with the two other functions, discovered by the admin user at the admin panel: modify the stock and the manufacturer. We have the same process as in the case of previous ones. Catch, modify, replay and wait for 200 OK.
In the end, you have 5 IDORs to be reported just from one function, because you enumerated properly.
It’s important to mention that now you have to test these functions properly and try to reach the highest impact at all. Also don’t forget to do the classic tests for the input validation bypass and these stuff, because there is still an opportunity, that you can report an XSS as well on these requests. Yes, this will be the 6th report for today.
I hope, I could help you with these information, and don’t hesitate to contact me, if you have any question.
Happy hunting!
