USE CASE
Protecting APIs from BOLA
Today, most everything we do digitally requires an account with user name and password that grants us access to resources behind the login. It could be a ticketing system, your finances, a social media app, or a shopping site. When you login, you are authenticating that you are who you say you are. By establishing an account, you are granted user privileges by the provider which are stored in a repository with other users who may have different privileges including management and system administration. While somewhat burdensome on the user, the process is simple and straightforward.
Where things begin to get complicated is during the API coding efforts. If the developer uses API authentication best practices while creating the API or web app, the user information should be safe, and the application should function as designed. If authentication coding errors are made, the result, known as Broken Object Level Authentication (BOLA), may allow attackers to access data they should not have, or use elevated privileges to make unapproved changes.
BOLA: Often Used in Multi-phased Attacks
As noted by OWASP, BOLA is ranked as the top threat on the API Security Top 10 list because the server component usually does not fully track the client’s state, and instead, relies more on parameters like object IDs, that are sent from the client to decide which objects to access. The practice of displaying object IDs is feasible and generally acceptable in cases where the information is open for public consumption as is the case for news articles. You may have read https://favoritenewssite.com/news/919 and its likely you would be able to read another news article by changing the ID in the URI to https://favoritenewssite.com/news/921. in the news site example, there is no proprietary information that represents a business risk if leaked. When a user authentication mechanism for confidential information is flawed, it can lead to significant API security incident, as was the case in the Peloton security incident from 2021.
In an extreme, yet real-world example, BOLA can allow an attacker to execute a sophisticated, multi-phased attack like mobile device SIM swapping. Your mobile device user profile is tied directly to the device phone number, which you can use to determine things like upgrade eligibility. In most cases, the telecom API will have strong authentication controls that only allows this request if a user has been authenticated to the application. However, it is the follow-on queries listed below that may or may not require authentication that begin to present a problem:
BOLA to Enumeration
Using common traffic reconnaissance techniques, an attacker learns that once authenticated, they can merely change the phone number to gain access to the account information. Using automation, the attacker then enumerates through a series of phone numbers, collecting user profile data.
Enumeration to ATO
Now that the attacker has access to a list of phone numbers and associated user information, the next step is to execute an account takeover by gaining access to your account, changing the password and locking you out of your phone.
ATO to SIM Takeover
Once your mobile account is compromised, your phone is no longer under your control.
A SIM swapping scenario is only one example of how BOLA can be used but it highlights the requirement for development and security teams alike to be vigilant in their coding and security practices to protect public facing APIs.
BOLA Attacks Impact the Business
The widespread use of APIs to support the account-based approach commonly found in today’s digital economy exemplifies the double edged sword that APIs introduce. For developers, APIs accelerate their productivity, allowing the organization to iterate more quickly and respond to market demands. Those same characteristics are also loved by attackers, who can use their developer skills for malicious purposes to uncover authentication coding errors to execute a range of attacks, resulting in significant business impacts:
Development Teams
The attack may have been on a shadow API, or one that did not adhere to specification definitions, the dev team will be impacted by the effort required to find the shadow API, or fix, test, and redeploy the API that is non-conformant. Either way, they are taken away from their tasks at hand.
Infrastructure
Whether it’s an automated attack on a perfectly coded API, or a volumetric attack against an API coded without resource or rate limiting (OWASP API#4), the impact on infrastructure teams can cause costs to skyrocket. Worse yet, the web site and mobile app can become non-responsive, resulting in (real) user dissatisfaction.
Security
Security is impacted by efforts to slow or stop API attacks, often struggling to separate real from fake, or worse yet, blindsided by an unprotected shadow API.
Fraud Teams
Often engaged directly if the BOLA attacks are fake account or ATO related, investigating individual accounts, issuing account reset or delete recommendations. All of which consumes time that could (and should) be spent on broader team goals.
Marketing, Sales, eCommerce
Depending on the type of attack, these groups may be presented with inflated marketing statistics which turn into poor or misleading sales program decisions, missed revenue projections and damage to vendor relationships.
Customer Satisfaction, PR, Brand
With the understanding that 57% of consumers spend more on brands to which they are loyal, which can generate a 12%-18% incremental revenue growth per year, retailers are singularly focused on customer retention. A bad experience due to a slow or unavailable website, or desired item can drive them elsewhere, resulting in a 5x increase in costs of acquiring a new customer.
Limitations of Traditional Cloud-native Defenses
Today’s security teams simply lack the visibility and defense capabilities they need to reduce the BOLA related risks introduced by their organizations explosive use of APIs. Many believe that compliance with PCI or SOC 2 and a “shift-left, DevOps” approach is sufficient to protect their APIs. The problem with these strategies is that they don’t have a way to “know the unknown”, meaning they aren’t able to look for all APIs and API vulnerabilities without knowing where to look. Even if all APIs are discovered and “known”, attackers can still leverage seemingly legitimate transactions in an attempt to steal data, or commit fraud. Traditional approaches that use WAFs or API gateways depend on easily evadable detection, lack the real-time ability to discern good from bad API activity and are reliant on static, least common denominator protection spread across multiple technology components.
The Journey to Unified API Protection
Cequence Security believes in taking a holistic approach to defending against API-related data risk with a market-defining Unified API Protection solution that goes beyond API security approaches that may focus solely on one aspect of the API protection journey. Achieving true peace of mind for comprehensive API attack protection means traveling through six distinct steps associated with the Unified API Protection solution:
Discovery: Viewing an organization’s API attack surface from a threat actor perspective to know the unknown.
Inventory: Performing a comprehensive multi-cloud API inventory, including all existing APIs and connections.
Testing: Integrating API protection into development, which shifts API security left within the organization, so risky code doesn’t go live.
Compliance: Keeping APIs in compliance with specifications, standards and regulations such as OWASP and ensuring ongoing API governance.
Detection: Continuous scanning for threats, including subtle business logic abuse, fraud, and automated malicious activity from bots.
Prevention: Employing countermeasures such as alerts, real-time blocking, deception, without the need for added third-party data security tools.
Unified API Protection is different from fragmented or incomplete API security offerings because it’s a methodology designed to account for multiple types of risk, across every phase of the API protection lifecycle.
Why Cequence?
With the Cequence Unified API Protection solution, customers can continue to reap the competitive and business advantages of ubiquitous API connectivity. The Cequence solution results in attack futility, failure, and fatigue for even the most relentless of attackers. It significantly improves visibility and protection while reducing cost, minimizing fraud, business abuse, data losses and non-compliance.
