OWASP API1: 2019 – Broken Object Level Authorization

BOLA is a common and severe API vulnerability. It is also referred to as Insecure Direct Object Reference (IDOR). Broken Object Level Authorization vulnerabilities allow attackers to access data objects that should be restricted. So attackers can request and access other users’ data/ resources.

The API doesn’t correctly validate the identity and privileges of the user performing the request. This is due to authorization flaws. Some examples of authorization flaws:

• API not checking permissions and allowing access to resources
• APIs include resource ID in the URI, request header, or body
• Resource ID has a clear structure that can be easily substituted
• No checks in place to determine ownership
• Not validating user-supplied inputs
• Misconfigured authorization checks
• Human errors – some requests have authorization checks while others don’t

Types of Broken Object Level Authorization  

Based on the User ID:

API endpoints receive user IDs to access user objects. For example:

/example.com/get_users_search_history?userID=1089 

The BOLA flaw allows attackers to change the user ID to something else. Thus, they can view other users’ search history. This flaw, however, is easier to solve for developers. This is because the authorization mechanism is straightforward here.

A simple check must be included to ensure the user can access the objects. In our example, the check must compare the user ID from the GET parameter to the current user ID. If it doesn’t match, the query must return an error message.

Based on Object ID

In this BOLA flaw type, the API endpoint receives an Object identifier that doesn’t belong to the user object.

For instance,

example.com/receipts/download_as_pdf?receipt_id=1089

The attacker can switch the receipt id to download the receipts of different users.

api/shop/ {shop name}/revenue_data.json

The attacker can change the shop name to gain access to the revenue data of other shops on an eCommerce platform.

Here again, the flaw exists because the server doesn’t properly validate the request for the object ID. Developers may not have properly secured all objects. They may have missed an object that must be secured. Securing this BOLA vulnerability is more complex than those based on user IDs.

BOLA exploits are possible in any API endpoint that allows user inputs. Attackers tend to test APIs for BOLA flaws. They try changing the user or object ID to see how the API responds.They would then go ahead with the attack if the API returns objects instead of an error message. The attack usually enumerates more user/ object IDs to access large volumes of restricted resources.

Let us take an example from the banking industry.

An attacker uses a credential-stuffing attack to breach a banking system. Suppose they identify a Broken Object Level Authorization vulnerability. Using this flaw, they keep changing the identifier in their request.

They don’t have to reauthenticate every request. So, they end up accessing any number of user accounts. Or they may even transfer money.

Why is Broken Object Level Authorization OWASP API1: 2019?

Exploitability 

As per OWASP API, BOLA has an exploitability score of 3. This means it is easily exploitable by attackers. And why wouldn’t it be?

Attackers must replace their resource’s user or object IDs with other values. It is even simpler with modern apps that widely use APIs. Why so?

The server in traditional apps would know what buttons a user clicked or which objects they viewed. Modern apps are much less aware of the user state as it is managed on the client side. The server components in API-based apps don’t completely track the user state. They rely on object IDs given by the client to decide access.

Widespread Prevalence 

Broken Object Level Authorization, as per OWASP, has a prevalence score of 3. It is found in all kinds of modern apps and across domains.

Further, enterprises use hundreds of APIs today. There are several shadow and rogue APIs that developers aren’t aware of.

Developers cannot test for BOLA or rectify the problem without centralized visibility. So, enterprises end up having one or more APIs vulnerable to BOLA.

Impact of BOLA on APIs

The technical impact score for BOLA is 3. This means the impact is severe and business specific. Here are some possible impacts of successful BOLA exploits.

• Exposure to sensitive information
• Attackers can view, modify, or delete data
• Full takeover of admin accounts
• Privilege escalation
• Using stolen data for identity thefts, financial fraud, etc.

Successful BOLA exploits are costly. You will lose customer trust and loyalty. There will be customer attrition.

You’ll also have to invest time and money in acquiring new customers. And this will be challenging, given the damage to your brand reputation.

Parler’s Data Breach70TB of Parler, a social network, got scarped through insecure APIs. Hackers scarped millions of posts, photos, and videos before the network was offline after Amazon, Apple, and Google booted the site. How did it happen? Experts confirmed that Parler lacked the basic security measures.

The insecure direct object reference is Parler’s major security flaw, says Kenneth White, the co-director of the Open Crypto Audit Project.

Facebook Vulnerability

The vulnerability in Facebook’s API allowed the unauthorized creation of posts on other users’ pages.  Although not appearing in newsfeeds, the posts could be viewed as legitimate by accessing through a direct link. The root cause was insufficient authorization checks for unlisted posts.

How to Detect BOLA Vulnerabilities? 

Despite its severity and prevalence, BOLA has average detectability (score 2). Regular API scanning and testing are the best ways to detect BOLA flaws.

