The Spring4Shell exploit was, really, quite elegant.
The critical remote code execution (RCE) flaw wasn’t an application programming interface (API) vulnerability, but it was an autobinding vulnerability of the type that can easily apply to APIs. It tricked the Tomcat logger into writing a new JSP file that could do anything the attackers wanted: All they had to do was browse to it.
Spring4Shell is important because the vulnerability was nobody’s fault. Spring — the open-source application framework that provides infrastructure support for developing Java applications — had a good defense in place. So did the developers writing the code. It was simply an interaction between components that caused the problem to be so serious.
Spring4Shell is an example of how securing APIs is drastically different from securing applications. While APIs are just as hackable as traditional web apps, many are surprised to find that securing APIs isn’t the same as application security. You may well think that our current security tools are appropriate for APIs, but alas, they aren’t. Static Analysis Security Testing (SAST) and Dynamic Analysis Security Testing (DAST) — where the scanners lack visibility into just what, exactly, they’re scanning — were designed for web applications from the early 2000s, and they haven’t advanced much since then.
Spring4Shell is just one example of why API security demands a modern approach — one that embeds instrumentation into the guts of code to analyze what’s happening in all components, including in all the libraries, the API server and platform components. When you think about API security, you need to think about problems that come from all of those sources, be they from code, libraries, platform frameworks or the interactions between those pieces.
API security boils down to the five areas below. In this series, we’ll dive into one each week — starting next week — to show how a modern, integrated API security platform manages to accomplish what traditional API or application security can’t do: namely, to secure APIs from the inside out.
Stay tuned: Next week, we’ll be looking at API inventory and why Contrast focuses on runtime inventory. The way we see it: Why bother with never-invoked, dead-weight code that’s just hitching a ride on your binaries?
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: