Authentication

Password based

Username/password enumeration

Brute force

Use burp intruder to check if responses indicate known indicators to look for:

Error message
return values
file size
timing differences

Protection bypass

When ip blocking occurs, enter own credentials at intervals to avoid locking
account lockout can be abused for user enum
- The error message may indicate differnce between lockout and ok password
try all passwords in a JSON login

2FA

bypass

Wait for the verification code and hard bypass to known url

logic flaw

When the login steps are counted, try changing values in the last step:

POST /login-steps/second HTTP/1.1
Host: vulnerable-website.com
Cookie: account=carlos
...
verification-code=123456

POST /login-steps/second HTTP/1.1
Host: vulnerable-website.com
Cookie: account=victim-user
...
verification-code=123456

this is the final step after authenticating in step 1 with

POST /login-steps/first HTTP/1.1
Host: vulnerable-website.com
...
username=carlos&password=qwerty



HTTP/1.1 200 OK
Set-Cookie: account=carlos

GET /login-steps/second HTTP/1.1
Cookie: account=carlos

This may ba abused tby bruteforing using a macro

Other mechanisms

sty logged in

It may be that the cookie is holding the username:password This info may be abused by using a different user and encoding is as found.

It may be that an XSS is able to steal such a cookie. Unhash the cookie password.

password reset via mail

Try a password reset an figure out the logic.

Sometimes the token is repeated in a cookie and in the body. Removing them both may disrupt the test and reset the password.
Use x-forwarded-host to change the email host part after an intercept

Example:

The user enters their username or email address and submits a password reset request.
The website checks that this user exists and then generates a temporary, unique, high-entropy token, which it associates with the user’s account on the back-end.
The website sends an email to the user that contains a link for resetting their password. The user’s unique reset token is included as a query parameter in the corresponding URL:
```
https://normal-website.com/reset?token=0a1b2c3d4e5f6g7h8i9j
```
When the user visits this URL, the website checks whether the provided token is valid and uses it to determine which account is being reset. If everything is as expected, the user is given the option to enter a new password. Finally, the token is destroyed.

So exploit this:

Submit password request on behalf of victim
intercept and change host header to owned domain
On click, the evil domain catches the token
Use the token to reset the victim password

Or use the x-forwarded-host to change the domain
Or use a dangling pointer

see portswigger

OAuth