DEV Community

Shadrach Adongo
Shadrach Adongo

Posted on

TryHackMe Neighbour Walkthrough Easy IDOR Room Explained

🎯 Room Info

Room Neighbour
Difficulty 🟢 Easy
Category IDOR (Insecure Direct Object Reference), API abuse
Link tryhackme.com/room/neighbour

📖 What This Room Is About

Neighbour is a small web app CTF built around a single, very common vulnerability class: IDOR — Insecure Direct Object Reference. It happens when an app lets you access someone else's data just by changing an ID in a URL or request, because the server never checks whether you are actually allowed to see it.

This room walks through:

  1. 🌐 Finding a registration/login flow
  2. 🔍 Poking at API endpoints and object IDs
  3. 🔓 Exploiting the IDOR to read data that shouldn't be yours
  4. 🚩 Chaining that access into full compromise

IDOR is one of the most-reported bug classes on real bug bounty platforms, which makes this an unusually practical easy room.

🧠 Skills You'll Practice

  • Web app enumeration (registration, login, session inspection)
  • Reading and manipulating API requests (Burp Suite / browser dev tools)
  • Recognizing and exploiting IDOR
  • Turning read access into further compromise (credential/data leakage)

🛠️ Step-by-Step Walkthrough

1️⃣ Scan and explore the target 

nmap -sC -sV -oN nmap-initial.txt <TARGET_IP>
Enter fullscreen mode Exit fullscreen mode

HTTP is open. Browse to the site and look around — Neighbour is themed as a small social/blogging platform where users have profile pages.

2️⃣ Register an account

Most IDOR rooms start the same way: create your own low-privilege account so you have a baseline "your data" vs. "someone else's data" to compare.

http://<TARGET_IP>/register
Enter fullscreen mode Exit fullscreen mode

Log in once your account is created, and note your own user ID — check the URL when you view your profile, e.g.:

http://<TARGET_IP>/profile?id=8
Enter fullscreen mode Exit fullscreen mode

3️⃣ Test the object reference

This is the core of an IDOR test: change the ID in the URL to a different number and see what happens.

http://<TARGET_IP>/profile?id=1
http://<TARGET_IP>/profile?id=2
Enter fullscreen mode Exit fullscreen mode

If the app returns another user's profile data without checking that it belongs to you, that's a confirmed IDOR.

💡 Why this matters: a properly built app checks "does this logged-in session own this resource?" on every request — not just whether you're logged in at all. Skipping that check is what makes IDOR possible.

4️⃣ Enumerate other users

Since IDs are usually small sequential integers, loop through them to map out the whole user base:

for id in $(seq 1 20); do
  curl -s -b "session=<YOUR_SESSION_COOKIE>" "http://<TARGET_IP>/profile?id=$id" | grep -i "username\|email"
done
Enter fullscreen mode Exit fullscreen mode

Or do this manually in Burp Suite using Intruder with a numeric payload range — cleaner for inspecting full responses.

5️⃣ Find the interesting account

Somewhere in that ID range is an account (often an admin or a specific named user referenced in the room's story) that holds something useful — a flag, a password reset token, or a hint pointing to the next step.

http://<TARGET_IP>/profile?id=1
Enter fullscreen mode Exit fullscreen mode

🔍 Click to reveal: what to look for

Pay attention to any field that isn't normally visible on your own profile page by default — some IDOR rooms expose extra fields (like a password hash, an internal note, or a security answer) only when viewing other users' records, because the developer assumed no one but the account owner would ever load that page.

6️⃣ Capture the flag

Once you land on the right profile ID, the flag is typically displayed directly on the page or inside a field you can now read because of the broken access control.

cat flag.txt   # if the IDOR exposes a downloadable file instead of a page field
Enter fullscreen mode Exit fullscreen mode

🚩 Click to reveal: flag

Redacted — swap in your own captured flag if you want to keep a private record.

📋 Every Command, In Order 

nmap -sC -sV -oN nmap-initial.txt <TARGET_IP>
# Register + log in via browser
# Note your own profile ID
for id in $(seq 1 20); do
  curl -s -b "session=<YOUR_SESSION_COOKIE>" "http://<TARGET_IP>/profile?id=$id" | grep -i "username\|email"
done
Enter fullscreen mode Exit fullscreen mode

🎓 Key Takeaways

  • IDOR is an access control failure, not an input validation one. The app correctly identifies you're logged in — it just never checks whether the specific resource you're requesting belongs to you.
  • Sequential numeric IDs make IDOR trivial to exploit. This is why many modern apps use UUIDs instead of id=1, 2, 3... — it doesn't fix the underlying flaw, but it removes the easy guessability.
  • Always compare "your data" vs "someone else's data" as a baseline test. Creating your own account first, like in this room, is standard methodology on real engagements too.
  • IDOR consistently ranks among the top reported bugs on HackerOne and Bugcrowd. This easy room maps directly onto a skill that pays real bug bounties.

Top comments (0)