Hacking APIs (1) - From a Festival Security Saga to BOLAs aka IDORs

BLOG Hacking APIs (1) - Broken Object-Level Authorization

Author: David Schmid
Date: 27.05.2024 • Last Update: 03.06.2024, 13:42
Categories: Cybersecurity

APIs serve as the backbone of software communication across the internet and local networks. With the explosion in digital interactions, the strategic business interest in these Application Programming Interfaces has increased, making their security vulnerabilities increasingly critical.

Some say API security is the new frontier in IT security.

Through an engaging festival analogy, where groupies try to access the backstage to meet their favorite musician, this article dives into the intricacies of "Broken Object-Level Authorization" (BOLA) in API security.

We'll explore how these vulnerabilities arise within the broader context of security and with a specific focus on API security. BOLA tops the OWASP Top Ten list of API security vulnerabilities in 2023, highlighting its significance in today's digital landscape.

Main Image Blog Article Hacking APIs Part 1

A Festival with BOLAs

Imagine this: you decide to organize a music festival. It's a fantastic idea, and you have all the resources and connections to musicians and sponsors, making it not just a creative venture but also a promising business success.

In preparation for the event, security is a top priority. With the main act featuring the renowned singer Steinbock, you expect a surge of groupies determined to reach the backstage area.

Therefore, you implement several security policies for staff members to follow.

Tickets are sold based on different access tiers: some tickets grant entry to the general zones, while others provide a VIP experience with access to exclusive areas. Additionally, a few high-class tickets, reserved for representatives of the main sponsors, grant access to the backstage area.

At the festival's entrance, visitors must confirm their identity by showing an ID to receive a wristband as an access token corresponding to their ticket tier. The wristbands are color-coded to indicate access levels: general (yellow), VIP (white), or Backstage (red, the most critical). Everything seems set for the big event.

However, things start to go wrong, and our festival becomes an analogy for understanding Broken Object-Level Authorization (BOLA) in API security.

Some inventive groupies discover they can remove the color from general admission wristbands. They figure out that applying alcohol, available in the high spirits sold at the bar, turns the yellow wristbands white, granting them access to the VIP lounge.

As the VIP lounge fills with groupies, some wander further and notice another gate leading to the backstage area. Although they can't fully change the white wristbands to red, the security breach is apparent.

In hastily called task force meetings, you begin to see through this strategy and implement stricter controls at both the VIP and backstage gates to check the wristbands for signs of tampering.

However, once the groupies realize there is no way through the main gate into the backstage area, they start looking for unsupervised backdoors and find one - an inconspicuous small door used as a quick corridor in some backstage areas but never monitored. Just like that, the backstage is overrun with unauthorized groupies, raising the glaring question:

How did this happen?

Authentication vs. Authorization

To understand the security breaches on a more conceptual level, we must distinguish between authentication and authorization - two fundamental concepts in security that are distinct yet crucial for proper implementation.

Authentication is the process of confirming a someones identity, akin to showing an ID at the festival gates to receive a wristband (access token) based on different privileges within the event. It verifies that you are who you claim to be.

Authorization, on the other hand, determines what you are allowed to do once you are inside the system. In the context of our festival, this involves ensuring that visitors can only enter the zones for which their wristbands (access tokens) are valid. This is achieved by implementing stringent security measures at every access point, preventing backdoor entries and misuse of access tokens, such as wristbands, for gaining unauthorized privileges.

In our festival security saga, the failure in authorization checks allowed groupies to bypass security by forging tokens and exploiting an unmonitored backdoor.

Similarly, in API security, a "broken" authorization vulnerability can occur when an API fails to enforce proper authorization checks, allowing unauthorized users to access or manipulate resources they shouldn't have access to. This underscores the importance of robust authorization mechanisms to maintain the integrity and security of both physical and digital environments.

☕ Let's Have a Coffee Break

After this festival security saga, it’s time for a coffee break. Before we dive deeper into API security, let’s gather some sips, take a deep breath, and relax for a moment.

If the content within these pages has enriched your journey, particularly our dive into API security topics, consider showing your support by buying me this coffee. This simple act triggers a fascinating chain of API calls across the web. From the Buy Me a Coffee site processing your kind tip to my use of a card at the local coffee shop, your support engages a dynamic network of digital transactions.

