This covers different ways website authentication methods can be bypassed, defeated or broken. These vulnerabilities can be some of the most critical as it often ends in leaks of customers personal data. ### Username Enumeration A helpful exercise to complete when trying to find authentication vulnerabilities is **creating a list of valid usernames**. Website error messages are great resources for collating this information to build our list of valid usernames. If you try *entering the username admin* and fill in the other form fields with fake information, you'll see we get the error An account with this username already exists. We can use the existence of this error message to produce a list of valid usernames already signed up on the system by using the ffuf tool below. The ffuf tool uses a list of commonly used usernames to check against for any matches. ```bash user@tryhackme$ ffuf -w /usr/share/wordlists/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://10.10.91.63/customers/signup -mr "username already exists" ``` In the above example, the `-w` argument *selects the file's location on the computer* that contains the list of usernames that we're going to check exists. The `-X` argument *specifies the request method*, this will be a GET request by default, but it is a POST request in our example. The `-d` argument *specifies the data* that we are going to send. In our example, we have the fields username, email, password and cpassword. We've set the value of the username to FUZZ. In the ffuf tool, the **FUZZ keyword signifies where the contents from our wordlist will be inserted** in the request. The `-H` argument is used for *adding additional headers* to the request. In this instance, we're setting the Content-Type so the web server knows we are sending form data. The `-u` argument *specifies the URL* we are making the request to, and finally, the `-mr` argument is *the text on the page we are looking for to validate* we've found a valid username. ### Brute Force Using the valid_usernames.txt file we generated in the previous task, we can now use this to attempt a brute force attack on the login page. A brute force attack is an automated process that tries a list of commonly used passwords against either a single username or, like in our case, a list of usernames. ```bash user@tryhackme$ ffuf -w valid_usernames.txt:W1,/usr/share/wordlists/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://10.10.91.63/customers/login -fc 200 ``` Previously we used the FUZZ keyword to select where in the request the data from the wordlists would be inserted, but because we're using multiple wordlists, we have to specify our own FUZZ keyword. In this instance, we've chosen *W1 for our list of valid usernames* and *W2 for the list of passwords* we will try. The multiple wordlists are again specified with the `-w` argument but separated with a comma. For a positive match, we're using the `-fc` argument to check for an HTTP status code other than 200. ### Logic Flaw Sometimes authentication processes contain logic flaws. A logic flaw is when the typical logical path of an application is either bypassed, circumvented or manipulated by a hacker. Logic flaws can exist in any area of a website, but we're going to concentrate on examples relating to authentication in this instance. ![[Logic Flaw.png]] The below mock code example checks to see whether the start of the path the client is visiting begins with /admin and if so, then further checks are made to see whether the client is, in fact, an admin. If the page doesn't begin with /admin, the page is shown to the client. ```PHP if( url.substr(0,6) === '/admin') { # Code to check user is an admin } else { # View Page } ``` Because the above PHP code example uses three equals signs (\=\=\=), it's looking for an *exact match on the string, including the same letter casing*. The code presents a logic flaw because an unauthenticated user requesting **/adMin** will not have their privileges checked and have the page displayed to them, totally bypassing the authentication checks. ### Cookie Tampering Examining and editing the cookies set by the web server during your online session can have multiple outcomes, such as *unauthenticated access, access to another user's account, or elevated privileges*. The contents of some cookies can be in plain text, and it is obvious what they do. Take, for example, if these were the cookie set after a successful login: ```HTTP Set-Cookie: logged_in=true; Max-Age=3600; Path=/ Set-Cookie: admin=false; Max-Age=3600; Path=/ ``` We see one cookie (logged_in), which appears to control whether the user is currently logged in or not, and another (admin), which controls whether the visitor has admin privileges. Using this logic, if we were to change the contents of the cookies and make a request we'll be able to change our privileges.