IDOR: Who, What, Where, When, Why, How?
Cybersec Café #46 - 12/17/24
After a long wait… the WWWWWH series is back.
Today, we’ll be diving into the Who, What, When, Where, Why, and How of Insecure Direct Object Reference, or IDOR for short. If you’re new to the newsletter, the purpose of this series is to dive deeper than just the How to exploit vulnerabilites that you’ve read so many articles about. In reality, the How is a byproduct of the context around the vulnerability itself, and in order to hunt for these vulnerabilities in the wild, it’s important to understand them from a holistic, end-to-end perspective.
Insecure Direct Object Reference (IDOR)
IDOR vulnerabilities are a type of access control vulnerability that occurs when an application exposes references to internal objects, such as files, database records, or user accounts, without properly validating a user’s authorization. This flaw can allow attackers to manipulate these references to access or modify data they shouldn’t have permission to through techniques such as changing an ID in a URL or API request. IDOR vulnerabilities often arise due to insufficient server-side checks, making them a frequent target in penetration testing and bug bounty hunting.
If you enjoy this article and you’re interested in deep diving into other vulnerabilities, here are some other vulnerabilities I’ve given a WWWWWH analysis:
WWWWWH Analysis
Who?
The victim of an IDOR vulnerabilty is generally a customer, user, or stakeholder of the application. Sometimes the victim could be random (as we’ll see in the example later) but it can also be targetted with some reconaissance. Since the nature of the attack can change based on the feature in question, the target of an attack depends on the context of the vulnerability.
What?
An IDOR, at it’s simplest form, is unauthorized access to resources due to missing or improper access controls. Attackers will go after different customers data located in the same application, or resources locked behind highly privileged roles.
When?
Attackers may have the best success searching for IDOR vulnerabilities when new complexities are introduced into an application. This can come in the form of new features or new roles that are released without sufficient testing. Attackers can keep with an application through patch notes or automated scans that detect when new features or pages have been added into an application.
Where?
IDOR vulnerabilities are generally found in API endpoints that poorly implement access controls, but can also occur where user input is used to access data. The key when searching for IDORs is to first find predictable patterns of behavior, then fuzz for unexpected results. Unexpected 200’s are a key indicator.
Why?
IDOR’s are attractive to attackers because they’re difficult to test for using automation from a developer and product perspective. In addition, their low effort to exploit with potentially critical impact is appealing. Malicious actors can target personal, business, and financial data as well as administrative/CRUD functions - but most devastatingly they can chain an IDOR vulnerability with other vulnerabilities, such as privilege escalation. Outcome could be anything from data exfiltration to loss of reputation and customer trust.
How?
Let’s consider a web application that has standard subscription levels: Basic, Pro, and Enterprise.
After some basic reconnaissance of the application using Burp and digging through API documentation, you (the attacker) have found the app has the following endpoints:
GET /api/users/{user_id}/details: Retrieve a user’s account details
POST /api/subscriptions/{subscription_id}/upgrade: Upgrade a user’s subscription
POST /api/admin/{user_id}/role-change: Change a user's role (admin-only)
Your first step is to identify the attack vector. After spinning up a free account, you see you have the “Basic” plan, which is fetched via the following request:
While inspecting the network traffic, you notice that the userID is just an int - not a random string. You deduce that the ID system is incremental, and decide to try a low number that may point to an admin user:
For this example, let’s assume you retrieve a 200 response - confirming the lack of proper access controls.
Let’s now attempt to apply this to the subscriptions API.
As expected, you’re met with a 200 - effectively upgrading the admin user’s subscription.
But after testing with your own:
You get denied - it looks like the developers may know what they’re doing after all…
It’s great if you can upgrade a random account, but the real jackpot comes if we can figure out how to upgrade our own account.
Seeing as the we found an admin role-change endpoint in our recon, let’s attempt to change our permissions:
Again, for the sake of this example, let’s assume that the request is not properly implemented and we are able to grant ourselves administrator privileges.
What does this mean?
Well, outside of now being an admin and being able to upgrade our own subscription, let’s consider other common endpoints:
An endpoint like GET /api/users/all could provide all user data
Another endpoint like POST /api/admin/{user_id}/downgrade could downgrade other customers, possibly damaging the reputation of the company.
Chaining with other vulnerabilities could also potentially lead to injecting malicious scripts into admin-controlled pages.
So, how do IDOR vulnerabilities happen? It comes down to implementation of the endpoint. Let’s compare an insecure implementation against a secure implementation.
INSECURE:
SECURE:
In order to implement the endpoint correctly, like most vulnerabilities that arise, we cannot implicitly trust anything that the user passes us (as shown in the insecure implementation). Instead, implement the endpoint so that the role is retrieved from a secure source.
WWWWWH: IDOR
Although this How example is dramatized when compared to what you’ll likely run into in the wild, it serves to illustrate the bigger picture of how an IDOR can be easily missed by developers, and can pose a critical threat to applications. The ability to not only view other customer data, but also perform administrative actions is severe in itself without accounting for the possibility to chain it with additional vlnerabilities. This example shows the importance of always validating and never implicitly trusting, as well as performing security audits when introducing increased complexities into applications.
As always, this material is meant to be used for educational purposes and not for malicious practice.
Securely Yours,
The Cybersec Cafe
Just a heads up, The Cybersec Cafe's got a pretty cool weekly cadence.
Every week, expect to dive into the hacker’s mindset in our Methodology Walkthroughs or explore Deep Dive articles on various cybersecurity topics.
. . .
Oh, and if you want even more content and updates, hop over to Ryan G. Cox on Twitter/X or my Website. Can't wait to keep sharing and learning together!