Welcome to this new episode of the OWASP Top 10 vulnerabilities course. Today, you are going to learn about Broken Authentication and Session Management.
Last time, I explained the Injection vulnerability. New upcoming posts will teach you the remaining OWASP Top 10 vulnerabilities. Consider subscribing to the Friday Newsletter.
What is Broken Authentication and Session Management?
We can’t talk about Broken Authentication without defining Authentication in the first place. This will give you a solid understanding of the big picture.
What is authentication?
In the context of Application Security, Authentication is the process of validating that the identity accessing an asset is the one it claims to be. For example, when you log in to your email account, you provide a username and password. The system then validates these credentials. If they are correct, the system lets you in. Otherwise, your authentication doesn’t succeed.
Notice that the identity can be another computer system as well. For example, when you connect to an HTTPS website, your browser authenticates the website using a Digital Certificate as part of a TLS handshake.
What is session management?
If you had to provide your credentials whenever you click on a page within your email account, it would be impractical. Thus, the identity receives a session after it logs in. It typically lasts as long as the identity is connected to the asset. Once the identity logs out, the server destroys the session.
What could go wrong?
From what we explained above on Authentication and Session Management, you can start thinking of scenarios where they can be broken. In fact, implementing authentication requires a set of features like the sign up, login, logout and password reset features. We will now explore what features support Authentication in-depth. Then, we will learn what vulnerabilities can target some of them.
Some Features which support Authentication
Authentication includes many features, such as:
- Sign up: Allows users to register their accounts on the system.
- Login: Allows them to access it.
- Password Reset: Helps them recover their credentials.
- Session token: Maintains a session of the user with the system. It can be a cookie, a JSON Web Token, a Bearer or other variations.
- Multi-Factor Authentication (MFA): Increases Authentication security by adding other factors such as a token, an SMS, physical biometrics such as fingerprints, etc.
If not securely developed, each feature can introduce its own Authentication vulnerabilities and weaken the overall Authentication security. For example, compromising the Login feature using a SQL injection would lead to a full Authentication compromise, especially if you can log in as an administrator.
Broken Authentication and Session management vulnerabilities
In this section, we are going to explore the following Authentication features and learn some ways of attacking each one of them.
Weak or default passwords
If the system doesn’t enforce a strong password policy, there is a high chance that users will use weak passwords. Besides, if the application doesn’t protect against rate limiting, a malicious user can brute force credentials in the hope of finding valid ones.
Sometimes, the software ships with default admin credentials, which are publicly available. If they remain upon installation, any user can log in to the system as an administrator. You can see this in action on the OWASP Top 10 Broken Authentication hands-on tutorial.
Authentication protects certain features from unauthorized access. Unfortunately, developers forget to put such features behind the Authentication layer. Therefore, any user can directly access them by performing forced browsing.
Broken password reset
There are many Password Reset can be vulnerable in many ways, depending on how the password is restored. The most popular implementation is a password reset link. In this case, you receive a random reset token which the server generates and ties to your email. Unfortunately, it can be vulnerable in many ways, such as:
- If there is a possibility to specify many receiving emails, the system can mistakenly send the reset token to all specified emails.
- If the application builds the password reset link based on user-controlled data, like the HTTP Host Header, an attacker can hijack the password reset token using a malicious Host Header pointing to his website.
Two-Factor Authentication, or 2FA for short, increases security by adding another verification step. For example, the application might send you a unique code via SMS. However, the verification response that the server sends can be modified on the client-side. If the application’s front-end relies on it to grant access, a malicious user can modify the response and bypass the verification. We will cover other examples in the Broken Authentication and Session management real-world attacks section.
Broken Authentication and Session management real-world attacks
The following is a list of real-world Authentication vulnerabilities:
Weak or Default credentials example
In this report, the hacker found a publicly accessible SAP server with default credentials belonging to Starbucks.
I also reported an authentication issue to OWOX, where a Grafana instance was running on port 3000 without any authentication. Simply browsing to the right service allowed me to access all their dashboards.
Password reset example
In this report, the hacker reported that he could hijack the victim’s password reset token by manipulating the HTTP Host Header.
In this report, the bug bounty hunter found that the Referer HTTP Header leaks the password reset token if the victim clicks on a link from the resulting password reset page. Although the exploitation is hard, it is still a valid issue which highlights how Authentication can break under many attack vectors, depending on the context.
Two-Factor authentication bypass example
In this critical report, the bug bounty hunter could substitute the victim’s token with his, allowing him to bypass Two-Factor Authentication.
Another common issue with Multi-factor authentication is the lack of rate limiting and the short length of the token. This report shows how the ethical hacker could guess the victim’s Two-Factor authentication token, also called a one-time password (OTP).
Impact of Broken Authentication and Session management
As you saw in the previous sections, especially in the real-world attacks section, Broken Authentication and Session management can be very dangerous. In fact, it compromises how an application authenticates an identity and it leads on account takeovers. Depending on the sensitivity of the asset and the compromised level of privilege, it can lead to serious business loss.
How to prevent Broken Authentication?
As you learned from the previous sections, there are many vulnerabilities which lead to Broken Authentication and session management. It would be impractical to enumerate all the instances. However, the following are the minimum security measures that you should implement whenever you develop an authentication feature.
Strong password policy
You should always enforce a strong password policy for your users. Such policy should require a minimum password length of 8 characters and include lower case, uppercase, digit and symbol characters. A plus would be to check the password against a list of well-known password dictionaries like this one.
Avoid injection issues
Always validate user input before processing the login request. If there is an injection vulnerability in one of your authentication features, your primary line of defense will be compromised.
Protect against brute force attacks
Implement rate-limiting against automated login attempts to prevent password guessing attacks. You can use captchas, account lockouts or Multi-Factor authentication.
You can browse the following OWASP Broken Authentication Cheat Sheet for an exhaustive list of security measures which you can apply according to your needs.
And that’s it! Hopefully, you’ve learned something new. If you enjoy learning on this blog, make sure to subscribe to the newsletter below. We will send you updates each Friday!