π― 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:
- π Finding a registration/login flow
- π Poking at API endpoints and object IDs
- π Exploiting the IDOR to read data that shouldn't be yours
- π© 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>
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
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
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
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
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
π 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
π© 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
π 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)