Tony Lauro is the Director of Security Technology and Strategy at Akamai Technologies. In this article, he discusses API security and everything you need to know about it.
Traditionally, API security was left to the web application firewall. WAAP is focused on external threats at the perimeter. It handles DDOS and Bot mitigation. API gateways, a lot of times, are used for some security-related tasks like authorization and authentication. But it is more about managing the API, ensuring you can do rate-limiting quota checks, etc. But the big area, and what we realized a few years ago, is that the majority of the APIs that we need to secure are behind the firewall or their post-authentication APIs that exist inside the environment inside the customer ecosystem. But, we realized that there were gaps. There are only 10% to 20% of APIs are handled by existing API security controls that exist today. Regarding large-scale automated security controls, 80% below the surface are all the other APIs.
Anatomy of an API attack
Uber account takeover issue – An article was released in 2019. It talks about how this researcher, from a phone number or email address, was able to get a full account takeover for any user on the Uber app. The first request was an API POST request to addDriver. So, if you knew a user’s email address or phone number, the response that came back in error was the UID (user ID for that particular user).
The second API request was a POST to getConsentScreenDetails, providing that user ID; the response was a lot of sensitive information.
This was a misconfiguration that should not have happened. There are two vulnerabilities here. One was that the API was sharing too much information and unnecessary information. The second information is BOLA (Broken Object Level Authorization). Users can access resources that they do not own.
Data exposure by Scoolio. Scoolio is a student app for German-speaking students. It collects student information and helps with study planning, personality tests, tutoring, etc. It collects information to monetize through better ads. A BOLA vulnerability was discovered in this app. The attacker was able to make an API call to the Explorer. Their response to that was to give them profile information about other users. The second API call was used to specifically take the user ID of a user they wanted to attack and then make a similar request.
In most cases, the initial entry point into an app is through signup and login as a user. This is why security teams are focusing so much on new user creation. They’re seeing bots creating new users so that they can come back later and monetize these accounts via exploitation on the app side or the business logic side. So, when you query an API, only return the necessary information to make the call function properly.
The other vulnerability in the Scoolio app was improper asset management. During the investigation, they discovered that they were using a depreciated API version, which had a lot to do with how the response information came back for that particular profile.
Detection is one of the biggest problems. Most of the security detection by organizations is by using web application firewalls or looking at consumer-to-business API calls or public-facing API calls. The other big problem is the detection of Shadow APIs. You don’t know how many APIs you have; they’re not well documented, you don’t have a good inventory. A pen test team may be testing existing APIs, but hidden APIs may not be tested.
Teams also suffer from alert fatigue. Multiple people will ask you to fix multiple things, and prioritization may get difficult. You do not know how easy it is for these APIs to be abused or if partners or competitors are currently abusing them. The main problem is you don’t know what the usage is supposed to look like, so you can’t create any kind of baseline.
The other problem is API abuse. Most of the existing tools don’t understand the business logic of the API. We know the APIs that are inside our environment. We assume that calls to these APIs are after authentication and so in the safe zone. In such cases, as need to think of BOLA and other business logic abuses. So, if we see a threat actor making a request and accessing a resource, we should be able to identify that. We must map the relationship between the threat actor, the actor, the user, and the resource. Any deviation from the baseline relationship should issue an alert.
We can have a discovery process with analytics and behavioral recognition of the API activity inside your infrastructure. This requires you to feed and bring information into a data lake after tokenizing sensitive information. Over time, this can also be an issue if the data lake is compromised.
Today, cybersecurity teams are focusing on web application firewall detection. But now, we need to shift our focus to multiple security aspects.
