OWASP Top 10 #2: Broken Authentication

Number two on the OWASP top 10 is Broken Authentication, and while I want to make sure these explanatory guides are as in-depth and detailed as possible, this one is going to be a little shorter. This is because broken authentication is a vulnerability that most people who know computers sort of understand instinctually.

As we will continue doing, we can start with OWASP’s definition:

Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently.

OWASP, “OWASP Top 10,”

What is evident almost immediately is that this definition is exceptionally broad, in that it can contain almost any vulnerability related to faulty authentication and legitimate user impersonation. As such, we can really break this vulnerability down into two types of vulnerabilities: session management and credential management. In other words, while these two types of vulnerabilities are different, they are both ways that an attacker can exploit the broken authentication vulnerability and take control of a user’s identity.

1. Session Management

A flaw in a web app’s session management is considered a broken authentication vulnerability. To understand how these can be exploited, you have to understand session management.

Each time you get on a website — particularly one that you log in to — you are in a web session. A rough definition of a web session is a series of contiguous actions on a web application that a user does in one time period. The different pages the user visits during the session is tracked via a session ID, a unique identifier that keeps the user’s activity history and maintains it for future use by the user (in order to, say, make the checkout process in a store quicker). These session IDs are generally cookies — tiny bits of code that are downloaded onto the users’ computer — or URL parameters.

Without implementing appropriate safeguards in the app code, an attacker may be able to exploit any vulnerabilities in the code governing session management and hijack a session ID. At the end of the day, this stolen session ID is like a login credential to the app. In other words, the attacker can steal either the session ID or the login credentials: both will allow the attacker to impersonate the user and enter the app.

There are several tactics for attacking an app’s session management. These include the following:

1. Session Hijacking: As mentioned above, if an attacker is able to get ahold of a legitimate session ID, they may hijack the session and enter the app impersonating the legitimate user. App developers must therefore implement appropriate safeguards into their app code, ranging from the simple task of setting a session timeout parameter (so that if a user leaves the session without logging out, the app will automatically log them out after a set period) to implementing HTTPS with TLS/SSL in order to encrypt the session ID.
2. Session Fixation: Session fixation results primarily when a web app assigns a user the same session ID over and over again across numerous sessions. Researcher Troy Hunt has demonstrated that an attacker can use Session Fixation to essentially choose the victim’s session ID. This allows the attacker to send the victim a link to a page to log in — whether that page is the app’s actual login or a fake landing page. In turn, the attacker may steal the victim’s credentials or, if the web application does not create unique session IDs for each section, the victim may still login and the attacker can use the session ID to login impersonating the victim in a second separate, but contiguous session.
3. Session ID URL Rewriting: This one I saved for last because it is the easiest to imagine. If the app allows the session ID to appear in the URL, an attacker may rewrite it in order to hijack the session. The last most famous use of this tactic was zoombombing.

Compromising Credentials

Even though hijacking and tampering with an app’s session ID can be common, what is more common is the use of compromised credentials to login to the app.

Just as above, there are three primary tactics malicious actors use to compromise a victim’s credentials and then turn around and use those to access areas of an app that are off limits. Like above as well, we’ll go through these below:

1. Credential Stuffing: As you may recall from the last section, I mentioned Troy Hunt. Troy Hunt has become an all star in the cybersec community due to his extremely useful resource Have I Been Pwned? and his dedication to trolling the dark net and finding leaked databases of credentials and hashes. This is because every time a major organization is hacked — and that has been done countless times over the past ten years — an attacker will often place the database online for other attackers to use. Couple that fact with the maddening inability of people to use a password manager, make their passwords unique and difficult to crack, and, worst of all, reuse passwords and these attackers can simply take these potential credentials and stuff them into logins in apps around the internet. Often, this works. This is why you should use a password manager to randomize your passwords, change them often, and set an alert on Troy’s website to let you know if a database that contains your email was found on the dark net.
2. Password Spraying: If you’re on this website, you may have gotten here because I’m doing reviews of tryhackme’s CTFs and rooms. On that site you may have gone through one of numerous rooms that require you to utilize wordlists available online and already installed on Kali Linux to run through passwords and see if any works. This is password spraying: in this, the attacker will have a username already and will try to find the password trusting in the fact that users will often use really weak passwords — 123456, p@ssword, pw123 for example. As the UK’s NCSC demonstrated, this is more common than you think.
3. Phishing: Personal story on how yours truly got into cybersecurity: when I was ten, as eBay and PayPal became household names, my parents joined millions of others in taking advantage of the internet to sell unneeded antiques for some extra money. One day my father got a call from his bank asking if he tried to buy a vehicle in Madrid, Spain. As he hadn’t, and after a brief investigation, we came to find out that he had received an email from an attacker acting like they were PayPal and asked my dad to give them his login credentials. Not knowing any better at that time, my dad gave them and the rest is history. Hackers still use this technique to steal a user’s credentials and impersonate them on an app.

How Do You Prevent Broken Authentication Attacks?

Just like with injection attacks, there are key steps that you can take to protect your app against broken authentication attacks. Because broken authentication revolves around a user’s ability to login, you need to make sure to incorporate the following.

First: always, always, always implement multi-factor authentication if possible (though this should always be possible). This will protect against credential stuffing, spraying, brute force attacks, and others. Forcing the user to login with a username and password as well as use of a third-party authenticating agent — such as Duo or Microsoft authenticator — will protect your site (even though it may be extra work for the user to login).

Next, just like with routers and IoT devices, never allow an admin’s account to have default logins. This is a recipe for disaster on your end and an easy in for the attacker.

Finally, set weak password requirements. Make sure your users passwords have a minimum length, use alphanumeric characters as well as symbols, and are changed on a regular basis.