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.
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.
As you can see, I simply change the value 72001 into 72007 and successfully retrieved other user details.
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.
I was playing with the python language. I wrote a simple python script to perform encode and decode 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.
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.
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.
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:
