API1:2023 Broken Object Level Authorization (BOLA)
APIs often expose endpoints that handle object identifiers, creating a wide potential attack surface. Object level authorization is an access control mechanism usually implemented at the code level to validate a user’s ability to access a given object. Authorization and access control mechanisms in modern applications are complex and widespread. Even if an application implements a proper infrastructure for authorization checks, developers often forget to apply these checks before accessing an object.
Attackers can easily exploit API endpoints that are vulnerable to broken object level authorization (BOLA) by manipulating the ID of an object that is sent within an API request. This is because the server component usually does not fully track the client’s state. Instead, the server component usually relies on parameters like object IDs sent from the client, to decide which objects can be accessed.
BOLA vulnerabilities are present in around 40% of all API attacks and are listed as the number one threat to API security in the OWASP API Security Top 10. Any access to unauthorized data is severe, regardless of its data classification or data sensitivity. Unfortunately, these types of authorization flaws are not easily detectable with automated static or dynamic testing.
Every API endpoint that receives an ID of an object, and performs any type of action on the object, should implement object level authorization checks. These checks should be made continuously throughout a given session to validate that the logged-in user has access to perform the requested action on a requested object.
Get your copy of the Gartner report: "Innovation Insight for API Protection"
Download NowWhat’s the Potential Impact of a BOLA attack?
Failure to enforce authorization at the object level can lead to data exfiltration as well as unauthorized viewing, modification, or destruction of data. BOLA can also lead to full account takeover such as in cases where an attacker can compromise a password reset flow and reset credentials of an account they aren’t authorized to.
In the example above, the backend logic of the application queries the database with the userId in the query parameter while verifying the authorization with the userId in the cookie. Under normal conditions, these two values should match. However, an attacker could simply modify the userId value in the query parameter in order to access unauthorized data.
If the userIds are sequential, the attacker can simply enumerate the query parameter userIdvalue to scrape, or exfiltrate, large amounts of data, particularly if rate limits aren’t enforced.
Real-World Examples of Broken Object Level Authorization (BOLA) Vulnerabilities
How a Hacker Could’ve Taken Over your Uber account
In 2019, a security researcher disclosed a BOLA vulnerability that would have enabled an attacker to take over any user account on Uber. By exploiting the vulnerability, the attacker could access another user’s account to track the target user’s location, take rides, and more. The attacker could also exploit the BOLA vulnerability to harvest Uber mobile app access tokens, and then use those access tokens to take over Uber Driver and Uber Eats accounts. The Uber application userId could be easily enumerated by supplying a user’s phone number or email address in another API request.
The BOLA Attack at the Central Bank of Russia
One prominent example of a successful BOLA attack happened at Russia’s central bank in 2016, where attackers managed to change an account ID and make unauthorized transfers to other accounts via a Fast Payments System, managing to steal around 2 billion rubles.
In this instance, the attackers managed to obtain customer account data by exploiting the BOLA vulnerability, then launched the bank’s mobile application in debug mode, logged in as a real client and transferred funds to another bank. Before making the transfer, the attacker changed the account ID to another client’s ID allowing the transfer to be processed without proper ID verification.
Why Existing Tools Fail to Protect You Against BOLA Vulnerabilities
Traditional security controls like WAFs and API gateways miss these types of attacks because they don’t understand API context and don’t baseline normal API usage.
When it comes to BOLA vulnerabilities, these tools do not know that the userId in the query parameter and the userId in the cookie should match. Also, since this is not a known, predictable attack pattern like a code injection where basic pattern matching and message filtering can be employed, a BOLA attack cannot be identified by the signatures used by a WAF or API gateway.
How to Protect APIs Against Broken Object Level Authorization (BOLA) Attacks
In order to prevent BOLA attacks, an API security solution must be able to learn the business logic of an API and detect when an authenticated user is trying to gain unauthorized access to another user’s data. Effectively, the API security tool needs to be able to recognize that the two objects should match and that the authenticated user is authorized to access the requested object. This kind of detection requires the analysis of large amounts of API traffic in order to gain context and understand the normal behavior of each API.
Only a solution that provides a baseline of normal usage can identify abnormal behavior like an attacker manipulating the userId in a query parameter in GET requests, or a userId variable within a message body of POST requests.
To see how the Salt platform can help you prevent BOLA attacks, get a demo today.
