What Do You Mean My Security Tools Don’t Work on APIs?!!

Mobile apps! Awesome JavaScript browser interface! Rich clients! Web APIs are everywhere!

Development teams are rolling out APIs – REST/JSON and SOAP/XML services that provide data and perform transactions – as part of every modern application. Old APIs are called web services, newer ones are called REST interfaces, microservices, or simply APIs. The benefits include rapid development, quality, manageability, easy integration, and more.

Unfortunately, there’s a catch. These APIs are just as susceptible to attack as traditional web applications. Anyone can easily intercept and modify the HTTP traffic being sent between the mobile banking application on their phone and their bank’s mobile APIs. Once you reverse-engineer the service API, you can try to hijack other users’ accounts, find injection vulnerabilities, access other user’s data, and all the other common attacks.

Generally, the client-side of these applications isn’t particularly risky. Perhaps some DOM XSS. But the APIs protect all the data for all the users. So we desperately need a way to verify their security. There are plenty of scanning tools for finding vulnerabilities in web applications – but even though they talk HTTP, these services work differently.

So the question is whether our current security tools are appropriate for APIs. Unfortunately, the answer is no. SAST and DAST were designed for web applications from the early 2000’s, and they haven’t advanced much in the last 15 years.

Dynamic Scanners Don’t Work on APIs
There are plenty of “dynamic” or DAST scanners to test the security of web applications. They send HTTP requests containing attacks and check the responses to see if the attack worked. Sometimes there is clear evidence of a vulnerability in the HTTP response, such as a cross-site script in the HTML. But usually the evidence is less clear, such as when you send a SQL injection attack and the response is a 500 error. Was there a SQL injection? Or did the application just break?

This problem is exacerbated when you want to test the security of an API. The scanning tool can’t invoke the API because there’s no way for it to know how to generate well-formed requests. Even if you know that the request is JSON or XML and you have some kind of schema for the API, it’s still exceptionally difficult to provide the right data to automatically invoke an API correctly. Many applications use custom, non-standard protocols, and data structures for their APIs. Applications using Google Web Toolkit (GWT), for example, has its own custom syntax and can’t be scanned without a custom scanner.

Static Analysis Tools Don’t Work on APIs Either
There are also “static” or SAST scanners. These tools scan source code and attempt to piece together how the application runs and how the data flows work. These tools often miss vulnerabilities and report false positives because they simply can’t trace the complex maze of program execution, state management, validation, encoding, and other common programming idioms.

But with an API, this problem is far worse. Static tools are designed to look for standard “source” methods such as request.getParameter() and trace the program through. Unfortunately, in a typical API, third-party frameworks and libraries use custom methods to read a JSON or XML document from the body of the HTTP request, parse it, and pass the data into your API code. Every framework does this differently, and they are simply too complex for static tools to properly analyze. So by the time your static vendor provides support for a framework, it’s probably already legacy.

Security Instrumentation to the Rescue
If you’re currently using scanners to verify the security of applications that publish APIs, you may have that false sense of security that comes from attempting to scan the unscannable. The scan runs and reports nothing… Are you secure? Or did the tool not understand?

Fortunately, there’s a different way to verify APIs and other services. Instrumentation simply means adding some monitoring code to your application at runtime. This technique is often used to add logging or timing code to a service or application.

Security instrumentation solves the problems that prevent DAST and SAST from working on APIs. First, security instrumentation means that we don’t have to attack the application to find vulnerabilities. So we don’t have to figure out how to invoke the complex APIs. Instead, we can watch how normal application behavior works.

Second, security instrumentation means that we don’t have to build a complex model of the application. Instead, we can directly analyze the actual running application itself. This allows us to trace the control and data flow of complex API frameworks as they execute, enabling highly accurate insight into the security-critical details that reveal vulnerabilities.

Direct observation of running code with instrumentation has already revolutionized web analytics, performance management, and other software-related disciplines. Commercial products like New Relic and AppDynamics have allowed performance engineering to evolve from something that only experts could do with their expert tools, to something everyone can do for themselves. This is the transformation we desperately need to scale application security. We can use security instrumentation to make application security better, faster, and most important, relevant to the types of modern applications that developers are building today, including APIs.