Even ‘Perfect’ APIs Can Be Abused

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 a precise vocabulary for both, describing and defending against highly specific types of API threats.

While the true meaning of “API attacks” is poorly defined in many peoples’ minds, it’s actually one of the most pressing risks that even very sophisticated users of APIs face. It’s also a threat category that is largely unaddressed by the industry’s existing API security frameworks and guidelines.

In order to keep API-based commerce secure and trustworthy, the industry must evolve its thinking, terminology, and tools to account for the diverse set of API threats companies now face — and the rapid speed at which the API threat landscape is evolving.

Not All API Attacks Leverage Vulnerabilities
Traditional application security deals with vulnerabilities such as those itemized in the OWASP API Top 10. In this case, vulnerabilities are defined as deficiencies in the API implementation, its deployment, or its configuration that expose it to potential exploitation. Vulnerabilities can be found and remediated. There is already a significant focus during the development life cycle (SDLC) on scanning the code and running dynamic analysis to find API vulnerabilities early.

Attacks are the act of an adversary actively exploiting an application for a gain. Some attacks leverage vulnerabilities, but even perfectly designed APIs can be abused if the attacker is using legitimate credentials.

APIs expose core business logic and sensitive data to the outside by design. In order to steal data or conduct fraud, the attacker just needs to use the right API with the right credentials. The reason why many successful attacks are hard to detect is because they hide within authorized traffic. Attackers or rogue third parties can use these authorized channels to conduct unauthorized activities.

These attacks go way beyond known vulnerabilities. When attackers use authorized access, they can perform “API abuse.” Today, API abuse is the riskiest attack for targets because valid credentials are used to access or manipulate data or conduct fraudulent transactions. Because the credentials are valid, the access and manipulation is allowed and the damage is done. API abuse can include:

• Using APIs in unsanctioned ways for malicious reasons. In these cases the APIs are technically used as designed, but by the wrong person or for the wrong reason. Data scraping is one example.
• Exploitation of vulnerabilities in application logic. These abuses are specific to that particular business and, in many cases, not addressed through the well-known OWASP framework.

API abuse is a useful way to think about how a threat actor could attack an API to put it to work in a manner that doesn’t comply with what the API’s developers and product managers who created it intended.

How Big a Problem Is API Abuse?
In short, it’s a big problem. Some organizations find false comfort in the fact that their APIs have been assessed for vulnerabilities and appear safe or “perfect.”

Even those organizations that do bring a proactive focus to application security tend to put more emphasis on protecting APIs created for web and mobile applications. In these cases, many organizations often incorrectly assume that their web application firewalls (WAFs) will bear much of the load of securing this type of API usage.

But the biggest API protection gap intended — even in sophisticated organizations — is protection of APIs that are open to partners. These APIs are ripe for abuse. Even if they are perfectly written and have no vulnerabilities, they can be abused in unanticipated ways to expose the core business functions and data of the organizations that share them.

Perhaps the best example of this is the Cambridge Analytica (CA) scandal that rocked Facebook in 2018. As a brief refresher, CA exploited Facebook’s open API to gather extensive data about at least 87 million users. This was accomplished by using a Facebook quiz app that exploited a permissive setting that allowed third-party apps to collect information about the quiz-taker, as well as all of their friends’ interests, location data, and more.

This information — and the demographic and psychographic profiles derived from it — was then sold to various political campaigns and movements. The full impact of this may never be known, but it is generally acknowledged that it had a material effect on the 2016 US presidential election and UK’s “Brexit” referendum. It also led to an immediate market cap hit for Facebook in excess of $100 billion, billions more in fines, and an ongoing spot 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 ways that were not intended or anticipated when it was created. Facebook exposed a core business API that was ultimately abused.

What Does This Mean to Businesses in 2022?
Obviously, the Facebook example is extreme. Still, broad-scale API abuse is occurring every day as businesses increasingly make their digital crown jewels available to trading partners — and even the public — through APIs.

Consider the online banking, budgeting, and financial planning applications and services that many of us now use every day. APIs are the key to making these types of conveniences work. But consider the value of the data now accessible through fintech APIs and the potential for abuse that exists. Every API that is developed is a window to your business — and, as such, can be abused.

Beyond the obvious concerns about user privacy, abuse of these APIs can have a devastating impact on the financial firms themselves. For example, if you were an unscrupulous mortgage firm, wouldn’t it be interesting to see the current mortgage payment of a large number of bank users and perhaps cross-reference it with home value information scraped from Zillow to identify the best refinancing candidates?

Similar risks exist across nearly all major industries now that so much of our daily business-to-consumer and business-to-business commerce is conducted online through APIs.

Approaching API Abuse Systematically
The industry is obviously not beginning at square one with API security. Existing best practices and resources like the OWASP API Top 10 give security professionals an initial road map. But organizations need to view the elimination of API infrastructure vulnerabilities as a starting point, not an end game. The real API security battle will be won by developing strategies for stopping API abuse. The industry needs to evolve in three important ways to be successful at addressing 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 for discovering, documenting, and remediating vulnerabilities (think MITRE CVE).
• Building a living knowledge base of known attack techniques (think MITRE ATT&CK).

In the API security space, OWASP API Top 10 gives a place to start for the first. While there is still more work to do to deconstruct each broad vulnerability type on the list into discrete sub-areas that API teams should focus on, it is still an excellent blueprint for proactive avoidance of API infrastructure vulnerabilities.

But very little has been done to date to truly understand and document the many ways that APIs can be abused. The area needs to be proactively addressed before attackers have undue advantages.

2. Dramatically Expand the Amount of API Data for Analysis
Many early API security efforts have focused on monitoring individual API calls or, at best, short-term session activity. This isn’t sufficient. Evaluating single requests or sessions cannot provide 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 as well. So API monitoring and analysis approaches must evolve to analyze data sets that cover 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 had explicitly installed sensors. Otherwise, forgotten legacy APIs will never be discovered, and newly appearing shadow APIs will be missed.

Embracing the cloud is key to closing both of these gaps. It provides the economical and scalable storage needed to collect detailed data from the widest possible array of sources, including API gateways, network devices, microservices orchestration solutions, and cloud providers. It also provides the computational power necessary to perform modern behavioral analytics and artificial intelligence (AI) on these data sets.

3. Use AI to Create Security Tools That Think Like Attackers
Thinking like a threat actor is difficult. A staggering amount of human intelligence and automation is being thrown into all flavors of security threats, including API attacks and abuse. The only way organizations will be successful is to bring even more resources and creativity to API discovery, threat detection, and mitigation.

Behavioral AI is the key to this. Security professionals will never be able to predict the future. Even experts will never be able to anticipate every creative way that a threat actor will try to abuse an API.

But organizations can baseline normal for API use and activity. Next, AI can be employed to better understand the entities using APIs and whether they are doing so as intended. The traditional methods of application security are not built to look at the context of business abuse. API security needs to think differently — and be reinvented.

Read More HERE