Understanding Broken Object Level Authorization (BOLA) Vulnerability in API Security

Want to know how to secure your applications? You're in the right place. In this article, we will discuss a critical vulnerability that ranks number one in the OWASP API top 10 2023 - Broken Object Level Authorization, also known as BOLA. We will explore the concept of BOLA, its implications, how it can be exploited, and how to secure your applications against it.

Authentication vs Authorization

Before diving into BOLA, let's clarify the difference between authentication and authorization.

Authentication is the process of verifying one's identity, while authorization determines what actions or resources a user is allowed to access. To illustrate this, think of checking into a hotel. Presenting your identification documents is authentication, while receiving a key or key card that grants access to your room and other facilities is authorization.

Understanding Broken Object Level Authorization (BOLA)

Broken Object Level Authorization occurs when an application fails to properly restrict access to specific objects. To put it simply, if an application allows a user to manipulate the object identifier (ID) in a request and still returns information from a different object, it indicates a BOLA vulnerability.

For example, let's consider a web application where the account page URL includes the user's ID, such as /account/2551 where 2551 represents the user's ID. If an attacker can change this ID to a different account ID and still retrieve information from that account, it signifies a BOLA vulnerability.

It's worth noting that BOLA is similar to Insecure Direct Object Reference (IDOR) vulnerability. In the context of APIs, BOLA is often used interchangeably with IDOR. If you are familiar with IDOR, you already have a head start as they essentially refer to the same vulnerability.

Implications of BOLA Vulnerability

The implications of BOLA vulnerability can be severe. By exploiting this vulnerability, an attacker can gain unauthorized access to sensitive information or perform actions that they are not authorized to perform. This can lead to data breaches, unauthorized modifications, or even complete system compromise.

In the example mentioned earlier, if an attacker can change the object ID in the request and retrieve information from a different account, they could potentially access personal data, financial information, or any other sensitive data associated with that account. This can have serious consequences for both individuals and organizations.

Exploiting BOLA Vulnerability with crAPI

To demonstrate BOLA in action, we will use a vulnerable API called "crAPI." In this example, we will create a new account, add a vehicle, and manipulate the object ID to exploit the BOLA vulnerability. Please note that this API is specifically designed for practicing attacks and should not be used in production environments.

It's important to note that BOLA vulnerabilities can be exploited in different ways. One approach is to gather object IDs from other accounts or parts of the application. This highlights the need for a defense-in-depth approach, as even a single leaky API can expose object IDs for exploitation.

In our example, we will create a new account (start locally: http://localhost:8888) and add a vehicle to it. Please check your email for the VIN and PIN code of your vehicle using the MailHog web portal (http://localhost:8025/).

Then, in the next steps you should try out:

1. Once we have added a vehicle to our account, we can observe the request made to the API. Click on refresh locationto review your API request.
2. Observe the request made to the server, which includes the vehicle ID (for example, GET /identity/api/v2/vehicle/vehicle_ID/location
3. Create a second account and add a vehicle to it (or if you're lazy, just check one of the posts sent on the Community page).
   It's important to note that even if the IDs are not easily guessable, we should always consider defense in depth. A single leaky API or engineer oversight can expose the IDs, making the system vulnerable.
4. Replace the vehicle ID in the copied request with the ID from the second account.
5. Send the modified request and observe the response.
   • If the response indicates unauthorized access or a 400 erroe, the system is secure.
   • If the response includes the requested vehicle's ID and sensitive information, the BOLA vulnerability is present. Which is the case here.

You'll discover that the API leaks sensitive information, such as the latitude and longitude of the vehicle, when we manipulate the vehicle ID. This demonstrates the broken object-level authorization vulnerability. Go to try it for yourself!

Mitigating BOLA Vulnerabilities

To mitigate BOLA vulnerabilities, developers and organizations should follow secure coding practices and implement proper access controls. Here are some key steps to consider:

1. Implement Role-Based Access Control (RBAC): Use RBAC to define and enforce access permissions based on user roles. This ensures that users can only access the objects and perform actions that are authorized for their role.
2. Validate and Sanitize User Input: Always validate and sanitize user input to prevent any manipulation of object IDs or other parameters. Implement strict input validation and ensure that only valid and expected values are accepted.
3. Implement Proper Authorization Checks: Ensure that authorization checks are performed at the appropriate points in the application flow. This includes checking the user's permissions and verifying that they have the necessary privileges to access or modify specific objects.
4. Use Unique and Unpredictable Object Identifiers: Avoid using sequential or easily guessable object IDs. Instead, generate unique and unpredictable identifiers for objects to make it harder for attackers to exploit BOLA vulnerabilities.
5. Regular Security Testing and Code Reviews: Conduct regular security testing (for example, with API security testing tools like Escape), including penetration testing and code reviews, to identify and address any potential BOLA vulnerabilities. This helps in identifying and fixing security flaws before they can be exploited.

Conclusion and further resources

In conclusion, Broken Object Level Authorization (BOLA) is a critical vulnerability that allows unauthorized access to objects within an application. Understanding BOLA and its implications is crucial for developers and security professionals to ensure the security of their APIs. Here is the selection of the best API security testing tools for that.

If you are interested in exploring BOLA further, you can check out the "Completely Ridiculous API" project, which is an open-source project designed for practicing attacks. Additionally, don't forget to check out our API Security Academy.

We also prepared a practical and ungated API security checklist dedicated to security professionals and developers.

By following secure coding practices, implementing proper access controls, and conducting regular security testing, organizations can mitigate BOLA vulnerabilities and protect their APIs from unauthorized access and data breaches.

We hope this article has provided you with a comprehensive understanding of BOLA and its significance in API security. If you have any questions or would like us to cover specific topics or tools in future articles, please reach out to Escape team. Stay secure!