Perfectly Coded APIs Can Be Susceptible To Attack

Uploaded on 2023-01-20 in TECHNOLOGY--Resilience, FREE TO VIEW, BUSINESS-Services-IT & Telecoms

An Application Programming Interface (API) is a way for two or more computer programmes to communicate with each other - a type of software that offers a service to other pieces of software. API development has seen an over emphasis on ‘shift left’, whereby security testing, quality and performance are carried out solely in the development process rather than throughout the entire release cycle.

While this has allowed departments to develop and roll out their own “secure” APIs, it assumes that the developer is happy to ‘mark their own homework’ and fix the code when many hate this aspect of the job.

But there’s another more serious danger in that it creates a false sense of security. The assumption is that APIs that go live are then bullet proof.

In reality, while shift left efforts are beneficial, no measures will stop a persistent automated attack. If the assets being protected by that API are attractive enough, attackers will persist and will compromise it usually by using its own functionality against it in an attack known as business logic abuse.

Even if the API is coded perfectly correctly, adheres to the API specification it is designed against, and is properly inventoried and has been tested to ensure it is not susceptible to any of the OWASP (Open Web Application Security Project) Top Ten API Threats, it can still be probed and compromised.

Research conducted during the first half of 2022 reveals that APIs were subjected to automated business logic abuse in numerous ways. Over three billion shopping bots were used to target well-formed APIs with a dense network of highly volumetric and geographically distributed fuzzing payloads. Over 290 million malicious gift card requests used enumeration based on fuzzing the numeric patterns on APIs that support payment and checkout microservices. And there were over 37 million comment spam requests detected against customer relationship management workflows.

Combined Assaults

Perfectly coded and inventoried APIs take more effort to compromise and so attacks will typically use multiple methods from the OWASP Top Ten. For instance, we’ve seen something we call the attack trifecta where attackers used API2 (Broken User Authentication), API3 (Excessive Data Exposure) and API9 (Improper Assets management), to perform detailed reconnaissance and analysis of how each API works, how they interact with each other, and the expected outcome. That information was then used for malicious purposes.

Another real-world example is the Ulta Beauty case study where a large scale enumeration attack was executed against a third party inventory API. The inventory search API supplier notified the company security team of a traffic surge, requesting help to stop the attack. The investigation mapped the attack to OWASP API4 (Lack of Resources and Rate Limiting) and API5 (Broken Function Level Authorisation).

Initially, the attackers targeted the web API before moving to the mobile API which provides similar information. The attack targeted the inventory API directly, without hitting any other app or web function (in contrast, normal behaviour would show the user traversing multiple APIs, generating upwards of 40-50 cookies as they browsed the inventory, whereas the attack generated just one).

Originating from residential proxy IP addresses, the attack rotated through 153,000 unique product and SKU combinations while scraping 61,000 ZIP codes and 33,000 products but Web Application Firewall (WAF) and Content Delivery Network (CDN) mitigation efforts were ineffective. It was only stopped by policies that effectively blocked 85.9 million requests.

The Difficulty Of Detection

In this particular case the company was alerted by its provider but how can businesses spot attacks against what they consider to be secure APIs? Web Application Firewalls (WAFs) or bot prevention tools are ineffective at preventing an API specific attack for several reasons.

WAFs use signatures to detect known vulnerabilities as described in the OWASP Web Application Top 10 Threats list so will struggle to find and block attacks that appear legitimate, and they are unable to address the entire API protection lifecycle. Bot tools rely on JavaScript instrumentation to collect the telemetry required to understand and block the attack. As an API is clientless, it cannot be instrumented in this manner. Consequently, those that believe their APIs are secure and rely on traditional web security tools are lulled into a false sense of security.

The first step in any API protection initiative should always be a runtime inventory. This automatically logs all known and unknown endpoints, helping to discover and prioritise APIs by assessing the risk they represent, and applying sensitive data exposure protection and business logic abuse protection. The next step is to protect the APIs from attacks using Machine Learning to determine the intent of transactions (whether performed by bots or individuals) and then quickly block them or send them down another path.

With runtime security covered, development teams should look at more API specific testing solutions to complement and strengthen existing shift left efforts. Dynamic Application Security Testing (DAST) solutions that use specifications and documentation to understand how an API works, then looks for vulnerabilities should also be considered. Traditional web-focused testing tools lack the ability to derive the API context needed to test and find gaps and this is where DAST can really add value.

There also needs to be acceptance that, while shift left is helping organisations deliver more secure APIs, even a perfectly coded API can be attacked. The OWASP Top Ten lists are useful, but should be viewed as a starting point.

Until we face up to the fact that all APIs will fall to a determined attacker, we can’t begin to adequately protect them.

Andy Mills is VP for EMEA at Cequence Security

You Might Also Read:

Types Of Security Testing Explained With Examples:

___________________________________________________________________________________________

If you like this website and use the comprehensive 6,500-plus service supplier Directory, you can get unrestricted access, including the exclusive in-depth Directors Report series, by signing up for a Premium Subscription.