[This lab](https://portswigger.net/web-security/authentication/password-based/lab-username-enumeration-via-different-responses) demonstrates a common web security issue where the application leaks information during authentication attempts. Specifically, it returns **different responses for invalid usernames vs. incorrect passwords**, which allows attackers to: --- ##### Step-by-Step Exploitation ###### Step 1: Investigate Login Form - Visit `/login` - Submit any **invalid username** and **invalid password** - Example: `username=test`, `password=wrong` --- ###### Step 2: Intercept the Login Request - In **Burp Suite**, go to **Proxy → HTTP history** - Locate the `POST /login` request - Right-click → **Send to Intruder** --- ###### 🎯 Step 3: Enumerate Usernames - In Intruder → **Positions** tab: - Ensure only the `username` is marked with § symbols: ``` username=§test§&password=dummy ``` - Go to **Payloads** tab: - Payload type: **Simple list** - Paste the provided list of **candidate usernames** - Click **Start attack** --- ###### 🕵️ Step 4: Identify Valid Username - In the results window, **sort by Length** - Observe two types of responses: - Most say: `"Invalid username"` (shorter response) - One says: `"Incorrect password"` (longer response) ✅ The one with `"Incorrect password"` confirms the username is **valid**. - **Note** the username from the Payload column. ![[CleanShot 2025-05-07 at 12.10.56.png]] --- ###### 🔑 Step 5: Brute-Force the Password - Back in Intruder: - Click **Clear §** - Set: ``` username=valid-user&password=§guess§ ``` - In the **Payloads** tab: - Paste the list of **candidate passwords** - Click **Start attack** --- ###### ✅ Step 6: Identify Correct Password - In the results window: - Most requests return **200 OK* - The **correct password returns 302 Found (redirect)* ✅ The `302` means successful login. - **Note** the password from the Payload column. ![[CleanShot 2025-05-07 at 12.12.36.png]] --- ###### 🔐 Step 7: Log In and Access the Account Page - Use the discovered **username and password** to log in via `/login` - Navigate to the **user account page** to solve the lab --- ##### Why It Works - The application leaks different error messages for: - Invalid usernames → `"Invalid username"` - Valid usernames with wrong passwords → `"Incorrect password"` - This creates a **side channel** that leaks valid usernames - Once a valid user is found, brute-forcing their password becomes feasible --- ##### Real-World Parallels - Many public login forms (SaaS, VPNs, legacy apps) unintentionally leak user existence - Bots can combine leaked emails/usernames from data breaches with brute-force techniques - Credential stuffing relies heavily on this type of misconfiguration