PortSwigger's "Username enumeration via subtly different responses" Walkthrough

This is the second of Portswigger’s Authentication Labs. Before we get started, you’ll need Burp Suite installed (check out this blog post for setup instructions), and an Portswigger Academy account.

After logging in, head over to the lab, located at https://portswigger.net/web-security/authentication/password-based/lab-username-enumeration-via-subtly-different-responses. You can find this through the Academy learning path list, or linked within the Authentication blog post.

Note: the correct answers vary between lab sessions, so you need to follow the steps to find the correct values for your lab session.

Challenge Information

Click the “Access the Lab” button and you will be taken to a temporary website that is created for your account. This will be in format https://<random string here>.web-security-academy.net/.

As with the previous authentication lab, this attack is reliant on different responses between an “invalid username” and “invalid password” case. This allows us to narrow down the valid username list, then narrow down the valid password list. This saves a lot of time in a bruteforce attack, which is why it’s important for developers to not leak information in this manner.

Challenge materials

We’re given a username list and a password list:

Keep these two tabs open, because we will need them in a minute.

Challenge website

The challenge website looks like this:

Click “My account” to get to the login page:

Then, with Burp Suite open and your proxy running, submit a fake set of credentials such as test/test. In Burp Suite, go to the Proxy tab, find this request, right-click it and select Send to Intruder.

As with the previous level, you’ll need to remove the extra variables from the Intruder positions. These variables are where Burp Suite inserts a payload list (one value at a time). Since we’re narrowing down the username, then the password, we only need one variable at a time.

To do so, highlight a variable (denoted by §) and then click Clear. Remove all variables that Burp Suite has auto-generated for you, except the username value:

Then, click the Payloads tab. As before, we’ll need to copy the username list into the Payload Options view by clicking Paste:

Then click Start Attack. You’ll quickly notice that the payload length is all over the place:

In the previous level, we could just watch the payload length to find the correct username. But this time we can’t… we’ll need another way to differentiate between responses. Each response says “Invalid username or password”, but there are no obvious differences.

Adjusting the brutefroce attack

Stop the attack by closing the window. Then click the Options tab, and scroll down to the Grep Extract section.

Click Add, and then copy/paste the error response “Invalid username or password”. This will return the HTML response in each request, starting at the end of “Invalid username or password” until the end of the file:

Restart the attack, and you will eventually see a line with a minor difference:

This lack of a . tells us that this case is being handled differently by the backend code. This is our valid username. In my case, it’s auth but since the values are randomized with each session, yours will be different.

Bruteforcing the password

Go back to the Options tab and adjust the variables so that the username is hardcoded with auth (or whatever value you found), and the password is now the variable:

Then, go to the Payloads tab and clear the payload list. Then copy from the password list and paste into the Payload Options section using the Paste button.

Click Start Attack on the right-hand side. Eventually, you will see a short response (similar to the previous level) that is a 302 redirect to /my-account. This means that the password is correct. For me, this value is 123456789.

Login with this value to complete the lab: