Are you leaving your APIs vulnerable to attacks? OWASP revealed that Broken Object Level Authorization is among the top 10 most critical API security risks list. It is number 1 on OWASP API Top 10, 2019.
Even large companies like Facebook, Uber, and Verizon, with thousands of engineers and dedicated security teams, have experienced BOLA attacks.
Before diving into Broken Object Level Authorization, here are a few terms you’ll need to be familiar with.
Data Objects are collections of related data points that create meaning together. Objects are assigned unique data types such as string, real, char, integer, etc. Data objects could be database records or files.
Let us consider an example from online retail. Your profile associated with your account is a data object. It contains your name, username, address, customer ID, etc. Developers use profile objects in their APIs to access information on different customers.
Object Identifiers: These are unique names that are assigned to objects. They are identifiers of the variable that contains the data object. Object identifiers are how objects are referenced within the code. They are used to access resources. APIs often tend to expose object identifiers.
Object Level Authorization is an access control mechanism. This essentially defines whether users have access to the data objects. If they have access, the difference is read-only, edit, and add/delete access to those objects.
For instance, a user may view objects but not modify them. These permissions will differ based on user groups and roles. Object-level authorization adds a layer of security to data objects. It ensures that only validated users view and access data objects.
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:
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.
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.
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.
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.
Despite its severity and prevalence, BOLA has average detectability (score 2). Regular API scanning and testing are the best ways to detect BOLA flaws.
Enterprises often rely on traditional tools like WAFs and API gateways to prevent BOLA risks. And these tools cannot offer adequate protection. Why so?
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.
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.
Deploy an API security solution 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?
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.
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.
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.
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.
It displays all results graphically on a dashboard with actionable insights. It enables fingertip access to details like:
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!
Stay tuned for more relevant and interesting security updates. Follow Indusface on Facebook, Twitter, and LinkedIn
This post was last modified on January 2, 2024 11:28
Indusface has once again been recognized as a Gartner® Peer Insights™ Customers' Choice for Cloud… Read More
Protect your business from DDoS attacks with multi-layered DDoS defense, proactive threat modeling, rate limiting,… Read More
A Managed WAF is a comprehensive cybersecurity service offered by specialized providers to oversee, optimize,… Read More