Blog

OWASP API Security Top 10 - Broken Object Level Authorization

Broken Object Level Authorization (BOLA) is the top most in the list of OWASP Top 10 API Security threats because of its ease of exploitation combined with its potential for impact as well as the difficulty to defend this threat in an organized way. 

 

Before getting into this vulnerability let us look at what an Object is. Objects typically at the code level could be something like another system, application, file, or data. Best way to control access to these objects is by setting access permissions for them. This allows moderating a user from viewing, creating, editing, or deleting any instance of a particular type of object. Generally, such authorization mechanisms are implemented within the application to validate that one user can only access objects that they should have access to. Within the REST API context, the action on a specific object is typically requested by passing an ID to the API endpoint provided that object level authorization checks are validated. 

 

Let us take a look at a theoretical example of a Banking system where one of the objects that can be defined is an Account Statement. A user having an account with the bank is allowed to access only their own Account Statement. 

 

Consider the following imaginary REST API call to access the account statement of a user with account id 0002366989.

   

    GET /api/v1/account/statement?account_id= 0002366989&start_date=20200601&end_date=20200630 HTTP/1.1

    Host: orangetrustbank.com

    Authorization: Bearer xYghgunm1un89

 

The response for the above call would be the list of money transactions during the specified period. 

 

Assume that there is a loophole in the banking system such that the access control mechanism for account statement objects can be exploited by any logged in user. Incrementing the account_id parameter by 1 and launching the API request again, will give the account statement of a different user. Well, exploiting this issue is as simple as running a script with different account numbers (usually increasing or decreasing the identifiers by 1) to collect the Account statements of different users. It may be possible that this information can be used by criminals to use social engineering techniques like claiming to be a bank personnel and steal credentials of user online banking.

 

In fact, the BOLA vulnerability has been frequently exploited in the wild. A few well known and recent examples include: Verizon, Facebook, T-Mobile, Airtel, Apple Sign Me In and the list doesn’t end.

 

Let us dive into a real world incident to see what exactly happened with Uber.


Uber User Account Takeover

Uber which operates in more than 60 countries and is a popular taxi and ride sharing company. A security researcher found that an API which takes the mobile number or email address of a Uber partner (including riders, drivers, eats) and leaks the UUID in response. This is shown in Figure 1.

Figure 1: Vulnerable API

Similar response would have been observed when an email address was used in place of a mobile number. It is possible to enumerate UUIDs belonging to different users based on phone numbers or email addresses and hence this can be categorized as a BOLA vulnerability. There is another API in Uber which was vulnerable to information disclosure which made the problem even worse. This API consumes the UUID and reveals a user’s private information like access token, location, address etc., among which the access token allows the user account to be hijacked. Luckily, the researcher was responsible and informed the Uber team who quickly fixed the vulnerability.

Figure 2: User Private Details Along with Token

Protection Mechanisms

Exploiting BOLA vulnerabilities look simple but there is no systematic way to prevent or detect such a vulnerability. Ideally implementing the access control mechanism in a perfect way would be the solution. Also, thoroughly evaluating the authorization mechanism to check that the logged-in user has the necessary permissions, also helps build a robust application. There is a common industry recommendation to leverage a mapping (e.g., random string) for the IDs to make it harder to enumerate values for an attacker. However, the REST standard encourages developers to receive many IDs from the client and for developers it is hard to implement access control for multiple objects. Manual code auditing will work in a great way but this has a limitation on resources and does not scale.

 

Some of the vulnerabilities of this type can be tackled by focusing on API testing during the development process. Many of the companies include API tests in their CI/CD processes by automating with tools such as Postman or a direct plugin with Jenkins. If any of the tests fail, the build stops and the issue must be fixed before releasing the build to production. Some upcoming tools like FuzzLightYear support stateful fuzzing which is a better way of testing the REST APIs. With API fuzzing, functionality errors are sought based on fuzzing the values for API parameters. However this may not work to find sophisticated vulnerabilities.

 

When it comes to API threat protection, CloudVector’s innovative approach efficiently detects BOLA type of vulnerabilities by facilitating parameter pinning policies. The protection scheme relies on the unique ability to understand API payload relationships. CloudVector is the first API Detection & Response (API DR) platform to continuously Discover, Monitor, and Secure APIs and API Data.

Sekhar Chintaginjala

Sekhar Chintaginjala

Sekhar Chintaginjala is an experienced information security researcher who brings 15+ years of hands-on knowledge to the CloudVector team. He has proven expertise in the area of vulnerability research, security content development and leading teams for large global companies. At CloudVector, Sekhar is a member of the Security Research team and also leads efforts for new feature development that help protect from API abuses.