Broken Object-Level Authorization

What is Broken Object-Level Authorization?

Broken object-level authorizations (BOLA) is also known as insecure direct object reference (IDOR). This issue occurs when the server does not properly verify if the currently authorized user or an unauthorized user is accessing data to read, update or delete an object to which they are not having the rights.

Types of Broken Object Level Authorization (BOLA

Mainly there are 2 types of BOLA. Those can be carried out if a userID is passed on to the server or an objectID, we will look into both.

Based on User ID

If a userID is passing on to the server in a clear visible manner like in URL, or in request, when we request to access all the resources for a certain user for example −

<https://google.com/get_users_search_history?userID=1234>

After seeing above URL if we changed the userID with someone else's userID, we are not authorized to get the search history of other users but if the endpoint is vulnerable to Broken Object Level Authorization issue means, we can view the search history of other users.

Based on ObjectID

This type vulnerability can also exist because object ID’s are passed to the server when the server does not properly validate if the user is authorised to access that object or not. For example, when a developer needs to implement security function to secure some resources and some not. They might avoid or forget to secure some of the objects which should be secured.

Exploiting Broken Object Level Access Vulnerability

It is easy to exploit this vulnerability once it’s been found. All an attacker needs to modify an identifier in a request and they’ve authorized to get access to objects they shouldn’t be allowed to get.

Let’s discuss it with an example.

Here, we are having a URL that is used to call an API −

https://myemail.com/messages/12345

This API call is used to fetch a user’s private messages. The resource being used is messages. The message is the object that we are referring to the Broken Object Level Authorization and we assume that messages can only be accessed and read by intended recipient.

In API call we have the id of the message 12345. This is an important parameter for an attacker. That id tells to the service which record to return. The API fetch that record from a data store and return it in the response.

Now let’s see the result if we change the id from 12345 to 12346?

Example −

https://myemail.com/messages/12346

If the message with id 12346 was intended for our user, we should be able to fetch it. But if that message belongs to another user, then API should never return it. If we have managed to retrieve the message means, then we have a Broken Level Object Authorization failure.

Another example is passing a POST request to update a resource. We can play with the id in the JSON payload−

{
   "userId": "12345678",
   "oldPassword": "My_0ld_Pa$$",
   "newPassword": "$uperS3CurE"
}

If we were to put any userId in the request and were able to update another user’s information, then we have a massive problem.

Technical Impact

Once we find the vulnerability, we can exploit it in different manners. We can use different HTTP methods on an API. We can use that input parameter or id to update or even delete messages!

What happens if we were able to compromise all Ids and able to delete all stored message. That’s a big impact.