When ships encounter bad weather and turbulence, they sail side-by-side because once they are tied together, they stand a better chance of weathering the storm. No matter how big they are, together they are less likely to capsize. People and businesses aren’t that different. We are willing to open up to new collaborations when hardship (pun intended) comes knocking.
With the speed of change accelerating around us, we need new and improved ways of collaborating. It’s understandable why API adoption is so strong in many industries. The use cases differ, but they all lead to increased information sharing, collaborative working and a shift toward open ecosystems that forge even more collaborations. As our recent survey shows, 4 out of 5 organizations already enable either partners (B2B) or users (B2C) to access their data using external APIs.
But this growing exchange of information doesn’t come without its fair share of risks. Having more APIs published and consumed also means more functionality being exposed. The business logic that was once hidden within an application can now be accessed - and potentially manipulated - directly. It’s not just the attack surface that grows, but also the increasing complexity of relationships between functions and data objects that creates new vulnerabilities.
You can ask Domino’s Pizza about the vulnerabilities created by the relationships between functions. In this case, the attacker was able to bypass the application and go directly to the API, initiating a fake payment process and manually activating the order confirmation function.
A lack of validation on the server side - order confirmation arriving only after successful payment - made this fraud possible. Thanks to the exposed payment approval process, tech-savvy ‘customers’ were able to rig the system so that it accepted invalid payments, providing them with free pizza.
New technology, new vulnerabilities
Attackers looking for cracks in APIs can employ a new attack style, one that traditional application security tools cannot detect: Functional Attacks. Understanding just what these new functional attacks are is critical for security professionals looking to secure their organization’s data, assets and clients.
APIs are considerably more vulnerable to functional attacks that target the expected API call flow. They look like normal requests for all intents and purposes, and are frequently not designated as such by standard protective measures. Unfortunately, this also means that general purpose application security solutions, like Web Application Firewall (WAF), aren’t enough for real API security.
While these security measures excel at detecting and blocking malicious API calls that match known generic vulnerabilities, they fail when it comes to detecting functional attacks. This is mostly because on the surface, functional attacks are simply calls made by authentic users. It’s only when the application’s behavior is analyzed that suspicions begin to arise.
Want to go deeper? Watch this webinar recording on functional attacks and the steps you can take to prevent them.
The API attack landscape
A closer look at the API attack landscape enables a better understanding of the risks posed to APIs by breaking them down into 4 distinct categories:
OWASP Top 10 API: API Security has a separate OWASP top-10 list (apart from the Web Application Security list), which provides a well-researched, detailed breakdown of the common vulnerabilities that have been exploited to abuse APIs. Many of the vulnerabilities are more technical and similar to those of applications, while others are geared towards exploitation of poorly designed functionalities, such as authentication and authorization flaws.
Functional attacks: Targets proprietary business logic that governs the API functionality which causes APIs to take actions they’re not supposed to.
User behavior: Several sub-categories including data scraping, execution of rare actions, lack of execution of common actions and other cases that indicate that the user is acting maliciously.
Reconnaissance: This is not an attack vector on its own, but the breadcrumbs hackers leave while learning how an API works and scanning for vulnerabilities can be identified, so the attack can be stopped before it happens.
The US Postal Service suffered a functional attack that displayed usage abuse for data scraping purposes. In this case, attackers realized that they could abuse a specific API transaction by slightly changing the call parameters with each request.
This made it extremely easy for them to automate and distribute the attack across different credentials and thus access the data they were trying to retrieve. They were able to achieve this without being detected, as the calls looked normal; the high volume, high frequency requests didn’t look like abnormal behavior on Postal Service’s wildly popular app.
The move towards ‘Open Everything’ accelerated the creation of open ecosystems and the deployment of transformative digital initiatives. APIs play a large role in this transformation.
While APIs have incredible benefits, they also come with significant risks. Each API represents a particular function. That means that a single API can talk to another API, and each API is actually a unique access point into the inner workings of an application.
Attacks on APIs are rapidly becoming the most common attack vector. Hackers eager to wreak havoc create functional attacks that manipulate API business logic to gain access to the private, sensitive data of others. Furthermore, there are no custom security measures developed to protect APIs. Functional attacks that target API business logic often go undetected, as they appear like normal API calls.
Having a security solution that learns each API’s unique business logic and detects the anomalous behavior that are functional attacks is key. The ability to automatically discover, test and protect your APIs has become more important than ever before.