In the previous blog post about API security, we described how to secure an API and introduced the top 10 most critical risks for APIs. This blog post will take a deeper dive into the most critical risk of all: broken object level authorization (BOLA). Based on real-life weaknesses we found during penetration tests, we will cover a few examples and also provide tips and tricks on how to spot and mitigate BOLA vulnerabilities.
What is Broken Object Level Authorization (BOLA)?
IDs are vastly used to reference users and objects in (web) applications. Most of the time, each user has a fixed ID, which serves as a static reference to the user. In contrast to a static ID, usernames, email addresses and other properties could change. The same applies to objects, such as uploaded files, or posted comments. These items receive fixed IDs so that they can be easily referenced. The IDs are often numbers, which are assigned in ascending order. Thus, they are easy to enumerate.
API calls, for example, to request information about the authenticated user, might contain their ID. The ID enables the back-end to determine whose user’s information should be provided in the response. But what happens when an attacker substitutes the ID with one belonging to another user? The API must validate if the attacker is authorized to request the information associated with the provided ID. If the API fails to correctly validate this or, even worse, doesn’t validate whether a request is authorized at all, the attacker is able to access foreign data.
This scenario is an example of a BOLA vulnerability. The vulnerability is also known as IDOR (Insecure Direct Object Reference). The API doesn’t check whether a user is authorized to access a specific resource, usually referenced by an ID. Thus, an attacker can replace the ID in an API request to access a resource belonging to another user. The outcome of this vulnerability can be severe. It can include, among others, information disclosure, unauthorized modification, or loss of data.
Do OAuth 2.0 or FAPI prevent BOLA?
OAuth 2.0 is the industry standard for delegated authorization and it is widely used for API authorization. It utilizes access tokens, which are most commonly included into HTTP requests via the "Authorization" header. For high-security APIs, such as in “Open Banking”, it may be necessary to comply with the financial-grade API (FAPI), which defines more complex high-security profiles for OAuth 2.0. Learn more about FAPI in our German blog series.
Simply relying on OAuth 2.0 or even the high-security FAPI profiles does not prevent BOLA vulnerabilities. The goal of an OAuth 2.0 or FAPI protocol flow is to ensure that only authorized parties are granted access to a resource. However, it is the API’s responsibility to decide whether to grant or deny the access to a specific ID based on the provided access token. If the API does not check if an access token grants permission to the ID provided in the request, the API is vulnerable to BOLA.
Common BOLA Vulnerabilities Found During Pentests
During API penetration tests for our customers, we often encounter BOLA vulnerabilities. Even though they seem to be easy to spot and easy to mitigate, extensive user and role concepts often result in edge cases or the necessary authorization checks are simply overlooked. In the following we want to give you realistic examples of BOLA vulnerabilities based on three real-life vulnerabilities we identified in penetration tests for our customers. Even though these three vulnerabilities were fixed shortly after our debrief with the customers, we slightly altered the scenario, for confidentiality reasons. Thus, no connection to the particular customer can be established, while not altering the technical aspects.
BOLA Example 1: Marketplace
Scenario: In our penetration test, we evaluated a large marketplace providing merchants the possibility to create a shop, in order to promote and sell items. The shop owner has administrative privileges which allow them to see, modify and delete account information, item listings and to view the trading history. All these actions can be issued either directly with API calls or indirectly through the web frontend, which in return issued the API calls. The API endpoints all expect an ID, to determine on which object to operate on. Fortunately, the APIs implement proper checks and are not vulnerable to BOLA.
Vulnerability: However, we found that one further API endpoint for creating new shop employees with the same administrative privileges as the shop owner. This endpoint also expected an identifier – the shop ID. Unfortunately, this API did not validate whether the user, which issues the call, is authorized for the specified shop or not. Even worse, the shop ID was a consecutive number, which was increased by one for every newly created shop. Thus, an attacker could create administrative users for an arbitrary shop by including the ID of the targeted shop in the API request. Ultimately, this enabled them to eavesdrop on the trading history of other merchants or, even worse, to overtake their shops. Even though all API endpoints, besides this one, had effective BOLA countermeasures present, the possible impact was severe.
Listing 1 illustrates a request to the vulnerable API endpoint. A bearer token, which was issued for an administrator of the shop with the shop_id 904, is used for authorization. However, the API call contains shop_id 903; thus creating a new administrator account for a different shop. Afterwards, the attacker could log in to the new account and access the data of the shop with the ID 903.
POST /sso/v2/users HTTP/1.1
Authorization: Bearer eyJ0e[...]2xAKB
[...]
{
”firstname”: ”New”,
”lastname”: ”Employee”,
”username”: ”NewEmployee3”,
”email”: ”NewEmployee3@example.com”,
”shop_id”: 903,
”password”: ”supersecurepassword”,
”administrator”: true
}
API Request to create a new Employee – The shop_id can be altered in order to create an Employee for another shop. (Listing 1)
BOLA Example 2: Video Streaming Platform
Scenario: A streaming platform offers APIs to gather information, for example, about the watch history, bookmarks and information of an authenticated user. The watch history and bookmarks API endpoints use a random ID as an identifier for the authenticated account and validate if this ID fits to the account associated with the access token used.
Vulnerability: However, the account information endpoint used the email address, specified in the body of the request, as an identifier instead. This endpoint did not validate at all, whether the user is authorized to request information about the referenced account. Thus, an attacker could include arbitrary email addresses in the body of the request in order to gather information about other users, such as their names and addresses.
BOLA Example 3: Flawed Implementation of a BOLA Countermeasure
The previous two examples showed that it can be devastating if an attacker is able to spot a BOLA vulnerability and the identifiers are easy to enumerate, for example, when they are consecutive numbers. To make it impossible for an attacker to predict or guess other valid identifiers, random identifiers such as the standardized UUID (universally unique identifier) version 4 can be utilized.
One of our customers had the right thought in mind, however, the developers utilized UUID version 1. While this identifier is, just like the version 4, universally unique and perfectly fine for many scenarios, it lacks one important characteristic. Unlike version 4, it is not random. Both UUID versions consist of five parts separated by a “-”, for example, 113a25d0-1cc2-11ed-b3a0-f1f504fcfbe0. However, the last four parts are static for UUIDv1 as they reference the machine, which created the UUID. The first part is not static, but it also does not contain any randomness. It is generated based on the current time and date and is therefore consistently increasing and predictable. An attacker knowing the machine constructing the UUID and the rough time of its creation could very easily guess the correct UUID, allowing them to predict the UUID for a specific account.
How to Spot and Mitigate BOLA
Spotting a BOLA vulnerability is often as simple as substituting one identifier with another one, as shown with the previous examples. Other kinds of tests are highly dependent on the particular API and cannot be generalized. Developers should evaluate which API endpoint utilizes which identifiers. Afterwards, they can then write test cases and implement them in the API lifecycle, in order to automatically test for BOLA vulnerabilities. However, for extensive role concepts and scenarios, more thorough manual testing is necessary.
The best way to mitigate BOLA is, similar to other vulnerabilities such as Injection, to never trust any data provided by a user. Before responding to an API call, the endpoint has to validate if the user is authorized to issue actions regarding a specific identifier. Sometimes it is even possible to remove the identifier from a request and extract it from the access token, for example, when a signed JWT is used for this purpose.
Another countermeasure, not to be ignored as shown in the third example, is to use non-predictable identifiers. The standardized UUID (universally unique identifier) version 4, is the perfect example for such a random identifier, which even provides a very high entropy of 122 bits.
Our Experts Develop the Optimal Solution for You
APIs – OAuth – FAPI
Are you faced with the decision of how to best protect your APIs and customer data? Or are you already using OAuth and wondering if your implementation is secure?
We will be glad to advise you; contact us for a no-obligation initial consultation. Thus, we are at your side with the following services and solutions:
IT Security Consulting | Training | Penetration Tests
Don't hesitate and find your way to secure APIs with us. We look forward to supporting you with your projects.
Your Contact for OAuth and secure APIs
Dr. Christian Mainka
christian.mainka@hackmanit.de