As API-related security incidents and breaches increased in recent years, the Open Web Application Security Project (OWASP) released the first-ever API Security Top 10 at the end of 2019 to raise awareness about the most common API security problems plaguing organizations. In this post and subsequent additions to the series, I dig into each of the OWASP API Security Top 10 in detail. I also provide examples and insight to help you understand how to protect your organization from the threats targeting APIs and API-based applications. We start with API1:2019 Broken Object Level Authorization, the most common API threat, represented in about 40% of all API attacks.
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.
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.
This API Security Checklist will help you close the gaps in your API security strategy based on industry best practices.
It’s one thing for us at Salt to say we’re the best in API security – it’s quite another for the team at API World to say it. And they just did.