Authentication

Usernames enumeration

Test in every features that interact with user account. E.g. login, password recovery.

Default username

admin
administrator
firstname.lastname@somecompany.com

Regisitration form

Create account and see if there's error like "account already exists".


Comparing responses

Use a valid user and an invalid user (and incorrect password). One character out of place makes the messages distinct, even if not visible on the page.

Tip: Use "Grep - match" in Burp Intruder to fetch the error message


Account locking

Try 3/5 login. If the account is locked, it could mean that there is.


Response times

A website may only check the password if the username is valid. So, entering an excessively long password causes a noticeable delay.

Passwords

Password Cracking

Account locking

Guess password with locked account

With your account locked, send a request with an incorrect password and another with a correct password. Is the response different?


IP blocked bypass

  • The failed attempts counter resets if the IP owner logs in successfully. (Make sure that concurrent requests is set to 1)

  • Try to bypass by adding X-Forwarded-For header


With password change

See if you can change the password of an arbitrary user. E.g. look for a hidden username paramer (control it). Brute-force password when you enter your current password.

Tip: use your account and notice different behavior.

  • current password: wrong, new-password-1=XXX, new-password-2=XXX

  • current password: wrong, new-password-1=XXX, new-password-2=YYY

  • current password: <right>, new-password-1=XXX, new-password-2=XXX

  • current password: <right>, new-password-1=XXX, new-password-2=YYY

2FA

  • Brute-force OTP

  • Bypassing two-factor authentication

Check if you can directly skip to "logged-in" pages.

  • Flawed logic

# 1 step - (REQUEST) Normal login with attacker account
POST /login-steps/first HTTP/1.1
Host: vulnerable-website.com
[...]

username=attacker&password=qwerty
# 1 step - (RESPONSE) The server sets cookie
HTTP/1.1 200 OK
Set-Cookie: account=attacker
# 2 step - request two-factor
GET /login-steps/second HTTP/1.1
Cookie: account=attacker
# 3 step - submit the two-factor code with victim cookie
POST /login-steps/second HTTP/1.1
Host: vulnerable-website.com
Cookie: account=victim-user
[...]

verification-code=123456

Remember me option

  • Study your cookie and deduce how it is generated - Sometimes this cookie is hashed or encoded (e.g. base64)

  • Brute-force other users' cookies to gain access to their accounts

Password reset

Control username parameter

After you receive an email with the URL to reset your password, see if you can control username parameter.

POST /forgot-pwd?temp-token=xxx HTTP/2
[...]

user=<victim>&new-pwd-1=<whatever>&new-pwd-2=<whatever>&token=xxx

Resetting passwords using a URL (static token)

Poor implementation can use guessable parameter: E.g. http://vulnerable-website.com/reset-password?user=victim-user


Steal another user's token (for dynamic token)

Add the X-Forwarded-Host header and see if it allows you to control the link generated by the app. This way, you can insert your website's URL so that when the user clicks on the link, they are directed to http://your.website.com/reset-password?token=impredictabletoken.

POST /forgot-password HTTP/2
Host: 0ad400fb039bb5ea816cac4d00be00a8.web-security-academy.net
X-Forwarded-Host: your.website.com

username=lebron

Last updated