☕ Buy Me a Coffee

Let me insure that my posts are based on my personal opinions and experiences, shared openly and honestly. Your support not only helps with my caffeine needs but also enables me to continue exploring and sharing more about the fascinating world of APIs and technology. As a father of two, coffee is indeed the elixir that fuels my vigilance and creativity.

In addition to sharing my journey and insights, I specialize in crafting and engineering API solutions that empower and enhance your tech projects. Discover how I can help innovate and secure your applications and services.

🔍 Discover My Services

But now, let's go back to the topic...

Broken Object-Level Authorization (BOLA)

Similar to how a flawed festival system might fail to verify each attendee’s wristband (access token) against the authorized areas, an API with lax security checks may not adequately verify whether a requester should have access to a specific piece of data or service. This leads to a vulnerability known as "Broken Object-Level Authorization" (BOLA), which tops the list of OWASP Top 10 API Security Risks in 2023.

If you are unfamiliar with the concept of APIs, I recommend my blog post about exposing APIs from a business perspectie. We can learn that that Application Programming Interfaces (APIs) serve as the backbone of software communication, connecting services, data and applications accross both the internet and local networks and that these vital components facilitate digital interactions and drive innovation and strategic advantage for businesses in the digital economy.

BOLA focuses on securing access to specific objects or resources within a system. Just as in our festival scenario, where the "objects" are different access zones, in API security or web applications, an "object" typically refers to a specific dataset or resource instance, such as a user profile, a financial record, a blog post, or any other identifiable and discrete data entity that the application manages. This form of authorization checks whether a user has permission to perform actions (like reading, writing, or deleting) on a specific object based on their attributes or ownership.

This is distinct from function-level authorization, which determines if a user can access certain functionalities, such as the ability to create new user accounts, modify system settings, or generate reports. Functional-level vulnerabilities also make the top ten list in API security but "only" rank at position five as "Broken Function Level Authorization."

The term "broken" in Broken Object-Level Authorization refers to the failure of a system to properly enforce object-level checks. This can arise due to improper or missing checks within the implementation that verifies a user's permissions against the object they are attempting to access or manipulate.

BOLAs are often also referred to as Insecure Direct Object References (IDORs). While the terms are sometimes used synonymously, IDORs generally refer to a narrower scope of issues, focusing specifically on the exploitation of insecure references to objects (making IDORs a subset of BOLAs).

Typically, public APIs that expose endpoints handling object identifiers to the web create a broad attack surface for BOLAs with vulnerabilities that can be exploited remotely from anywhere. Therefore, it is crucial that object-level authorization checks are integrated into every function that accesses a data source using an identifier provided by the user.

Whether these APIs are RESTful or GraphQL, they often adhere to the CRUD (Create, Read, Update, Delete) model for resource management. A BOLA vulnerability occurs when an attacker manages to create, read, update, or delete a resource that does not belong to them, thereby breaching intended security protocols. These checks must ensure that the logged-in user has the necessary permissions to perform the requested action on the requested object.

Hypothetical API Security Examples

In the following sections, we will explore three examples that demonstrate how BOLAs might occur in the API context. These examples are loosely based on the scenarios provided by the OWASP Top 10 guidelines for BOLAs, but with some variations to better illustrate different aspects.

Online Shop Order Viewing

Imagine an online shop where each user, or customer, can view, edit, and create new orders. The system uses an API that accesses specific orders based on their unique IDs, supporting various actions through HTTP methods like GET, POST, and DELETE. For example, to view an order, a typical API request might look like this:

GET api.example-shop.com/v1/orders/12345

In this scenario, 12345 is the order ID, uniquely identifying an order in the shop’s backend database.

Now, suppose a hacker discovers that by simply changing the order ID in the URL - from 12345 to 12346 - they can access orders belonging to other shoppers.

This discovery highlights a critical security flaw: the API does not adequately verify whether the authenticated user is authorized to access the specified order. This vulnerability exposes the shop to significant risks, including unauthorized access and potential misuse of order data (recalling the zones in our "BOLA Festival").

Such a scenario underscores the importance of implementing robust authorization checks within the API to ensure that each request to access or modify an order is properly authenticated and authorized. Without these checks, the integrity of the ordering system and the security of user data are at risk, making it imperative for developers to address such vulnerabilities proactively.

