Authentication is used by most web applications. Both for letting users have access to individual accounts, but also for protecting certain resources from the public. Basic authentication allows an individual to prove to the application that they are the user that is trying to access it. Unfortunately, authentication vulnerabilities are often found by pen testers too.

While there are many forms of authentication, the most common implementations are that of the username and password. Many modern applications have also adopted further authentication methods to help strengthen their security posture, such as multi-factor authentication (MFA). 

Usually when testing for authentication, penetration testers will follow OWASP’s Web Application Security Testing framework. The chapter of note is “04-Autentication Testing”, which covers almost all issues we are looking for. 

In this blog, we will go through some of the most common authentication vulnerabilities that penetration testers encounter. We’ll also offer some recommended remediations for each issue. 

Authentication vulnerability 1: Administrative interfaces with weak or default credentials 

Web applications often feature administrative interfaces to make it easier for administrators to update content and settings on the application. 

In most cases, having these interfaces publicly available does not pose a large risk itself, but other issues can lead to this being an entry point for adversaries. One such issue is if the administrator account has been compromised, giving the attacker full control over the application through the publicly facing interfaces. 

Default credentials  

Another issue can arise when the default credentials for the service have not been changed. For example, Outpost24 research shows that many admins are using weak and easily guessable passwords. By using various databases containing default credentials for services, an attacker can easily compromise the site. Even if the password has been changed from the default one, the username might still be the same, allowing an attacker to try to guess it. This is also the reverse case, where the username differs. 

Even if the default credentials have been changed, problems still arise when the credentials are weak or predictable. If the administrator account is changed from having the username “Admin” to “Admin_Account”, it is still highly guessable. The same thing with emails, for instance the admin account is “admin@some.company.com”, given the attacker knows or can guess the domain part of the email the account is still guessable. 

Recommended remediations  

• Remove remote access to administration panels if possible 
• If remote access is needed, restrict the access to specific IP ranges 
• Change any default credentials on the service 
• Always have strong passwords for administrative accounts 

Authentication vulnerability 2: Custom multi-factor authentication (MFA) 

Earlier we noted that most modern applications have implemented additional authentication methods to strengthen their security. The most popular and common of these implementations is 2FA (two factor authentication), usually a code that is sent to a phone number, emailed or accessed through an external application. While secure if done right and through well-known solutions such as Google or Microsoft authentication applications, problems arise when custom solutions are implemented. 

Take as an example you have an application that enforces their own MFA solution. Upon login you get prompted to enter the MFA code received on the account’s email. Looking at the email we can see the code: 

780053 

Retrying the process on a separate account shortly thereafter, the following code gets sent: 

780341 

Trying once again on the original account and we get the following: 

780452 

Instead of randomly generating a code each time, the application’s custom made MFA solution appends a static number to each MFA requested. This means that it is possible to predict the MFA code based on time, rendering the protection useless. 

Recommended remediations  

• Prioritize using a well-known MFA solution instead of a custom made 
• Ensure the tokens are randomly generated and not predictable 

Authentication vulnerability 3: User enumeration and brute forcing 

For a user wanting to authenticate to any application they need a unique identifier to prove who they are. The most common way to implement the identification part is to have a unique username or email address. Since the username along with the password are the most crucial parts, it’s important that the authentication functionality is not implemented in a manner that can give an adversary information regarding registered users and help protect against automated attacks. 

For example, if the application responds with the following depending on if the account exists or not: 

“Account could not be found” 

vs 

“Incorrect Password” 

An attacker could easily enumerate through common usernames to get knowledge of users registered to the site. While if the application responds with the following messages for all types of incorrect authentication attempts: 

“Invalid Credentials” 

An attacker would not be able to tell which usernames are registered on the application based on the error message only. The same issue often exists on password reset functionalities as well. 

If an attacker has access to a username the only thing left to guess in the best-case scenario is the password. Usually when you fail a login multiple times in a row or during a certain time frame an application will lock the account for a certain amount of time. But when this is not the case, an attacker could try a huge number of passwords to try to get access to an account. 

Recommended remediations 

• Restrict and rate limit login attempts from IP addresses sending a large amount of login requests. 
• Ensure the application responds with generic message on failed login and password reset. 
• Lock out users after certain amounts of incorrect login attempts  
• Implement a CAPTCHA 

Authentication vulnerability 4: Faulty Captchas 

As mentioned in the previous section, one solution to remediate user enumeration and brute forcing is to implement a CAPTCHA challenge. The main purpose of the challenge is to tell humans and bots apart, to help stop spam and automation on a website. The solved captcha is then sent with the request, verified by the server that it was solved, and the response is sent back.  

