Broken Object Level Authorization

According to Gartner, by 2022 application programming interface (API) attacks will become the most-frequent attack vector. There are several surveys that point towards the fact that 2022 will be the year of API security. Threat actors are increasingly turning their attention towards APIs as an attack vector and will undoubtedly develop and use better tools and advanced methods of exploitation. Threat actors are no longer only relying on automation to exploit injection-based vulnerabilities but are increasingly moving towards developing new approaches to exploit business logic vulnerabilities. One of the most common such attacks is Broken Objection Level Authorization (BOLA). This vulnerability is at the top in the OWASP API top ten.

What is Broken Object Level Authorization (BOLA)?

According to the Open Web Application Security Project (OWASP), Broken Object Level Authorization (BOLA), also referred to as Insecure Direct Object Reference (IDOR), is the most severe API vulnerability ranking at the first place in the top 10 list.

A Broken Object Level Authorization issue occurs when the server does not properly check if the currently logged-in user or even a logged-out user can read, update or delete an object to which they do not have the rights or access to. Lack of authorization check by the server leads to BOLA vulnerability.

There are several ways to carry out BOLA attacks but the most typical method involves an attacker substituting the identifier of their own resource in the API call with an identifier of a resource belonging to a victim user. The lack of proper authorization checks at the server allows attackers to access the specified resource and perform read/write operations.

An example of this would be, a user with a read-only role in an organization being able to perform write operations or access a privileged resource that only the admin user role is configured to have access to.

The Main Types of Broken Object Level Authorization

There are two main types of BOLA. These types of vulnerabilities can occur because either a user identifier is passed on to the server to gain privileged data, or in the form of passing an object identifier to the server for gaining access to the privileged data.

User ID based BOLA

Let’s explain this with an example. Consider a GET request sent to the server:

https://sampledomain.com/get_user_configuration?userID=100

If we are logged in as userID 100, then we obviously should be able to access the user configuration of userID 100. However, if we replace the userID 100 with 101 or any other victim userID, we should not be able to access those users’ configuration. When a broken object level authorization issue arises, we would be able to access other user’s data after changing the userID.

To solve the above problem as developers, we need to check if the currently logged-in user is allowed to access those objects. In the above example we need to check if the userID from the GET parameter is the same as the userID of the object’s owner. If the userID from the GET parameter does not match with the ownerID of the object then the user is shown a 401 unauthorized response code, implying that the user is not authorized to access the resources.

Object ID based BOLA

This type of vulnerability can exist when an attacker passes the objectID to the server and the server does not properly check if the user is authorised to access that object.

For example, in organization X there are 15 files on a shared drive and the admin can access all the files, but there is a read-only user role that is configured to only access the file with file ID 12. Therefore, when this user tries accessing the file with ID 12, a GET request is sent to the server:

GET file.php?id=12

Here, if this user changes the id parameter value from 12 to 10, the user should not be allowed to access the file with id 10. However, if the user is able to get a 200 Ok response to the sent request with id set as 10 and is able to access that file, then that is evidence of broken object level authorization vulnerability.

This issue usually exists because of two reasons – the lack of security control, and human error. Since there are APIs that handle both sensitive and non-sensitive data, some requests should have mandatory authorization checks and other API endpoints shouldn’t. This makes it easy to miss a check while writing code.

How to Protect Your APIs From BOLA Vulnerabilities

Authorization is the biggest challenge when it comes to a BOLA vulnerability. Therefore, this issue is usually mitigated at the time of development. Here are some of the effective steps to protect your APIs from BOLA vulnerabilities.

Use of UUIDs

BOLA attacks often happen when a threat actor is able to guess an object or user identifier leveraging auto-incrementing identifiers. To protect your APIs from BOLA vulnerabilities, it is best to avoid using auto-incrementing identifiers and instead use random identifiers when creating and accessing APIs.

These identifiers, which are commonly referred to as UUIDs, are designed specifically to be difficult for threat actors and unauthorized users to guess. UUIDs are made up of a combination of letters, numbers, and symbols that have no pattern, making them impossible to guess. Using UUIDs minimizes the risk of tampering of GET requests to access unauthorized data by changing the user id or object id.

Enforcing Authorization Mechanisms.

Securing your APIs from BOLA attacks requires a strong authentication, but also a robust authorization. Having a centralised authorization solution that you can re-use for every sensitive object will be helpful. Implement this authorization check properly and ensure that it relies on user policies and complex user hierarchies. Write tests to evaluate this authorization mechanism and do not deploy anything that doesn’t pass the tests.

Rigorous Testing of the Business Logic.

BOLA vulnerabilities often occur due to unfound critical flaws in the design of the actual functionalities of your APIs, rather than threat actors using complex exploits to break into the systems. That’s why it’s critical to rigorously test the business logic of your application to spot vulnerabilities that are impossible to reliably address upon each release, with automated tools and vulnerability scanners.

Relying on IDs from JWT tokens.

Instead of sending the user identifier as a parameter, we should use an auth token such as JWT (JSON web token) and extract the user identifier from the JWT token.

In Conclusion

Broken Object Level Authorization (BOLA) is a severe vulnerability and the potential impacts are enormous. BOLA vulnerabilities are becoming ever more prevalent as functionalities of applications increase, systems are getting more and more complex with varying user hierarchies in place, and simultaneously more APIs are built. Therefore, making sure your APIs are not vulnerable to BOLA attacks has become challenging.

The real source of this vulnerability is traced to trusting the data that is passed to the API by the user. Therefore, object and user level authorization checks should be enforced in every API endpoint that receives an object or user identifier and performs any type of action. The authorization checks should validate that only the authorized users are granted access to the request object.