BOLA vulnerability in crAPI

Introduction

In this article, we are going to be looking at the BOLA vulnerability which is short for Broken Object Level Authorization, it is a type of vulnerability which affects API applications , it allows a user to access, modify or delete another person’s information simply by modifying or manipulating the value of an object ID. Keep in mind that BOLA is not just about object ID’s , it can be found in any scenario whereby the application does not properly perform authorization checks to anyone requesting for a particular resource.

It ranks as the number 1 API vulnerability in the OWASP API TOP 10 list.

For example take a look at this URL

https://api.target.com/v2/users/1

If a user changes the value 1 to 2 and is able to view another user’s info, we have a BOLA vulnerability, this example looks pretty easy but is being actively exploited in the wild. Although most web apps now use GUIDs (Globally Unique Identifiers) or UUIDs (Universally unique identifiers) which are more difficult to guess. BOLA occurs because applications don’t fully track a user’s state but rely on IDs and other parameters to identify users of the application.

BOLA can lead to leakage of sensitive information of other users to unauthorized parties and can even lead to the complete takeover of other user’s accounts in some severe cases.

Even with the difficulty in guessing correct ID’s , applications sometimes still leak the obeject IDs or UUIDs which is the example vulnerability we’d be looking at in this writeup.

On the homepage of the crAPI app , there is a button to refresh location, this is where the BOLA vulnerability was found

After clicking the button to refresh our location, using the Burpsuite web proxy for testing applications, i viewed the response

Notice that we can see our vehicle ID :

/identity/api/v2/vehicle/ac4dd7c1-5c70-4aae-b004-47c522adc8f9/location and our information, the vulnerability here is to see if we can access another person’s information simply by changing the vehicle id. I found a vehicle ID by navigating to the community section which shows what other users have posted about.

This is the response from the community page:

/community/api/v2/community/posts/recent

I noticed that the response is leaking too much user information which is a vulnerability in itself (we’ll come back to that in another writeup) but observe that we now have another user’s vehicle ID. Let’s see what happens when we try to replace another user’s ID with our own :

/identity/api/v2/vehicle/**cd515c12-0fc1-48ae-8b61-9230b70a845b**/location

Voila! I can now view another user’s sensitive information, their latitude and longitude which happens to be their real time location simply by changing vehicle ID’s. This is a simple case of how the BOLA vulnerability can be exploited.

Remediation and Prevention

• Any endpoint that receives an ID should properly check if the person making that request with the ID is actually authorized to view what they are requesting.
• Randomized values should be used as ID’s e.g. UUIDs, GUIDs rather than using predictable objects like 1,2,3 etc.
• Authorization mechanisms should be properly tested to be sure they are secure.