If everything is done correctly the application should block request without the CAPTCHA challenge or request with the incorrect solution. Solutions such as Googles reCAPTCHA can help with the implementation of this, but problems once again arise when implementing a custom solution. 

Captcha challenges  

Consider the CAPTCHA being displayed as an image, with random numbers and letters on it along with modifications to make it a bit harder to read. In certain cases, it is possible to automatically solve the problem using a script, that downloads the image, transforms it and reads it afterwards. This makes it possible to bypass the purpose of the challenge and still automate the brute force process. 

A CAPTCHA challenge should always be verified both client- and server side. The client-side check consists of checking that the challenge has been done, while the server-side check should verify that the challenge is solved. Problems arises when you only implement client-side checks. Given a login functionality, the CAPTCHA response should be sent along the request containing the username and password, so that it could be verified. But if the application does not send the CAPTCHA response in the request, or if it can be removed it enables automation once again. 

Recommended remediation 

• Ensure the CAPTCHA challenge is validated both client- and server-side. 
• Implement a strong, non-machine solvable captcha. 

Authentication vulnerability 5: Weak password policies 

Since the most common way of authentication is made through the combination of a user and password, it is always recommended to have a strong password. With many people reusing passwords or using easy to remember passwords that are considered weak, many applications have started enforcing password policies. The policies generally enforce the passwords to be of a certain length, contain specific characters or straight up refusing the use of common passwords. 

While this is a very common practice, there are still cases where the application allows users to set weak passwords. In some extreme cases when no policy is in place, could allow a single character to be used as a password. But even when there is a policy in place it could still be considered weak. For instance, if the application only enforces that all passwords are of at least 6 in length, then the following is a valid password: 

“password” 

For an adversary, guessing this would take no time at all, rendering the policy worthless. 

Recommended remediations  

• Enforce passwords to have a sufficient minimum length, 
• Enforce passwords to contain at least of uppercase-, lowercase-, and special characters. 
• Do not allow users to reuse old passwords. 
• Do not allow the use of common weak passwords (such as “password123”) 

Authentication vulnerability 6: Password resets and changes 

Password reset functionality is necessary for any site that wants to have an enjoyable experience for their users. Everyone forgets passwords, and to be able to reset it yourself without the need to contact a support division is a necessary function. Since anyone can send password reset requests to any account it is important for this to be handled securely. 

The reset is often done through a link to the URL sent over email. If the link is generated based of the email address, such as it just being the email base64 encoded, any account on the site could be compromised by an adversary that figured this out. The root problem is that the link should not be based on anything that can be predicted, i.e. the URL should be randomly generated so it is impossible for an adversary to guess it. 

Example walkthrough  

Another issue can appear if it is possible to manipulate the HTTP request that issues the rest. Consider the below request: 

We can see that the request body contains the “url” parameter. Normally this is set to the URL of site, creating a link in the email with the token the originator site. But take for example if an attacker changes this parameter to a domain under their control (attacker.com), like the following: 

Then there is a chance that the link in the password reset email will contain the correct reset token, but instead point to the attacker’s domain. If the user who got the password reset email presses the link, then the attacker can acquire the password reset. 

Another problem occurs when there is a lack of validation on password change for users. Usually when a user changes the password of their account, they will be prompted to enter the current password along with the desired new password. The following request should look something like this: 

Here we can see that the old password is sent with the request along with the desired new password. Because of oversight however, this is not always the case. When changing the password, you might have that you need to enter the current password, but when looking at the request: 

We can see that the current password is not sent with it, meaning that it is only validated client-side. This can be used by an attacker in multiple ways of to successfully hijack the account. For instance, if the site offers no cross-site request forgery (CSRF) protection, an attacker could craft a page that issues the password change without the need of knowing the current password. Also, if an attacker has hijacked the accounts session it could be leveraged for a full-on account takeover. 

Remediation advice 

While there is multiple more issues regarding changing passwords, these are the most common ones we encounter. To remediate this, ensure the following: 

• Password reset links are randomly generated and non-guessable. 
• Password reset links cannot be manipulated 
• Password change validation both client- and server-side 
• Password change has proper CSRF protection 

Test your web apps in real time for vulnerabilities  

With Outpost24’s SWAT solution, you can automatically and continuously monitor your internet-facing web applications for the latest vulnerabilities. Results are verified by our certified pen testers to avoid frustrating false positives. The solution can be fully customized to your needs, minimizing unnecessary load, or risk to any sensitive environments. You can also interact directly with our security experts for validation and remediation guidance, all via an easy-to-use portal. Book your live demo today.