APIs are an essential component of modern applications. An enterprise organization has more than 10,000 of them in use, including many self-designed APIs. External users communicate with them in abundance, but malicious actors can cause many headaches for the organization running the API. OWASP (Open Worldwide Application Security Project) recently produced a new top 10 of API security risks. For many companies, these cause major headaches, but Noname Security can already close all of these gaps.
In 2019, OWASP already came out with a top 10 API security risks. The two leading dangers are still unchanged: Broken Object Level Authorization (BOLA) and Broken User Authentication. On the former, Filip Verloy, Field CTO at Noname Security, told us earlier this year that BOLA attacks can do a lot of damage. In September 2022, such an incident occurred at Australian telecom company Optus, which leaked nearly 10 million personal data.
An API is usually set up to provide a user with specific data, but a malicious party can figure out how the API does this. Verloy argues that an attacker can start as an ordinary user and then, after authentication and authorization, make queries that manipulate the API. This could create giant data breaches, such as when an attacker scours every other user’s data and leaks it. After all, anyone who figures out which Object IDs are retrievable can systematically retrieve and pull them in if no further security measures are taken.
To ensure there’s no BOLA attack, it’s important to apply user policies that do not allow access to just any Object ID. Also, records of these should not be ID’d in a predictable manner. OWASP recommends running tests on the API while it is under development, as Noname Security supports.
In addition, number two, broken authentication, is still prominent. Causes include admins allowing weak passwords, not verifying the authenticity of tokens or not placing limits on password recovery. These can leave APIs vulnerable to brute-force attacks.
From effect to cause
OWASP goes on to state that object properties must also be provided with authorization validation. Those who do not apply this or insufficiently face many dangers. As an example, the group cites that users can modify personal data and monetary amounts and thus enter incorrect information. A legitimate API call is thus modified to manipulate data that a user should not be able to tinker with. To prevent this, an organization must ensure that the object properties that users are allowed to adjust are very limited.
Tip: Noname Security introduces tool to leave no API untested
Number four is a fairly simple misconfiguration: API requests consume hardware resources, which are inherently finite and consume power. Everything from CPU cycles to network bandwidth comes into play. Therefore, it is essential to limit this consumption – otherwise, a threat actor can take down a system via numerous API calls. In fact, one can thus carry out a classic DDoS attack on a company’s IT environment. Execution timeouts, memory consumption maxima, file size and other limits are thus very important to protect against this.
In addition, it is possible for an attacker to manipulate administrative API endpoints. OWASP highlights this danger as number five on its ranking: checking authorization checks is a time-consuming task and can be very confusing due to the jumble of roles, groups and user hierarchies. On top of that, a misconfiguration of these can be more easily noticed in the structured data of an API. Thus, it is possible for administrative functions to be manipulated to obtain sensitive data, for example, by a malicious person accessing an application via a rogue API call. An ordinary user should not be able to perform this action.
Scanning for everything
Now, these five dangers mentioned are known problems. Numbers eight and nine from the OWASP list are also not new. Security misconfigurations are unfortunately still common and often arise at APIs, for example. This is possible because external applications have not yet been patched for a known vulnerability or because an API does not contain a secure default configuration. Improper inventory management is also an easy mistake to make: because many organizations apparently have more than 10,000 APIs, it is challenging to keep an overview.
Almost all of these problems can be overcome with careful development of APIs. If they come from third parties, of course, this is not feasible. But those building their own APIs should be paying attention from the get-go. Verloy observes, “The cost to fix these problems is 10 to 100 times higher than if found during pre-production.” At Noname, therefore, the focus is on assisting API builders rather than observing problems with existing APIs. Yet that second is also part of Noname’s capabilities.
New dangers
Noname announced this week that it can now fix all 10 API vulnerabilities identified by OWASP, three of which are entirely new to the list. One concerns a widespread problem that also affects customers. APIs can contain information about business flows, or processes essential to doing business. For example, a ticket agency or a restaurant may offer tickets or reservations online, respectively, but the process for doing so may be automated and predictable to the extent that someone from the outside can run bots on it. The result: a suddenly sold-out concert or fully booked restaurant, after which the perpetrator resells the tickets at extortionate prices or leaves the restaurant with empty tables. Things like device fingerprinting, captchas and checking for mouse clicks faster than a human could can make bots ineffective.
Second, attackers can forge server-side requests. When an API addresses an external resource without checking a supplied URL, for example, an attacker can scan for vulnerable network ports. For example, consider a platform that allows image uploads via a URL but does not check it beforehand. Suddenly, an unwanted connection is created between the attacker’s website and the affected company’s system. Utilizing allow lists of trusted websites, stopping HTTP redirects and deploying a tested URL parses can prevent problems from cropping up.
The final addition to the OWASP list concerns the excessive consumption of APIs, especially those from third parties. While Noname, for example, can help test its own APIs during the development process, it is much more difficult to keep an eye on how good the security level of externally supplied sources is. In fact, this tenth pitfall has a lot of overlap with other API dangers: those who don’t have an overview of which APIs one uses or don’t patch them can run into trouble with third-party variants.