IDOR tutorial hands-on – OWASP Top 10 training

Hello ethical hackers and welcome again to this OWASP Top 10 training series. In this hands-on IDOR tutorial, you will practice what you’ve learned about the IDOR vulnerability we explored earlier. Specifically, you will leverage IDOR to:

• Access other users’ data using simple IDs and UUIDs
• Impersonate other users
• Hunt for hard IDs
• Delete other users’ data

If you don’t know what id IDOR, RESTful APIs or HTTP methods, I highly recommend you read the previous article. That way, you will take full advantage of this IDOR tutorial.

I will be releasing new similar hands-on tutorials to help you practice security vulnerabilities. Make sure you stay up-to-date by subscribing to the newsletter below.

Leverage IDOR vulnerability to affect Confidentiality

In many IDOR cases, you will compromise the confidentiality of other users’ data by accessing other resources. In the following IDOR attack examples, we will explore how to do that in two ways.

Juice shop IDOR challenge: Access other users’ baskets

Let’s start with a simple challenge to get you started. In this simple IDOR tutorial, the goal is to access other users’ baskets. 

1. Make sure OWASP ZAP or Burp Suite are properly configured with your Web browser.
2. Login to OWASP Juice shop and add some products to your basket.
3. When you list the content of your basket on the top-right corner, you should capture the request GET /rest/basket/ID-OF-YOUR-BASKET in your Web Proxy.
4. Let’s brute force the basket ID since it is a simple Integer. You can do this using Burp’s Intruder or ZAP’s Fuzzer. In the video tutorial, I am using the latter. 
5. Using a range of Integers between 0 and 50, we successfully accessed many baskets.

WebGoat IDOR challenge: Hidden endpoint

In this IDOR attack example. Our goal is to access data of other users using an endpoint which is not easily exploitable. In fact, we will infer the vulnerable endpoint from what we will see in the Web Proxy.

1. Make sure OWASP ZAP or Burp Suite are properly configured with your Web browser.
2. Login to OWASP WebGoat.
3. Go to the Broken Access Control menu, then choose Insecure Direct Object Reference. Then, choose challenge 2.

4. Login as the user tom with the password cat, then skip to challenge 5.
5. Click on the first View Profile button

6. You should capture a request GET /WebGoat/IDOR/profile/%7BuserId%7D  in your Web Proxy. Note that the structure follows the REST convention (profile/id)
7. Since this is a RESTful API, when you remove the ID part and replay the request. You should get your own profile data. Note your userId for later.

8. The userId seems to be a simple Integer. Let’s try to brute force the last digit. Maybe we will get access to other users’ data. You can do this using Burp’s Intruder or ZAP’s Fuzzer. In the video tutorial, I am using the latter.
9. You should be able to access Bill’s data with the user id 2342388

Compromise Integrity using IDOR vulnerability

If a feature of the application allows you to modify data and it’s vulnerable to IDOR, you will be able to edit arbitrary resources. Furthermore, even though some IDs are hard to guess, you can hunt for them inside the application. In the following IDOR attack examples, you will see this in action.

Leverage IDOR vulnerability to impersonate other users

In this challenge, the goal is to post a review of a product as another user. 

1. Login to OWASP Juice Shop.
2. Select a product and add a review while capturing the HTTP requests.
3. In your Web Proxy, you should see a request similar to the following

4. Note how the author field contains the email of your account. Change that to another user. For example, superadmin@juice-sh.op
5. Send the request and verify that the comment has been added as the impersonated user.

Hunting for hard IDs to achieve an IDOR exploit

In this challenge, our goal is to modify a review of another user. Let’s do that! 

1. When you list reviews of the banana juice product, you can see Bender’s review.

2. If we want to edit an existing review, we need to see what the HTTP request looks like. Let’s add our own review and edit it.

3. Sadly, it seems that the id is hard to guess. If we want to edit Bender’s review, we will have to hunt for his review’s ID. 
4. Looking through the HTTP requests on your Web Proxy, you should spot a request which lists all reviews. Have you found it? It should be similar to GET /rest/products/6/reviews. And the response gives us the missing piece of the puzzle.

5. Let’s take the highlighted _id parameter from the response above and repeat our previous review edition PATCH /rest/products/reviews request.
6. You should now have changed Bender’s review comment.

Unauthorized data deletion using IDOR vulnerability

The impact of Insecure Direct Object Reference depends on what the vulnerable feature does. Sometimes, you can’t find it using normal browsing. To increase your chance of finding hidden IDOR vulnerabilities, you need to play with the RESTful requests you already collected. In this case, we will delete all customer feedback entries from the Juice shop store.

1. Login to OWASP Juice Shop. Then, go to the menu on the top-left corner and send a customer review.
2. You should see a request similar to the one below

3. There are few things to note here. Firstly, we have a POST request to the feedback resource, which uses a captcha id and its corresponding value. In the response, we have the id of the resulting feedback, which is a simple Integer. 
4. Although there is no feature available for us in the UI for deleting a customer feedback, we can still tamper with the request to see if the RESful API allows to delete feedback. Let’s change POST to DELETE, append the feedback ID and remove the POST data.

5. We have successfully removed our own feedback. 
6. So far, the API accepts to delete our own feedback. But what about deleting other users’ feedback? It seems that we can reuse the same captcha id and value in our malicious request, which will bypass the captcha protection. The idea is to iterate over the feedback ids and delete all of them. I leave this for you as a final exercise.

That’s it! You’re now ready to find IDOR vulnerabilities on your own. If you enjoyed learning with this article, make sure to share it with your network and subscribe to the newsletter to have fresh content delivered to you once it’s available.

Again, here is the IDOR walkthrough video: