Other vulnerability types

Learning about Insecure Object Reference (IDOR)


What is an IDOR? An IDOR is simply 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. 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 tldr, being able to modify/view other users' info from simply changing one value (typically integer value)

Over my time as a bugbounty hunter i've reported countless idors resulting in ~250,000,000 details being leaked, and this post is designed to outline the process I use. 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 (public profile?) or look for patterns and see if you can generate your own & run it through burp intruder.

See some type of unique identifier (ID) in a request? Test it.

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. Sounds simple right? That's because honestly, it really is that simple. An API is designed to take user input (the users ID, https://api.example.com/user/123456), process & return information. One IDOR on an API will more than likely lead to lots more.

  1. Opt out links

    These sometimes just contain a userid arguement to opt out and will usually reveal the users emails. These can be found in emails they send you. Signup to all newsletters!

  2. Mobile Apps

    80% of my IDOR findings are from mobile apps. Most mobile apps use a simple API system to log the user in, display their information etc. A lot of API's just take a userid parameter and will usually reveal all their information to you, as shown above in the example. If you see some type of GUID then why not try a GUID generator, generate 10,000 & see what happens. Or if they look like they are encrypting/encoding it somehow then look for patterns. 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.

  3. Updating account settings

    Sometimes when updating your account settings, they'll send your userid as a parameter. Manipulating this can sometimes result in another users profile being edited. Don't forget that if one feature is vulnerable to IDOR then it may be a site-wide issue (and don't forget to check mobile site!). Even if you do not see your ID in the post data, just simply try adding it. id=, uid=, userid=, especially if it is a GraphQL query or JSON post data (if it's PUT).

  4. Reset password

    The same as above. Mongobug was able to do this on Uber but instead of a userID, he had to supply the users number. Not hard to obtain though right and earned himself a nice $10k, check it out here: https://hackerone.com/reports/143717

  5. Anytime you see some sort of indentifer

    This can mean a simple ID (1), or a guid (425d1126-4139-4067-ac68-d9caafdf2b46), or some other value. The key is to look for values which identifies you when interacting with the site/API, then to check if you can provide another users ID (your second testing account), and if yes, you have a bug. If it's something like a GUID then you should look for potential places it may be leaked on the site.

However with that said, don't just look for integer values. Perhaps to update your profile your username is used to validate who's to update, so simply trying another username you control will let you test for IDOR. To learn more about some common payloads i've used (and areas I found them in) you can check the useful payloads tab on the left.

Mobile Apps - These typically use some type of API and sometimes the requests will contain your userID. Change this to another ID you control. Don't forget to check in cookie values!

JSON Requests - Anytime you see a request and the postdata is JSON, {"example":"example"}, try simply injecting a new parameter name, {"example":"example","id":"1"}. When the JSON is parsed server-side you literally have no idea how it may handle it, so why not why? This not only applies to JSON requests but all requests, but I typically have higher success rate when it's a JSON payload.

Patterns - I once had a case where the users ID was a bunch of a-z characters. However the length was the same everytime and I noticed they re-used a set amount of characters. From this I was able to collaborate with another researcher and we were able to find 10 seperate endpoints vulnerable to this attack. IDOR right infront of everyone! The key thing to take away from this is anytime you see what appears to be an encrypted value, play with it!