WebApp 101

WebApps 101: Broken Authentication Controls

Note: Majority of the content here was ripped directly from PortSwigger.net.

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.


What is Authentication?

Authentication is the process of verifying the identity of a given user or client. In other words, it involves making sure that they really are who they claim to be.

  • Something you know, such as a password or the answer to a security question. These are sometimes referred to as “knowledge factors”.
  • Something you have, that is, a physical object like a mobile phone or security token. These are sometimes referred to as “possession factors”.
  • Something you are or do, for example, your biometrics or patterns of behavior. These are sometimes referred to as “inherence factors”.

How do we test for Broken Authentication Vulnerabilities?

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.

Example: Going to http://example.com/ may redirect to http://example.com/login.php. Viewing the response may reveal information on the page that they didn’t think you’d be able to see.


Bypassing Authentication: Null Binds

  • Some LDAP servers will be configured to allow Null Binds. If you’re prompted to login, and the login is performed with a post request, try issuing a request without any username or password parameters in the body.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s