Blogging Website Vulnerability

Consider a blogging platform where users can freely read all blog posts but are only authorized to edit, post, and delete their own contributions. Each user's account is intended to restrict editing capabilities solely to posts they have authored, ensuring that content ownership is respected and maintained across the platform.

A typical API setup for this blogging platform might include endpoints structured as follows:

To retrieve a post:

GET api.blogsite.com/v1/posts/{postId}

To create a new post:

POST api.blogsite.com/v1/posts

To update an existing post:

PUT api.blogsite.com/v1/posts/{postId}

To delete a post:

DELETE api.blogsite.com/v1/posts/{postId}

In these examples, {postId} acts as a unique identifier for each blog post.

Now, imagine a scenario where a vulnerability within the platform allows users to manipulate the {postId} in the URL of a PUT or DELETE request. For instance, if a user discovers they can alter the {postId} from one of their own posts to one authored by another user, they could inappropriately gain the ability to edit or delete someone else's post.

This type of vulnerability could lead to several adverse outcomes, including unauthorized content modification, deletion of posts without consent, and breaches of user trust. It underscores a critical flaw in the authorization checks of the blogging platform, where the system fails to adequately verify the alignment between the user making the request and the post targeted by the {postId}.

Unauthorized Document Deletion in a Cloud Service

A cloud-based document storage service provides users with functionalities to manage their digital files, including viewing, editing, storing, and deleting documents.

Using a GraphQL mutation to trigger an API request when a user decides to delete a document, we can imagine a request that specifies the unique identifier of the document intended for deletion as follows:

POST /graphql
Content-Type: application/json

{
  "operationName": "deleteReports",
  "variables": {
	"reportKeys": ["{DOCUMENT_ID}"]
  },
  "query": "mutation deleteReports($siteId: ID!, $reportKeys: [String]!) {
    deleteReports(reportKeys: $reportKeys)
  }"
}

The reportKeys array holds the IDs of the documents that the user wishes to delete. The request is sent to the /graphql endpoint of the API.

Now, imagine a vulnerability arising when the API does not perform adequate permission checks before proceeding with the deletion. Specifically, if it fails to verify whether the user making the request is the rightful owner of the document identified by the {DOCUMENT_ID} or has the necessary permissions to delete it. This oversight could allow any user who can send a properly formatted GraphQL mutation to potentially delete documents they do not own.

Preventing BOLA Vulnerabilities

To safeguard against Broken Object-Level Authorization (BOLA) vulnerabilities, it is essential to implement robust security measures. Here are some best practices to help prevent these vulnerabilities:

Implement a Proper Authorization Mechanism: Ensure that your authorization mechanism is comprehensive and relies on user policies and hierarchy. This means clearly defining what actions each user role can perform and enforcing these rules consistently across your application.
Verify User Permissions: In every function that uses an input from the client to access a record in the database, use the authorization mechanism to check if the logged-in user has the necessary permissions to perform the requested action. This step is crucial to ensure that only authorized users can access or modify specific data.
Use Random and Unpredictable Identifiers: Prefer the use of random and unpredictable values, such as GUIDs (Globally Unique Identifiers), for record IDs. This practice makes it more difficult for attackers to guess valid IDs and exploit the system.
Conduct Thorough Testing: Write and execute tests to evaluate the effectiveness of your authorization mechanism. Regularly test for vulnerabilities and ensure that any changes to the system do not introduce new security issues. Do not deploy changes if the tests reveal weaknesses in the authorization checks.

Conclusion

We explored the concept of Broken Object-Level Authorization (BOLA) through a festival analogy, highlighting how minor security oversights can lead to significant breaches. We examined how BOLA applies to API security, emphasizing the need for robust authorization mechanisms to protect sensitive data and resources.

By understanding the complexities of BOLA and implementing proper security measures, we can safeguard our APIs from unauthorized access and manipulation.

However, BOLA is just one piece of the API security puzzle. In our next article, we will continue the festival security saga by diving into the world of Broken Authentication, another critical vulnerability in API security.

Stay tuned as we unravel the challenges of authentication and explore strategies to further fortify our APIs against this pervasive threat.

Comments

No comment on this post yet... Initiate the dialogue - be the first to illuminate this page with your thoughts!

Table of Contents