Exploiting IDOR Through Predictable Hashed Endpoints

In this challenge, we explore how using predictable hashed values instead of proper access control can still lead to an Insecure Direct Object Reference (IDOR) vulnerability.

The Challange:

You have found yourself in a strange corridor. Can you find your way back to where you came?

In this challenge, you will explore potential IDOR vulnerabilities. Examine the URL endpoints you access as you navigate the website and note the hexadecimal values you find (they look an awful lot like a hash, don't they?). This could help you uncover website locations you were not expected to access.

Introduction:

We're given access to a web application that displays a corridor with multiple doors.

Each door leads to a different room, but none of them seem to contain anything useful at first glance.

The goal is simple: Find the hidden flag by exploring how the application handles these room endpoints.

Step1: Accessing the Application

None
The corridor

After opening the target URL, we are presented with an image of a corridor containing multiple doors.

Each door is clickable and redirects to a new page.

However, every room appears empty.

None
Empty rooms

Step 2: Observing the URL Structure

None
Notice the URL

When clicking on different doors, we notice something interesting in the URL:

http://<target-ip>/c4ca4238a0b923820dcc509a6f75849b

Each room is identified by a hexadecimal string, which looks very similar to a hash.

This is a strong hint that the application might be using encoded or hashed identifiers.

Step 3: Inspecting the Source Code

None
Source Code (Accessed Using Ctrl+U)

Viewing the page source reveals all the door endpoints.

This tells us:

  • All room links are directly exposed in the frontend
  • Each room corresponds to a specific hash value

Step 4: Identifying the Hash

Using an online decoder ( https://www.dcode.fr/ ), we find that these are MD5 hash values.

Decoded results:

c4ca4238a0b923820dcc509a6f75849b → 1  
c81e728d9d4c2f636f067f89cc14862c → 2  
eccbc87e4b5ce2fe28308fd9f2a7baf3 → 3  
...

So the pattern becomes clear:

room → MD5(number)

The application uses hashed values to represent rooms, but:

  • The hashes are predictable
  • There is no access control
  • The server blindly trusts the requested URL

This is a classic IDOR vulnerability:

  • Users can modify the identifier
  • No validation is performed
  • Unauthorized resources can be accessed

Step 5: Exploiting the IDOR

Now that we understand the pattern, we try accessing values outside the given range.

Trying MD5(14) aab3238922bcc25a6f606eb525ffdc56

This still leads to an empty room.

Trying MD5(0) 897316929176464ebc9ad085f31e7284

This reveals the flag!

None

Final Thoughts

This challenge demonstrates that simply using hashes does not guarantee security.

If identifiers are predictable and not protected by proper authorization checks, they can be easily abused.

Key Takeaways:

  • Hashing does not equal security
  • Predictable identifiers can lead to IDOR
  • Always validate user access on the server side
  • Test edge cases like 0, negative numbers, or out-of-range values

In this challenge, we explore how using predictable hashed values instead of proper access control can still lead to an Insecure Direct Object Reference (IDOR) vulnerability.