Building a modern API security strategy — API protection

Part four of the five-part series, Building a modern API security strategy.

Another Log4j or Spring4Shell could happen tomorrow. 

A zero-day vulnerability could lead to a total compromise of your organization’s vulnerable applications or application programming interfaces (APIs). 

“Log4j is not over,” states a recent report (PDF) from the Federal Cyber Safety Review Board, which added that “vulnerable instances of Log4j will remain in systems for many years to come, perhaps a decade or longer” and that “significant risk remains.”

Are you ready? 

If it isn’t a zero day, it could just as easily be a vulnerability in your custom API code. APIs can have almost all of the same vulnerabilities that traditional web applications have, including SQL injection, server-side request forgery, unsafe deserialization and many more.

In order to protect production against attacks like these, you’ve got to identify probes and attacks on both known and unknown vulnerabilities and prevent exploits. But in order to do it right, you need to understand the unique challenges presented by API protection.

The challenge of protecting APIs

Here are just four of the most serious security challenges involved in the protection of web applications and APIs:

1. Real attacks are difficult to identify. Every API has its own unique vulnerabilities that can only be exploited with a specific attack. An HTTP request that's completely harmless for one API could be devastating for another.
2. Modern APIs consume complex formats like JSON, XML, serialized objects and custom binary formats. These requests use a variety of protocols beyond just HTTP, including WebSocket, which are generated by JavaScript in the browser, rich clients, mobile applications and many other sources.
3. Traditional defenses simply aren't effective. Web Application Firewalls (WAFs) operate entirely separate from APIs by analyzing HTTP traffic before it reaches the API server. And although most large organizations have a WAF in place, many lack the teams and expertise required to do the tuning necessary to keep it operational, leaving it in "log mode" only.
4. Software is moving fast, and there’s been an explosion of containers, infrastructure as a service (IaaS), platform as a service (PaaS), virtual and elastic environments. These allow APIs to be deployed quickly, but they also expose code to new vulnerabilities.

Traditional API security won’t let you sleep through another Log4j 

While traditional technologies such as intrusion prevention systems (IPSes) and web application firewalls (WAFs) are often used for API protection at runtime, they work in-line as they inspect network traffic and content. This includes many new “API Security” products. As they analyze traffic and/or user sessions to and from apps and APIs, they have no visibility into how traffic and data are being processed within these components. Note that access to the OpenAPI definition of an API is of little help in identifying attacks.

Fortunately, Runtime Application Self-Protection (RASP) can address many of these concerns. RASP provides two key capabilities: First, it creates visibility into exactly who is attacking you, what attack vectors they are using on your APIs and which of your APIs is being targeted. Second, RASP prevents most of the major classes of vulnerabilities from being exploited, including both zero days and custom code flaws. 

RASP works very differently from WAFs. RASP uses instrumentation to add lightweight security sensors to your API code and platforms. These sensors can directly measure security relevant behavior of your APIs and detect malicious events. Unlike perimeter defenses, instrumentation and sensors accurately track attacks and prevent vulnerabilities from being exploited, giving users a firm yes or no regarding whether the exploit reached its target. It protects against a broad range of zero-day attacks without tuning or reconfiguration.

Working from inside APIs themselves, RASP security is able to detect, block and mitigate attacks immediately, protecting as they run in realtime by analyzing both their behavior and context. By using the app or API to continuously monitor its own behavior, RASP has the ability to protect an API from data theft, malicious inputs and behavior, without human intervention. It gives AppSec, SecOps and Dev teams accurate, detailed information, including the payload, full HTTP request, exact lines of code, queries executed, files accessed and more.

RASP protection can be used until the underlying vulnerabilities can be addressed. This gives both Dev and Ops breathing room by reducing lengthy and disruptive security fire drills, minimizing sleepless nights wrought by zero days. Instead of insomnia, it brings deep security instrumentation to gain insight into exactly how attacks behave, automatically weaving visibility and protection directly into APIs, without requiring any API changes. 

RASP provides highly effective protection against both custom code vulnerabilities and zero days. In fact, RASP prevented both Log4Shell and Spring4Shell from being exploited long before the vulnerability was discovered or disclosed. This is because RASP fundamentally prevents the techniques used in those exploits, including expression language injection and unsafe deserialization, from being used maliciously.

These protections have been in our product for years: years before those CVEs were ever discovered. In short, if you were using Contrast Protect when Log4Shell or Spring4Shell hit, you were protected, period. 

No patching, noted one relieved customer. No need for server updating. Just the peace of mind that comes with Contrast Protect with RASP. 

The five parts of API security

Last week, we looked at API components. 

Stay tuned: Next week, we’ll be looking at the ease of use of Contrast’s API security solutions. 

For a guide to all five parts of Contrast’s series on forging a modern API security strategy, check out this overview. 

Also, be sure to check out this discussion between Jeff Williams, Co-Founder & CTO, Contrast Security, and Melinda Marks, Senior Analyst, ESG Research, where they unravel: 

• What the future of API security holds for enterprises.
• What you need to know to secure your APIs.
• Strategies to stay ahead of the CI/CD lifecycle game.
• The path forward to building unified developer and security teams that can build secure APIs. 

To download the recorded webinar: