My Bug Hunting Journey with IDORs Part 2

This is Part 2 of my first write-up Part 1, If you have not read yet that then read it first. In this write-up, I will discuss with you about all various kind of IDORs which I was discovered during my research. I have categorized these with the base on their types.

Image for post
Image for post

Introduction :

Insecure Direct Object References (IDOR) occurs when a developer forgets to validate the objects-based user inputs, it allows a malicious user to access other user's data directly from the database server. This type of vulnerability considers as an Access Control failure. Insecure Direct Object Reference is one of the most common vulnerabilities. It is listed on OWASP TOP 10 2013 and 2017 (Merged with Broken Access Control) list.

Types of IDOR :

  • Common IDOR
  • Base64 based IDOR
  • GUID/UUID based IDOR

Common IDOR

This type of IDOR can easily detect to looking in the URL or body of the POST request. for finding IDORs you have to check all the parameters passing through the Post request or URL. Just modify the value of the parameter and monitor the responses of the application.

As you can see in the picture, a value 72001 passing in URL over GET request in the request tab and you can see the user details in the response tab.

Image for post
Image for post
User_01_response

As you can see, I simply change the value 72001 into 72007 and successfully retrieved other user details.

Image for post
Image for post
Victim_01_response

Base64 based IDOR

This type of IDOR is similar to Common IDOR but the parameter is passed in base64 format. For testing this type of issue you need to decode base64 first and after modification, encode into base64, and put into URL parameter. you can perform this action using Burp Suite. First, select the value and press Ctrl+Shiift+B to decode and Ctrl+B to encode.

As you can see in the picture that application allow downloading invoice through passing id parameter in base64 format.

Image for post
Image for post
User_01_b64_response

I was playing with the python language. I wrote a simple python script to perform encode and decode operation.

Image for post
Image for post
Image for post
Image for post
python script for decode and encode operation

As you can see in the picture. When I changed the parameter value to the modified value, I was able to download other user invoices.

Image for post
Image for post
Victim_01_b64_response

GUID/UUID based IDOR

This type of IDOR is difficult to exploit because of nature. The server generates GUID/UUID for each user that can not be predictable. to exploiting this type IDORs you have to create another account and swap the GUID/UUID. Many bug bounty program does not consider that type of bug as a security issue. Before reporting this type IDOR you have to find another endpoint where you can able retrieve other users UUID then definitely, it should be considered as P1.

As you can see in the picture, the application discloses user GUID in URL, but it's not possible to modify the parameter value.

Image for post
Image for post
User_profile

Log into another user account/create another account > copy that user GUID > Swap it. You can see I was able to access the victim profile.

Image for post
Image for post
Victim_profile

Endpoint for IDOR :

Always look at in id, uid, name, role, email, appid, invoice_id, and any CRUD(Create, Read, Update, Delete) operations. You must have to monitor all requests and parameters to detect IDOR while testing.

Reference:

Security Researcher | Bug Bounty Hunter

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store