Hey guys, in this tutorial, we are going to move towards the next vulnerability of OWASP TOP 10 which is IDOR “Insecure direct object references“vulnerability. Insecure direct object references are a type of access control vulnerability that occurs when an application uses user supplied input to access object (server), such as fa file, directory or database key directly. Now in this tutorial we will talk about almost everything related to this vulnerability such as: exploitation, mitigation, etc.
Lets take a Look 🙂 !!
What is IDOR Vulnerability ?
As we have already discussed about that the IDOR “Insecure direct object references”vulnerability aries when an application provide the direct access to the object of user-supplied input without identifying the input validation. If the web application is vulnerable to this vulnerability, the results may be comes very dangerous as the attacker can bypass authentication and take over the accounts of the users. Now we will move towards exploitation from where you come to know about this vulnerability.
IDOR ( Change Secret )
We’ll use the bWAPP vulnerable web application to demonstration this vulnerability and for the web application lab setup you can visit here. Below is an input field from which we can change the current user’s secret key.
Understand the first scenario that what are we going to do ? There are two users in the database whose secret keys you can analyze through the image below. We have already changed the secret key of user “bee” to “123“, since we are a login with user “Bee“. But we do not have any rights to change the secret key of user “A.I.M” that we will do through this vulnerabiltiy. Excited ? lets do it 🙂 !!
Now only we need to change the username and even we can change the secret as per requirement. Below you can see that we have changed the username “Bee” to “A.I.M“.
Wait 🙂 The secret key has changed successfully but let’s see what happens in the database.
Nice 🙂 As you can see the secret key has also been changed in the database.
🙂 !! When we analyze the source code, we found that there are no restrictions available in it even the user input is directly executed in the database without knowing the validation.
IDOR ( Tickets )
Ordinarily such various websites available from where we can buy or book tickets for our trips or tours. But sometimes such websites are vulnerable to these vulnerabilities due to which the attackers take advantage of them. similarly we will take same scenario with the help of bWAPP vulnerable application. Below you can see that the per ticket costs is 15 EUR.
We are using the burpsuite tool to manipulate the request. Now we enter the number of tickets and intercept the request.
Just not much, we will change the price per ticket to 1 EURO and send the request of the server.
DOne 🙂 “Thanks for your order” !! as you can see, we have successfully booked 15 tickets in 15 EUR by changing the price of ticket.
Now we are going to use WebGoat vulnerable web application to explain more about this vulnerability. Now we will just follow the instructions and do what is mentioned in the image. For this purpose we will use the burpsuite tool, so prepare yourself and intercept the request by clicking on the profile option.
After clicking on the profile option we intercept the request which will appear as shown below. Now we’ll send request to the intruder tab and identify the response.
Hmm:) !! We received an error after forwarding the same request, so we just remove the URL encoded value from the URL and you can see that we have successfully received the profile information of the user “Tom Cat“.
When we login with another account we found that there is not much difference between the two user IDs, hence we can perform brute force attack in order to grab another profile information. Now we come back to the intercept tab.
Here we’ll select the payload type and location for brute forcing attack.
As we analyze there are changes in the last two digits of the userID, hence we’ll select the numbers from 00 to 100.
Boom 🙂 At the last we got success and as you can see that due to direct object reference we have successfully get the profile information of user “Bill“.
This will be the final scenario in which we will show you how attackers change users’ reviews and comments through such vulnerabilities. We are using the juice shop vulnerable application through which we will demonstrate this attack. Below you can see that the first user review is something that we will replace bad reviews. Prepare the burpsuite tool and click on the like button of the first review.
We need a userID of the first reviewer for which we have clicked on the Like button 🙂 !! As you can see in brupsuite.
When we check the available HTTP methods for the confirmation then we get the PATCH HTTP method which is enabled. Now we will try to manipulate the message through this HTTP method.
Ok 🙂 Sounds good ! but we first check that the message has been successfully changed on the web application as we see in the burpsuite tool.
Really 🙂 We got success and you can see that this message is visible to everyone, which we changed through the burpsuite tool.
Mitigation
- Should be check user input before using it.
- Validation of Parameters should be properly implemented.
- Application should perform a Syntactic Validation to verify suspicious inputs
A keen learner and passionate IT student. He has done Web designing, CCNA, RedHat, Ethical hacking, Network & web penetration testing. Currently, he is completing his graduation and learning about Red teaming, CTF challenges & Blue teaming.
