Advent of Cyber Day5

 

Cracking IDOR

A Hands-On Exploration of Authorization Flaws (Day 5 Challenge)

Introduction

The elves of Wareville are in panic. After McSkidy mysteriously disappeared, parents began reporting strange behaviour on the TryPresentMe website. Gift vouchers failed to activate, and phishing emails contained private details no one should have access to.

Investigations led TBFC staff to a suspicious account named Sir Carrotbane, hoarding an unusually large number of vouchers. Although the account was removed and vouchers recovered, the incident revealed a deeper issue.

This challenge explores that weakness and demonstrates how attackers exploit one of the most common web vulnerabilities: Insecure Direct Object Reference (IDOR).

🎯 What You’ll Learn

In this challenge, you will understand:

  • The difference between authentication and authorization

  • What IDOR is and why it occurs

  • How attackers discover exposed object references

  • Horizontal privilege escalation through IDOR

  • Secure design principles to prevent IDOR

🔍 Understanding IDOR

Have you ever seen a URL like this?

https://awesome.website.thm/TrackPackage?packageID=1001

And wondered: What happens if I change the number?

That curiosity is exactly how an IDOR vulnerability is discovered.

❓ What Is IDOR?

IDOR (Insecure Direct Object Reference) is an access control vulnerability that occurs when an application exposes internal object identifiers—such as user IDs, file names, or order numbers—without verifying whether the requesting user is authorized to access them.

Simple Example

If changing:

packageID=1001 → packageID=1002

allows access to another user’s package, the application is vulnerable to IDOR.

⚠️ Why Does IDOR Happen So Often?

Developers frequently rely on direct object lookups such as:

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

Without authorization checks, attackers can:

  • Increment values

  • Enumerate resources

  • Access sensitive data

If the endpoint doesn’t require authentication, tracking abuse becomes even harder.

🔐 Authentication vs Authorization

Understanding IDOR requires knowing the difference between two key concepts.

✔ Authentication

“Who are you?”

  • Occurs during login

  • Maintained through sessions or tokens

✔ Authorization

“What are you allowed to access?”

  • Must be enforced on every request

  • Depends on knowing the authenticated user

❗ Authentication without authorization is useless.

🚨 Privilege Escalation via IDOR

IDOR vulnerabilities typically lead to privilege escalation.

1️⃣ Vertical Privilege Escalation

  • Regular user gains admin-level access

2️⃣ Horizontal Privilege Escalation

  • One user accesses another user’s data

🧠 80–90% of IDOR vulnerabilities are horizontal, making them extremely common and dangerous.

🧪 Live Exploitation: Finding IDOR

After logging into the TryPresentMe platform, the dashboard loads normally. However, inspecting network traffic reveals the following request:

/view_accountinfo?user_id=10

Changing the value of user_id and refreshing the page exposes another user’s account details.

✔ This confirms a classic IDOR vulnerability.

🕵️ Hidden Object References

Not all IDOR vulnerabilities use plain numbers.

🔹 Base64-Encoding

Example:

child_id = Mg==

Decoding Base64 reveals:

2

Encoding data does not prevent IDOR.

🔹 Hashed Identifiers

Some applications use MD5 or SHA-based hashes.
If the original value is predictable (such as incremental IDs), attackers can still generate valid references.

🔹 UUID-Based IDOR

Vouchers appeared random but were identified as UUID version 1.

UUIDv1 includes:

  • Timestamp

  • MAC address

If attackers know the time window of generation, they can brute-force valid voucher IDs.

🛠️ Fixing IDOR the Right Way

Common misconceptions:

  • ❌ Hiding IDs ≠ Security

  • ❌ Encoding ≠ Security

  • ❌ Hashing ≠ Security

✅ Correct Fix

Every request must:

  1. Identify the authenticated user

  2. Verify ownership or permissions

  3. Reject unauthorized access

Additional Best Practices

  • Use non-sequential identifiers

  • Log and alert on unauthorized access attempts

  • Regularly test endpoints for access control flaws

🏁 Challenge Answers

✔ What does IDOR stand for?
Insecure Direct Object Reference

✔ Most common privilege escalation in IDOR?
Horizontal

✔ User ID of the parent with 10 children?
15

(Bonus challenges require advanced enumeration and do not have a single fixed answer.)

🎄 Final Thoughts

IDOR is one of the simplest yet most destructive vulnerabilities in web applications. It appears everywhere—from student portals to financial systems—because developers trust client-side identifiers too much.

Always remember:

  • 👉 Never trust data from the client

  • 👉 Always enforce authorization on the server

If you enjoyed this challenge, explore the full IDOR room to sharpen your access control testing skills.

Comments

Post a Comment

Popular Posts