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 wide-spread. 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. These vulnerabilities are extremely common in API-based applications 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.
Any access of unauthorized data is severe, regardless of its data classification or data sensitivity. These types of authorization flaws are also 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.
Failure to enforce authorization at the object level or broken improper object level authorization 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 this example, 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.
The attacker (John Smith) is logged inwithuserId 207939055.Whenthe attacker changes the userId in the query parameter touserId 207938044
The attacker (John Smith) is logged in with userId 207939055. When the attacker changes the userId in the query parameter to userId 207938044 the application does not validate that the userId of the authenticated user matches that of the record being requested in the query parameter or whether the authenticated user is authorized to view that given record. As a result, the database backend returns the record for David Miller as opposed to John Smith.
If the userIds are sequential the attacker can simply enumerate the query parameter userId value to scrape, or exfiltrate, large amounts of data, particularly if rate limits aren’t enforced.
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.
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. In this case, these tools do not know that the userId in the query parameter and the userId in the cookie should match. Also consider that since this is not a known, predictable attack pattern like a code injection where basic pattern matching and message filtering can be employed, it won’t be identified by the signatures used by a WAF or API gateway.
In order to prevent BOLA attacks an API security solution must be able to learn the business logic of an API and detect when one authenticated user is trying to gain unauthorized access to another user’s data. In this particular case, 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 usage for each API. A solution with 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 the rest of the blogs in this series, click on the links that follow. To see how the Salt platform can help you prevent BOLA attacks, request a demo.
Having Forbes single out Salt Security as one of only 25 of the “Next Billion-Dollar Startups” testifies to the combination of both the significant lead we enjoy in the market and the enormity of the problem we solve.
Salt Labs researchers investigated a large business-to-consumer (B2C) online platform that provides API-based mobile applications and software as a service to millions of users globally.