How To Test BOLA by Parameter Pollution Using Akto

The vulnerability allowed attackers to add an additional parameter to the login request, which forced the server to ignore the user's password and allow them to log in without it. This vulnerability affected millions of users and was quickly patched by Uber once it was discovered.

What is Broken Object Level Authorization?

Broken Object Level Authorization (BOLA) is a type of security vulnerability that occurs when an application fails to properly check the permissions of an authenticated user attempting to access a particular resource or object. This can allow an attacker to access or modify sensitive information or functionality that they should not be able to.

What is BOLA by Parameter Pollution?

BOLA by Parameter Pollution is a type of Broken Object Level Authorization vulnerability that occurs when an attacker is able to manipulate or inject multiple instances of the same parameter in the request to bypass authorization checks and gain access to unauthorized resources and objects.

When a backend server receives an API call with multiple instances of the same parameter, the handling varies depending on the specific backend server. Some servers will only consider the first value, while others may prioritize the second value, and some might concatenate both values with a comma as a separator. These variations can introduce security vulnerabilities through which authorization checks could be bypassed.

For example, in the realm of microservices, there is a possibility that the auth-service, which runs on Tomcat, might retrieve the first variable, while the cart-service, powered by PHP, could retrieve the second variable.

How to Manually Test for it

• Find an API endpoint that performs an action based on the JSON data in the request. The action may or may not include user input.

• Analyze the parameters in the JSON body and check if any of the parameters are unique to each user. The parameters could include email, userID, cartID, etc., and could be predictable, for example, userID: 23 can be incremented to 24.

• Inject the same parameter multiple times, but with different values, to analyze the response. If the response contains the data of another user, it means the API endpoint is vulnerable.

Practical Demonstration

Target Application: OWASP Juice Shop

I have created two accounts:

• The first account (attacker): test@akto.io, BasketID: 26

• The second account (victim): test2@akto.io, BasketID: 27

OWASP Juice Shop has an endpoint that enables users to add products to their cart. This endpoint sends three parameters: productId, BasketId, and quantity.

Endpoint: /api/BasketItems/

To view your basket ID, follow these steps:

1. Right-click on the page and select "Inspect element."

2. Navigate to the "Storage" tab.

3. Click on "Session Storage."

4. Look for the "bid" value, which represents your basket ID.

From the above screenshot, we can see that the bid value is 27 for the victim’s account.

HTTP Parameter Pollution Exploitation

To exploit BOLA via parameter pollution, add another parameter to the JSON body called "basketid," but change the value to 27, which is the victim's basket ID. Basically, we are attempting to add a product to the victim's basket.

The server responded with "success" instead of throwing an unauthorized error. Additionally, we can see that the basketid in the response is 27 instead of 26. This indicates that the exploitation was successful.

We can confirm that the product has been added to the victim's basket. We were able to perform an unauthorized action on the victim's behalf simply by assigning the same parameter that the server was expecting but with a different value.

Problem: You’re Lazy!

What is shown above seems interesting and easy to test, until instead of one endpoint, you have hundreds of API endpoints. This a very tedious task as well as time-consuming.