IDOR: The Gift That Keeps On Taking

What's IDOR, Anyway?

Picture this: You're tracking a package at https://awesome.website.thm/TrackPackage?packageID=1001.

Now ask yourself: What happens if I change that to 1002?

If you can suddenly see someone else's package details, congratulations—you've found an IDOR vulnerability. It's like discovering that changing your gym locker number on a form gives you access to everyone else's locker.

IDOR stands for Insecure Direct Object Reference, and it's a type of access control vulnerability where web applications:

1. Use predictable references (IDs, numbers, codes)

2. Fail to verify you're authorized to access that reference

3. Happily hand over data that isn't yours

Why This Happens (A Lot)

Let's talk about lazy database queries. When a developer writes:

SELECT person, address, status FROM Packages WHERE packageID = value;

They've created the digital equivalent of a filing cabinet where anyone who knows a folder number can pull that folder—no ID check required.

The TryPresentMe application made this exact mistake. User IDs were sequential, predictable, and—most damning—completely unprotected by authorization checks.

The Authentication vs. Authorization Trap

Here's where many developers stumble:

• Authentication = "Who are you?" (Username + password)

• Authorization = "What are you allowed to do?"

The TryPresentMe app authenticated users just fine. It knew who was logged in. But it forgot to ask the crucial follow-up question: "Should you be viewing this user's data?"

This leads to horizontal privilege escalation—you're not gaining admin powers (vertical escalation), but you're accessing data belonging to other users at your same permission level. It's not climbing the ladder; it's raiding your neighbor's apartment.

The IDOR Disguise Kit

In Wareville's case, the attackers found IDOR vulnerabilities hiding in three different costumes:

1. Naked Numbers

The simplest form: user_id=10 in the request. Change it to 11, and boom—you're viewing someone else's account. No encryption, no obfuscation, just raw, predictable integers.

2. Base64 Camouflage

The child endpoint used Mg== instead of 2. Looks fancy, right? Except Base64 isn't encryption—it's just encoding. A security measure as effective as writing "SECRET" on an unsealed envelope.

3. Hash Browns (That Still Taste Like IDOR)

MD5 hashes in the edit endpoints looked impressive: c81e728d9d4c2f636f067f89cc14862c. But if you know what's being hashed (sequential IDs), you can simply replicate the hash for any ID you want. It's obfuscation theater.

4. UUID Roulette

The vouchers used UUID v1—which includes timestamp information. If you know vouchers were generated between 20:00-21:00 on a specific date, you can generate all 3,600 possible UUIDs for that hour and brute-force your way to valid vouchers. Predictability wearing a random-looking mask.

The Real-World Damage

Sir Carrotbane exploited these vulnerabilities to:

• Access other users' account information

• View children's private details

• Harvest valid vouchers

• Collect non-public information for targeted phishing campaigns

This wasn't just a theoretical vulnerability—it enabled actual harm. Parents couldn't access legitimate vouchers because they'd been hoarded. Private information fueled social engineering attacks.

How to Actually Fix IDOR

Want to turn IDOR into SDOR (Secure Direct Object Reference)? Follow these rules:

1. Always Verify on the Server

Every. Single. Request. Don't trust the client. Don't assume the user sending user_id=10 is actually user 10.

# BAD user_data = get_user(request.params['user_id']) # GOOD requested_user = request.params['user_id'] logged_in_user = get_current_user_from_session() if requested_user != logged_in_user.id: return "Unauthorized" user_data = get_user(requested_user)

2. Use Indirect References

Instead of exposing database IDs directly, use session-based mappings:

# Create a temporary mapping for this session session['voucher_map'] = { 'abc123': actual_voucher_id_1, 'def456': actual_voucher_id_2 } # User requests using 'abc123', you translate internally

3. Random IDs Aren't Security

UUIDs and random strings make enumeration harder, but they're not permission checks. If someone guesses or intercepts a UUID, you still need to verify they're authorized to access it.

4. Log and Monitor

Track failed authorization attempts. If user A keeps trying to access user B's data, that's either a bug or an attack—both worth knowing about.

5. Test Your Own App

Log in as User A. Try to access User B's data through every endpoint. If it works, you have IDOR. Fix it before Sir Carrotbane does.

The Wareville Lesson

The TryPresentMe incident teaches us that security isn't about making attacks difficult—it's about making them impossible through proper authorization checks.

Base64 encoding, MD5 hashing, and fancy UUID versions don't prevent IDOR. They just slow down attackers by about 30 seconds—the time it takes to open a Base64 decoder or write a simple hash function.

Real security means asking "Is this user authorized?" before returning data. Every time. No exceptions.

Sir Carrotbane may have been deleted, but the vulnerability that enabled the attack lived on until someone fixed the authorization logic at the server level.

Your Assignment

1. Audit your applications for direct object references

2. Add authorization checks to every endpoint

3. Test by trying to access other users' data

4. Don't rely on obfuscation as security

5. Remember: Authentication tells you who, Authorization tells you what

Because somewhere out there, in a digital kingdom not unlike Wareville, another Sir Carrotbane is changing URL parameters and seeing what breaks.

Don't let it be your application.

Want to practice finding IDOR vulnerabilities in a safe environment? Check out TryHackMe's complete IDOR room for hands-on experience.

#WebSecurity #IDOR #AccessControl #CyberSecurity #HorizontalPrivilegeEscalation