This post intends to serve as a guide for some easy wins to look for when pentesting a web application for weak authentication controls. Note that this differs from Broken Authorization Controls, as Authentication takes place first.
This post will be updated as I learn more about broken controls to look for.
Check session cookies.
- Sometimes you’ll find that an application will place a cookie with a value that matches the user that you’re logged in with. If you modify this cookie to read a different value, you may be able to modify the account you’re authenticated as.
- In an attempt to make a cookie a bit less human readable, webdevs might hash your username with a common algorithm and then use that value as your session cookie value. You should check the cookie to see if you can identify whether a hashing algorithm is in place. If so, check to see if it matches your username, as this could be an easy way to impersonate other users.
Registering the admin user.
- When you’re able to register a new user, you may be able to register the “admin” user yourself if proper checks are not in place.
- If it gives you an error, see if you can adjust the casing as not all checks are case sensitive. For example, try registering with “aDmin” instead of “admin”.
- See if you can add a space at the end of the username to register “admin ” instead of “admin”. You can even try with multiple spaces.
Viewing redirect responses.
- Some webdevs may force a redirect to a login page when you attempt to navigate a site. If you capture this request in Burpsuite, you can view the Response and see if there is any information on the page that is sensitive before the redirection takes place. You could also run Curl against the page to get the same result.