Vulnerabilities in authentication and authorization

Authentication vs authorization

Most people don’t fully understand the difference between authentication and authorization and regularly use them interchangeably, despite having fundamentally different functions. Authentication is responsible for recognizing the user, and its key task is to make sure the current entity sending a request is the same entity that has existed previously. For example, a simple login mechanism or password recover procedure. Authorization, on the other hand, manages privileges and permissions for clients, guests, users, and admins. Despite their different functions, it doesn’t usually make sense to talk about authentication and authorization separately, since they are both closely connected in a continuous cycle. Authorization needs proper authentication to operate reliably, and authentication without proper authorization serves no purpose.

Security failures in authorization and authentication

Unfortunately, security vulnerabilities associated with authentication and authorization are extremely common and regularly exploited by hackers. Solutions or mechanisms which have been poorly implemented can lead to serious security issues, and the process of recovering from a breach is not only financially costly, but harmful to your company’s reputation as well. OWASP is a non-profit group that has been creating well-regarded top 10 lists of the most common security vulnerabilities for years, and even keeps them frequently updated. So it’s no surprise that authentication and authorization vulnerabilities regularly make these lists. In the past, authentication vulnerabilities were grouped under the umbrella of Broken Authentication, but in the new 2021 list they are now grouped under Identification and Authentication Failures, while vulnerabilities related to authorization can be found under Broken Access Control.

So now let’s take a look at some examples to get a better understanding of what these various vulnerabilities can look like.

Authorization – Broken Access Control

Example 1: Insecure Direct Object Reference (IDOR)

Insecure Direct Object References (IDOR) occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability, attackers can bypass authorization and access resources in the system directly, for example, database records or files.

Imagine a social network application. After registering, an attacker can see that they can access their profile on the /profile?ID=120 endpoint. So now they can assume there are at least 119 other profiles and can try to guess another user’s ID, say /profile?ID=110. If that returns another user profile, then the application is vulnerable to IDOR, and this can lead to more serious issues such as changing another user’s password, deleting their account, etc.

Example 2: Broken Object Level Authorisation (BOLA)

Broken Object Level Authorisation (BOLA) and IDOR are pretty similar. You could even describe BOLA as “IDOR in APIs”.

The scenario here is almost the same here as in the IDOR example. The only difference is that the attacker communicates with the API and forges requests to it.

If the attacker gets responses and can leak different users’ profile data, then the API is vulnerable to BOLA.

The responses are usually in JSON format.

Prevention

The first and simplest solution is to make sure developers plan their code more consciously. To maintain the system in a consistent and safe manner, it is essential to minimize (if not completely avoid) mistakes in the code responsible for access control on the server-side application. This prevents an attacker from being able to modify the access control check. Unfortunately there isn’t a single trick or formula to prevent access control vulnerabilities, but here are some useful principles and tips that will help:

• Force all requests to go through access control checks

• Provide only the minimum necessary access

• Test the application multiple times and in repeating cycles

• Set the privileges properly from the beginning

• Do not trust in obfuscation

• Use logging systems to monitor unusual behavior and alert the appropriate teams if necessary

• Use rate limit algorithms

You can find more details about authorization vulnerabilities from OWASP here.

Now let’s move on and take a look at some examples of vulnerabilities on the authentication side of things.

Authentication – Identification and Authentication Failures

Example 1: Automated Brute force

A brute force attack is when a hacker attempts to guess a user’s login credentials manually without using any software, often by trying common passwords. If the application doesn’t have a lockout system or any rate-limiting rules, the attacker could also use a script that tries passwords extremely quickly.

Let’s imagine an attacker obtained the username of an existing user, but they don’t know the intended victim’s password. They might try several passwords manually and realize the application allows them to do so without any restriction.This means they can use an automated script to do their manual labor for them. The script will use a preloaded list of common passwords to try to log in, and if the victim doesn’t take security seriously an chose one of these common passwords, the attacker will eventually find the correct guess.

Example 2: Mass Assignment

When we assign values to multiple attributes all at once, it is known as Mass Assignment. If these values are coming from a user, then the list of attributes should be properly validated, otherwise the attacker might be able to also set the values of private properties.

Say there’s an embedded registration form on a casino web application. The only values the client can set on the form are username and password, but on the backend, the application generates the user instance with a default cash value attribute of 0. So the form generates the following POST request:

If the attacker can also inject this cash parameter, they can manipulate the amount of cash they’re credited without depositing any money.

Prevention

Like with IDOR, there is no one “golden rule” that will prevent authentication vulnerabilities 100% of the time, but there are of course principles and tips you should know:

• Force users to create strong passwords (length, character usage)

• After multiple failed login attempts, lock out the user account

• Use CAPTCHA to defend against bot attacks

• Use logging systems to monitor unusual behavior and alert the appropriate teams if necessary

• Implement re-authentication and multi-factor authentication in key functions

• Manage secure password resets

• Do not let sensitive accounts authenticate to front-end user interfaces

Like earlier, you can check out the OWASP website for more technical details on these vulnerabilities.

Summary

Without properly implemented authentication and authorization, the reliability of web applications is significantly reduced, and it’s not easy to stay up-to-date with the ever-changing threat landscape and potential defenses. This is why cybersecurity training is becoming even more important in the software development process. One of the most effective starting points for securing applications is to build and maintain a strong security culture, and that includes regular training. Making sure your team has the right security skills and mindset will help to ensure application integrity and decrease security risks. It is also important to engage with the community and exchange knowledge, which is exactly what happens in the OWASP community.