Broken object-level authorization (BOLA) is a vulnerability that grants users access to data without them having the necessary privilege.
Broken object-level tops OWASP's API Security Top 10 2023. As a result, it's important to test your application for this type of vulnerability.
In this post, you'll learn about what broken object-level authorization is. We'll also look at some examples of this vulnerability and how to prevent each one.
What Is Broken Object-level Authorization?
What is broken object-level authorization in Kotlin and how do you prevent it? In order to answer both questions, we'll walk through an example of a todo app API. This example API has an endpoint that returns a list of all tasks created by a specific user. Also, each task has an owner ID (user-id) that helps the system know who that task is for.
So, let's say the URL for our endpoint for fetching todo tasks looks like this:
https://example.com/api/todos/{user-id}Where user-id is the key for fetching all tasks belonging to a specific user.
Now, if a user is able to guess a valid user-id and the system returns the tasks for the original owner of those tasks, we can say there's a potential broken object-level authorization vulnerability.
To further explain what BOLA means, let's first take a look at what object-level authorization is.
According to OWASP, "object level authorization is an access control mechanism that is usually implemented at the code level to validate that one user can only access objects that they should have access to."
From the above definition, we see that the major cause of broken object-level authorization is poor code-level validation.
In BOLA, the attacker takes advantage of an application's features and endpoints that do not perform proper verification of a user's authority before executing a task and returning data. For example, an app that's vulnerable to broken object-level authorization may allow a user to read private data like messages for another user by manipulating request parameters.
Examples of Broken Object-Level Authorization in Kotlin
In this section, we'll look at three examples of broken object-level authorization vulnerabilities in Kotlin. In addition, we'll also walk through how to prevent each vulnerability.
Remember our todo example app API from earlier? We'll be referring to it in these examples. The Kotlin framework Ktor powers the API. In addition, the API stores user data in an SQL database, and we can query the database for specific data using user inputs.
1. Read All Tasks for Specific User
The normal flow of the example app requires that a user can only view a list of tasks they own. That is, the tasks a user creates.
Our example API has an endpoint that returns all tasks for a specific user. As a result, there's code that reads the data from the tasks table on the SQL database. This code depends on a user-id parameter from the API URL. Then, it uses the value for user-id in a query as follows:
todoResult = stmt.executeQuery("SELECT task_title FROM tasks WHERE id=$userId;")In a vulnerable app, an attacker can modify the value for user-id to a valid ID for another user in our database so that the above code will return all tasks for that user. This is an example of broken object-level authorization because there's unauthorized access to private data.
Prevention
You can prevent this flaw by validating that the user sending the request to the API is authorized to see the task.
We can do this by authenticating the user and sending session identifiers like access tokens as part of the request. However, enforcing only authentication to an API endpoint is usually not enough to prevent access to sensitive data without privilege. In fact, leaving restrictions at authentication only can increase the risk of broken object-level authorization. For example, only checking for authentication may mean that an attacker can authenticate as one user and access data for another user. The following code demonstrates the flow for validating a user before returning data:
if(currentUser.user_id == request.user_id) {
return tasks
} else {
return errorMessage
}
2. Read Single Todo Item (Task)
Another feature of the todo app API is an endpoint that returns full details about a specific task. Again, this endpoint depends on an identifier that's part of the URL. The normal flow is that users can only view full details of a task they own.
The following is the URL for the endpoint in this example:
https://example.com/api/detail/{task-id}Here, task-id is the unique key for querying the database.
An attacker can send random values for task-id until the API returns data when one of the values matches a valid task ID. After that, the attacker will gain access to the full details of the task even though they are not the owner.
Prevention
This type of attack requires the attacker to send multiple requests to the endpoint until the application returns valid data. Hence, in addition to validating whether a user is authorized to see a task, we can reduce some of the risks of this type of attack by rate-limiting our API endpoints.
3. Admin-Only Feature
In this third example, we'll consider an endpoint for admins only that returns a list of all users on the todo app service. This list contains sensitive data like the names and emails of all users. That means if just any user gains knowledge of this endpoint and can access it, then data could be exposed.
For example, the URL for this endpoint is as follows:
https://example.com/api/admin/users/{admin-uid}The attacker may manipulate the value of admin-uid till they get a valid one. If we don't have enough validation in our code, this API will return the list of users. The attacker can then proceed to use this data for malicious things like phishing and sending scam emails.
Prevention
A good fix for this vulnerability is making sure that the request is authenticated. It's also important to verify that the authenticated user ID is the same as the value for admin-uid.
In addition, if your application has extra fields in the database that defines user privilege, also verify that the current user has admin privilege. In addition to the above method, API rate-limiting can reduce risk here too. This helps by reducing the number of requests the attacker can send to the endpoint before guessing a valid value for admin-uid.
You can also prevent broken object-level authorization include using values that are hard to predict for user IDs and other identifiers. However, you should combine this method with validating a user.
Summing Up
Broken object-level authorization is a type of flaw, usually in the code of an application that can lead to exposure of private user data. A Kotlin application, like an API built with Ktor and SQL, may be vulnerable to broken object-level authorization attacks. Attackers may perform such attacks by manipulating URL and request parameters.
From our examples, the most straightforward method for preventing broken object-level authorization in Kotlin is by validating who a user is and determining whether they can or can't view the data they are requesting. You can do this using a regular if statement.
One final recommendation: In order to reduce the risk of BOLA, you should test your API rigorously for unauthorized access to endpoints and data.
This post was written by Pius Aboyi. Pius is a mobile and web developer with over 4 years of experience building for the Android platform. He writes code in Java, Kotlin, and PHP. He loves writing about tech and creating how-to tutorials for developers.
