In the world of API security, the words “attack” and “vulnerability” are often used interchangeably. But as the API threat landscape explodes — and security teams scramble to respond — it’s more important than ever to develop an accurate vocabulary for both, describing and defending against very specific types of API threats.
While the true meaning of “API attacks” is ill-defined in many people’s minds, it’s actually one of the most pressing risks that even very sophisticated API users face. It is also a category of threats largely ignored by the industry’s existing API security frameworks and guidelines.
In order to maintain the security and reliability of API-based commerce, the industry must evolve its thinking, terminology, and tools to account for the diverse set of API threats enterprises currently face – and the the rate at which the API threat landscape is changing.
Not all API attacks exploit vulnerabilities
Traditional application security deals with vulnerabilities such as those described in the Top 10 OWASP APIs. In this case, vulnerabilities are defined as gaps in the API’s implementation, deployment, or configuration that expose it to potential exploitation. Vulnerabilities can be found and fixed. During the development life cycle (SDLC), the focus is already on analyzing the code and performing dynamic analysis to detect API vulnerabilities at an early stage.
Attacks are the act of an adversary actively exploiting an application for profit. Some attacks exploit vulnerabilities, but even well-crafted APIs can be abused if the attacker uses legitimate credentials.
APIs expose core business logic and sensitive data externally by design. To steal data or commit fraud, the attacker simply needs to use the right API with the right credentials. The reason many successful attacks are difficult to detect is that they hide in authorized traffic. Attackers or malicious third parties can use these authorized channels to conduct unauthorized activities.
These attacks go well beyond known vulnerabilities. When attackers use authorized access, they can commit “API abuse”. Today, API abuse is the riskiest attack for targets because valid credentials are used to access or manipulate data or perform fraudulent transactions. Because the credentials are valid, access and manipulation are allowed, and the damage is done. API abuse can include:
- Using APIs in an unauthorized way for malicious reasons. In these cases, the APIs are technically being used as intended, but by the wrong person or for the wrong reason. Data scraping is an example.
- Exploitation of vulnerabilities in application logic. These abuses are specific to that particular company and, in many cases, are not addressed by the well-known OWASP framework.
API Abuse is a useful way to think about how a malicious actor might attack an API to make it work in a way that is inconsistent with the intent of API developers and product managers who are doing it. have created.
How big is the API abuse problem?
In short, it’s a big problem. Some organizations take false comfort in the fact that their APIs have been assessed for vulnerabilities and appear to be safe or “perfect”.
Even organizations that proactively focus on application security tend to put more emphasis on protecting APIs created for web and mobile applications. In these cases, many organizations often mistakenly assume that their web application firewalls (WAFs) will bear much of the burden of securing this type of API usage.
But the biggest predicted API protection gap, even in sophisticated organizations, is API protection open to partners. These APIs are ripe for abuse. Even though they are perfectly written and have no vulnerabilities, they can be abused in unintended ways to expose critical business functions and the data of the organizations that share them.
Perhaps the best example is the Cambridge Analytica scandal (CA) that rocked Facebook in 2018. As a quick refresher, CA leveraged Facebook’s Open API to gather detailed data on at least 87 million users. This was accomplished by using a Facebook quiz app that leveraged a permissive setting allowing third-party apps to collect information about the quiz taker, as well as any of their friends’ interests, location data, etc.
This information – and the resulting demographic and psychographic profiles – was then sold to various campaigns and political movements. The full impact of this may never be known, but it is generally accepted that it had a material effect on the 2016 US presidential election and the UK ‘Brexit’ referendum. It also led to an immediate market capitalization for Facebook of over $100 billion, billions in additional fines, and a continued place in the crosshairs of government regulators years later.
None of this involved exploiting an infrastructure vulnerability in Facebook’s API infrastructure. CA simply used Facebook’s public API in a way that was not intended or anticipated when it was created. Facebook exposed a basic commerce API that was eventually abused.
What does this mean for businesses in 2022?
Obviously, the example of Facebook is extreme. Yet large-scale API abuse is happening every day as companies increasingly make their digital gems available to their business partners — and even the public — through APIs.
Consider the online banking, budgeting, and financial planning apps and services that many of us now use every day. APIs are the key to making these kinds of conveniences work. But consider the value of data now accessible through fintech APIs and the potential for abuse that exists. Every API developed is a window into your business and as such can be abused.
Beyond the obvious user privacy concerns, misuse of these APIs can have a devastating impact on financial firms themselves. For example, if you were an unscrupulous mortgage company, wouldn’t it be interesting to see the current mortgage payment of a large number of bank users and perhaps cross-reference that with information on the value of the house extracted from Zillow to identify the best candidates for refinancing?
Similar risks exist in nearly every major industry now that so much of our daily business-to-consumer commerce is conducted online through APIs.
Systematic approach to API abuse
The industry is obviously not starting at square one with API security. Existing best practices and resources like the OWASP API Top 10 give security professionals an initial roadmap. But organizations should view eliminating API infrastructure vulnerabilities as a starting point, not an end. The real battle of API security will be won by developing strategies to stop API abuse. The industry must evolve in three important ways to successfully combat abusive behavior.
1. Think more about the nature of API attacks
In other areas of security, there are two different types of frameworks:
- Systematic approaches to discovering, documenting and remediating vulnerabilities (think MITER CVE).
- Build a living knowledge base of known attack techniques (think MITER ATT&CK).
In the API security space, OWASP API Top 10 gives a starting point for the first. While there’s still work to be done to deconstruct each major vulnerability type on the list into separate sub-areas that API teams should focus on, it’s still a great plan to proactively avoid vulnerabilities. API infrastructure vulnerabilities.
But very little has been done to date to truly understand and document the many ways APIs can be abused. The area must be proactively dealt with before attackers gain undue advantages.
2. Significantly increase the amount of API data for analysis
Many early API security efforts focused on monitoring individual API calls or, at best, short-term session activity. It’s not sufficient. The evaluation of single requests or sessions cannot provide an understanding of the context of normal or abusive behavior. Many legitimate business processes occur over a time horizon of minutes, hours, and days. Many attacks do this too. API monitoring and analysis approaches therefore need to evolve to analyze datasets that span these extended time periods.
Blind spots are another Achilles’ heel of many API security programs. API monitoring and analysis cannot be limited to applications where the security team has explicitly installed sensors. Otherwise, forgotten legacy APIs will never be discovered and newly appeared phantom APIs will be missed.
Embracing the cloud is key to closing both of these gaps. It provides the cost-effective and scalable storage needed to collect detailed data from the widest range of sources, including API gateways, network devices, microservices orchestration solutions, and cloud providers. It also provides the computing power needed to perform modern behavioral analytics and artificial intelligence (AI) on these datasets.
3. Use AI to create security tools that think like attackers
Thinking like a threat actor is hard. A staggering amount of human intelligence and automation is projected into all forms of security threats, including API attacks and abuse. The only way organizations will succeed is to bring even more resources and creativity to API discovery, threat detection, and mitigation.
Behavioral AI is the key. Security professionals can never predict the future. Even experts will never be able to anticipate all the creative ways a malicious actor will attempt to abuse an API.
But organizations can establish a normal baseline for API usage and activity. Then, AI can be used to better understand which entities are using the APIs and if they are doing so as intended. Traditional application security methods are not designed to examine the context of commercial abuse. API security needs to think differently and be reinvented.
Comments are closed.