In Depth: Insecure Direct Object References (IDOR)

[InDepth#11] Also known as hide-and-seek, and security through obscurity!

Greetings friends! I hope you enjoyed last week’s Security Tip about Leaking Model Existence, and are thinking about areas in your apps that could benefit from adding another layer of security in that area.

As promised, this week we’re diving into Insecure Direct Object Reference (IDOR) vulnerabilities. I find this a fascinating topic because there are so many options to choose from when preventing IDORs, and many subtle tricks and pitfalls you need to avoid. We’ll also be touching on a number of topics we’ve previously covered, such as Policy Objects, Signed URLs, and Timing Attacks. To help us learn about IDORs, we’ll walk through the new challenges on our intentionally vulnerable demo site. (You’re going to have a lot of fun with these ones!)

In addition to LSID, I’m a Laravel Security Consultant, offering Laravel Security Audits and Penetration Tests. Reach out if you'd like me to hack your app and work with you to improve your security!

---

In Depth: Insecure Direct Object References (IDOR)

What is a Insecure Direct Object Reference (IDOR) vulnerability?

OWASP defines IDOR as:

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 10¹. 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 user².

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:

1. 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.

2. Alternatively, you can work through the challenges while reading the post. A guided tour, as such. 😉

3. 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.