Test your knowledge with BugBountyHunter Challenges


Resources

A list of useful websites, blog posts, reports tools to help you.

Learning about Insecure Direct Object Reference (IDOR)


What is an Insecure Direct Object Reference? Imagine the URL https://api.example.com/api/user/139349 - in which you supply the endpoint with a userid/guid, or some sort of identification and it'll execute & respond. In this case, it's looking for userid 139349. An application that is not vulnerable will not let you change 139349 to another users ID, but if it is vulnerable, the IDOR bug would enable a malicious user to enumerate https://api.example.com/api/user/x & leak users information. So the simple version is, being able to modify/view other users' info from simply changing one value, typically integer value, is an IDOR.

IDOR's exist because of a lack of access control. The developer is not validating you are that USERID and they are happy to allow for any ID supplied. This can result in editing, viewing and destroying information you do not own. Your goal when looking for IDORs is to achieve either of the three.

Over my time as a bug bounty hunter i've reported countless idors resulting in ~250,000,000 details being leaked. IDORs can exist throughout the entire application so it is always suggested that if you see IDs then to always test, even if they are guids or some type of "encrypted id". Look for potential leaks of this ID such as public profile, posts, or look for patterns and see if you can generate your own & run it it through a tool such as Burp Suite's intruder. I once had a case where a certain set of a-z characters were used and I was able to mass-generate valid IDs from a simple script.

Finding IDOR's

IDOR bugs exist in more places than you think, especially on mobile apps! Mobile apps will typically query an API with a users ID and this ID can be manipulated to view any other users' information. An API is designed to take user input such as the users ID, https://api.example.com/user/123456), and process & return information. The endpoint should ensure that the user ID being supplied is actually you but in a lot of cases you will find there is no validation.

Be mindful that one IDOR on an API will more than likely lead to lots more!

Below you can find some common areas you may discover an IDOR vulnerability

  • Look for integer values and test!

    Look at the feature you're testing and what it does. Imagine you are querying for sensitive order information and the request is https://www.example.com/order?order_id=1337. Changing the ID to 1338 will reveal another users order! A great report and finding on this can be found here from our Hackevent: [IDOR] Modifying anyone's Appointment information

    Anytime you see a request and the postdata is JSON, {"userid":"1", "password":"oops"}, always try modifying the userID. In a lot of cases you will discover it is vulnerable. As well as this, you can simply injecting a new parameter name if the userID isn't provided! Before: {password":"oops"}, and after: {"password":"oops","userid":"1"}.

  • However..

    However with that said, don't just look for integer values. Perhaps when updating your profile your username is used instead to validate which profile to update, so simply trying another username you control will let you test for IDOR.

Another simple test, -1 !

This is mentioned on the SQL injection page but is also revelant here. Simply trying -1 can sometimes uncover a vulnerability. Imagine the request is:

	
POST /updateUser
Host: example.com

user_id=1338&name=test
	

If you were to provide user_id=1338-1 and it was vulnerable, then the code would execute against user_id=1337. The code

$sql = "UPDATE users SET name='test' WHERE id='1338-1'"; will be executed as being user id 1337