• Evaluate all API endpoints and the identifiers they use
• Write test cases to implement across the API lifecycle. The tests are straightforward. Tests simply require object IDs to be replaced. If they don’t return an error message, you must act
• Test all objects. Check them for read, update, modify and delete actions
• Check all functionalities that access objects through secondary routes, including those that access objects
• Automate the testing process to find all BOLA flaws quickly and accurately to uncover business logic flaws
• Leverage API-specific, comprehensive testing solutions for the effective detection of BOLA flaws
• Follow a regular cadence of manual pen testing for uncovering BOLA flaws that often reside in the business logic layer of APIs

Traditional Tools Don’t Work  

Enterprises often rely on traditional tools like WAFs and API gateways to prevent BOLA risks. And these tools cannot offer adequate protection. Why so?

• API gateways are good for implementing authorization. However, they can’t inspect requests and check for malicious requests. After all, barring DDoS requests, most malicious requests could be deciphered by analyzing the request object
• These tools rely on signatures. It is difficult for them to differentiate good from bad API behaviour
• They can’t look or don’t know where to look for APIs and API flaws. So, they aren’t equipped to know the unknown
• Traditional tools offer only the least common denominator protection. And that is inadequate for today’s complex, modern architecture

Implement Proper Authorization Mechanisms

You must implement a well-defined authorization mechanism. It must be based on user policies, roles, and hierarchies. The mechanism must validate every user. It must ensure that the user has permission to perform any actions that they do. This should be the case for every user using any functionality to fetch data.

This must be a centralized mechanism that can be deployed for every sensitive object. This helps ensure that codes are not messed up by varying authorization mechanisms.

You must regularly test and update your authorization policies. This helps ensure that your policies are free of logical flaws and loopholes. This is the most effective way to combat Broken Object Level Authorization.

Using GUIDs instead of Numeric IDs

Most guides on BOLA protection will tell you to use GUIDs instead of numeric IDs. GUID (Globally Unique Identifier) is also known as UUID (Universally Unique Identifiers). GUIDs are long, random, unpredictable strings of alphanumeric values. It minimizes the risk of tampering by attackers.

Remember that GUIDs make it challenging for attackers to guess object identifiers. However, it is not impossible. Employ GUIDs as an added security layer and not the only solution.

Real-Time Threat Monitoring

Deploy an API security software that detects and neutralizes BOLA threats in real-time. It must maintain an updated inventory of all APIs, endpoints, and dependencies.

The solution should use behavioral and pattern analysis to detect malicious API behaviour and stop it.

In addition, attackers use bots to evade traditional defences. So, behaviour-based protection and self-learning AI are key to combat BOLA attacks.

If possible, the solution should also have an API discovery module, where the solution will keep updating the inventory of APIs automatically as and when they are created.

AppTrana can help both detect the vulnerability and stop its exploitation. With behavioural analytics, AppTrana can monitor, flag, and block behaviour that indicates BOLA attempts. How Our API Protection Is Unique?

Infinite API Scanner

The AppTrana solution bundles an API scanner that is infinitely expandable through the usage of plugins. Hence the name Infinite. There is also an added capability of penetration testing on the APIs.

The infinite API scanner with built-in pen testing license will help you detect all the OWASP API Top 10 vulnerabilities, including detects BOLA / IDOR. The automated scanner helps detect gaps in access control and server validation. It performs a comprehensive scan of API to ensure no loopholes for BOLA attacks.

Few tests are dependent on the particular API and can’t be generalized. In such cases, the plug-in-based architecture enables pen-testers to write an automated test case. It extends testing capabilities infinitely.

Infinite API scanner providers visibility on vulnerable API endpoints. It continuously scans each endpoint and compares observed requests with expected usage. Then it analyses the failed resources for various error conditions, which reveals potential BOLA weakness.

False Positives

Sometimes legitimate users who forget their password appears like attackers. In other cases, attackers attempt through legitimate user credentials.

With threat intelligence, AppTrana can find the difference. It is designed to block malicious requests from attacking the APIs while allowing legitimate traffic.

Enhanced Bot Protection

BOLA significantly widens the attack surface. Hackers can target multi-step attacks. Once they exploit BOLA, they will string together a series of attacks, including bot attacks. Also, they hide their attempt to exploit BOLA with high traffic using bots.

AppTrana counter this approach with advanced bot management. It also relates malicious traffic across multiple events to detect techniques associated with a unique attacker.

Behaviour-Based Monitoring

AppTrana continuously monitors each user and detects activity targeting BOLA vulnerability. It not only monitors for resources that attempt to exploit this vulnerability.

It also looks for other suspicious activities like repeated error responses. If these behaviours exceed the risk threshold, it blocks the attacker immediately.

Visibility

It displays all results graphically on a dashboard with actionable insights. It enables fingertip access to details like:

• Attack source/response codes that leak the data
• Underlying IP address details

Broken Object Level Authorization is the top API vulnerability today. The damage caused by the exploitation of BOLA is catastrophic.

Don’t let a broken object-level authorization vulnerability be the downfall of your business. Leverage a fully managed and reliable API security solution like AppTrana.

To protect your APIs and reduce the risk of BOLA, start your free trial today!