In Depth: Insecure Direct Object References (IDOR)
[InDepth#11] Also known as hide-and-seek, and security through obscurity!
What is a Insecure Direct Object Reference (IDOR) vulnerability?
Insecure Direct Object Reference (called IDOR from here) occurs when a application exposes a reference to an internal implementation object. Using this way, it reveals the real identifier and format/pattern used of the element in the storage backend side. The most common example of it (although is not limited to this one) is a record identifier in a storage system (database, filesystem and so on). IDOR is referenced in element A4 of the OWASP Top 10 in the 2013 edition.
The term IDOR became common when OWASP included it in the 2007 Top 101. It stayed for the 2013 release, and was merged into Broken Access Control in the 2017 Top 10.
This tells us something we should already have guessed: IDOR is an access or authorisation problem. Allowing someone to access something shouldn’t have access to is an authorisation problem. You may have noticed I talk about this a lot, but it’s so important to get authorisation right.
The most common vulnerabilities I find when auditing my client’s apps are authorisation problems. Usually they’ve done everything else right, and just missed one small line, which gives me an opening I need to break in! Maybe they’ve forgotten to add middleware, or they aren’t checking if the user has access to the parent resource.
Authorisation problems can manifest in many different ways, but when we’re talking about IDORs we’re referring specifically to accessing resources that we shouldn’t have access to through some form of identifier. We’re familiar with using IDs, Slugs, Hashids, and UUIDs, as different identifiers that we can use for requesting resources in our apps. Many of these can be easily guessed, or found, and when requests made for these identifies aren’t properly authorised, we have an IDOR.
Some IDORs may not expose anything beyond the existence of a record, while others could leak sensitive data or Personally Identifiable Information (PII), or even the leak entire database! I even had one that allowed me to login as any user2.
Do Try This At Home!
In this post we’re going to explore some different examples of IDORs, based off different examples I’ve seen in the wild. To aid with this exploration, I’ve built 5 new challenges into intentionally vulnerable demo site!
You’ve got three options:
- You can either stop reading the post and work through the challenges on your own first, and then come back when you’ve finished to read the post.
- Alternatively, you can work through the challenges while reading the post. A guided tour, as such. 😉
- Or you can just read the post and skip the challenges. I’ll include screenshots and solutions, so you’ll know what’s going on with each challenge.
