Common Web Application Vulnerabilities – Authentication Weaknesses

As we continue our mini-series addressing some of the most common web application vulnerabilities we see during assessments, we turn our attention to the broad category of authentication weaknesses next. The OWASP Top 10 identifies this category as number 2 on its list, meaning it is obviously well known and prevalent. So then why are we still seeing so many issues here?

Well that’s probably due to a couple different reasons. First, the authentication process for any web application can be complicated and there are a lot of considerations to be made for how to conduct authentication in a secure manner. This takes research and training in secure software development, which can be a notoriously lacking area in many organizations. Beyond simple blind spots in a nuanced area, many organizations make arguments that securing the authentication process hampers the user experience and may reduce overall usability of their application. I’d argue that if Google can manage authentication securely for all their services, it’s probably not that big of an impact. Now of course that should be taken with a grain of salt because Google does have significantly more resources than the average bear, but in general, you can manage the authentication process securely without negatively affecting your application’s user experience.

Vulnerabilities in the Authentication Process

We’ll break out some of the different issues in the realm of authentication weaknesses below. We already covered username enumeration in a previous blog even though it definitely applies here. It is just so common and has so many different aspects to consider it really made sense to break it out on its own.

Lack of Account Lockouts

One of the biggest threats for applications exposed to the Internet is password attacks. Any login page has a giant bullseye on it for adversaries looking to attack. The most common and easily launched password attack is a simple dictionary-based or brute force attack, where an attacker tries a bunch of passwords against a common account or a username they’ve discovered somewhere. An easy to help stop these kinds of attacks is through account lockouts, which should be fairly well known as a mitigating control (e.g. 5 invalid login attempts locks an account out for an hour).

Lack of Anti-Automation

Similarly to account lockouts, anti-automation controls can be effective in mitigating password attacks. But these controls can help stop more than traditional brute force attacks. They can also be great for preventing automated username enumeration techniques or password spraying attacks. Sometimes anti-automation will be in the form of a CAPTCHA that a user has to answer to login (or it may only show up after a certain number of invalid attempts). Other times anti-automation could be a temporary IP blacklist after a certain number of requests in a certain time period. And another might be an exponential back-off, which is a type of control that enforces an exponential sleep time in between invalid login attempts (e.g. 1 invalid attempt no sleep, 2 attempts sleep for 5 secs before next, 3 attempts sleep for 30 secs before next, and so on).

Weak Password Policy

Web application password policies seem to be lagging behind the rest of security best practice for organizations. Sometimes there are good reasons for this (e.g. bank applications tied to mainframes) but many times it’s just a lack of understanding of the risk or a misjudgment on the usability impacts. This goes for both weak password policies that don’t require at least 8 characters in length, prevent extremely common passwords using a blacklist, etc. as well as unnecessary password restrictions that don’t have a positive impact on security like arbitrary complexity requirements or the prevention of certain special characters.

Lack of Support for MFA

Depending on the sensitivity of data contained within a web application, support for multi-factor authentication when an application is Internet accessible is quickly becoming a minimum security feature. Partially due to the prevalence of password attacks and credential stuffing and partially due to remote access requirements pushed by compliance standards, it’s a great way to allow users to be as secure as they want to be. Ideally, this involves support for a third-party authenticator app or hardware security token. But if that isn’t possible or for lower security applications, two step verification with email or SMS can be useful alternatives.

There are other vulnerabilities that can occur related to authentication weaknesses, of course. But we just wanted to cover some of the most common as raise awareness for some fairly common issues we report on a regular basis. If you have any questions or want to schedule a web application penetration test to see if any of these issues plague your organization’s applications, let us know!