Application Security

6/25/2015
10:30 AM
Jeff Williams
Jeff Williams
Commentary
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail vvv
100%
0%

What Do You Mean My Security Tools Dont Work on APIs?!!

SAST and DAST scanners haven't advanced much in 15 years. But the bigger problem is that they were designed for web apps, not to test the security of an API.

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.

A pioneer in application security, Jeff Williams is the founder and CTO of Contrast Security, a revolutionary application security product that enhances software with the power to defend itself, check itself for vulnerabilities, and join a security command and control ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
planetlevel
50%
50%
planetlevel,
User Rank: Author
7/7/2015 | 2:15:02 PM
Re: More apt means of analyzing weakness
Please read my response to @jgilliam
planetlevel
50%
50%
planetlevel,
User Rank: Author
7/7/2015 | 2:14:25 PM
Re: More apt means of analyzing weakness
Great question, and an important topic.

I think we can agree that the goal is to find all the security vulnerabilities in an application as early in the process and with the minimal amount of effort and expertise required.

Ordinarily, then only way to tell whether a security vulnerability is really present is to exploit it.  That means that you need experts, have to craft exploits, etc...  Actually, static analysis doesn't require exploit, but it generates so many false positives, that you end up having to verify all the findings with an exploit anyway.

But the vast majority vulnerabilities *can* be observed without exploit, if you've instrumented the application so that you can see all the security relevant activity.  For example, if you walk into your house and nothing forces you to unlock a door... then you know an attacker could do the same.

In a web service, instrumentation can watch the data come from a JSON request, flow through the application, and reach a SQL query, without being validated, encoded, or parameterized.  Instrumentation has established that the application is vulnerable to SQL injection, and we didn't have to exploit it.

This approach can be used on a very broad range of application security vulnerabilities and is extremely accurate. All you have to do is use the application normally, and the instrumentation can tell you whether anything happened (or failed to happen) that an attacker could exploit.

There are, of course, some parts of the code that aren't normally executed.  For those, you have to send some specially crafted input.  But even those cases don't require exploit, just the right data to make the code execute so that the instrumentation can watch how the code runs.

You can (and should) use instrumentation throughout the lifecycle to gain security insight from the first moment a developer codes and tests locally, to continuous integration, QA testing, and staging.

Gartner calls this approach IAST (Interactive Application Security Testing), and the speed, accuracy, and process advantages over SAST and DAST are dramatic.  Neither SAST or DAST achieves good code coverage, and what's worse is that you'll never know what parts of the code were missed.

 
kbannan100
100%
0%
kbannan100,
User Rank: Moderator
7/2/2015 | 6:32:49 PM
Re: More apt means of analyzing weakness
Sounds like that to me, too! 

--KB

Karen J.Bannan, commenting on behalf of IDG and FireEye. 
jgillam
50%
50%
jgillam,
User Rank: Apprentice
6/29/2015 | 9:44:34 AM
Re: More apt means of analyzing weakness
It almost sounds like you are suggesting that it might be better to just test the security of things (houses, code) through normal use rather than with by attacking it.  Hopefully that wasn't your intention.  Application security testing (like any security testing) must be conducted with both regular and irregular usage, not just one or the other.  

I think you mean to say that in an ideal world we should be catching all the bad stuff during devepment cycles.  And I absolutely agree with that.  It is a failing of many organizations that applications are built and then tested rather than built while being tested.  However the types of tools mentioned in the article (DAST and SAST) should be used for that pre-production testing and particularly DAST tools should definitely be hitting the application or api or whatever with both "normal" traffic as well as attack traffic.  And if something breaks... well it is a good thing it just broke during a test, right?
RyanSepe
50%
50%
RyanSepe,
User Rank: Ninja
6/26/2015 | 2:43:37 PM
Re: More apt means of analyzing weakness
I agree to an extent. From a functionality standpoint you will most likely run into issues due to cross-app cryptography inconsistency. But if the app is stand alone internally and wasn't web based, this train of thought detracts from the scope of the article, then you could have a strong cryptology that has not been introduced publicly. Potentially making it more secure....if you have high expertise in cryptology of course.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
6/26/2015 | 9:40:13 AM
Re: Dropwizard API security
Yes, I read that. Interesting. Thank you.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
6/26/2015 | 9:39:41 AM
Re: More apt means of analyzing weakness
Today's frameworks are design in a way that security kept in mind. The only thing the developers should be doing to follow the guidelines. When they start becoming creative such as creating their own cryptography that is where you end up with problems.
planetlevel
50%
50%
planetlevel,
User Rank: Author
6/25/2015 | 10:26:00 PM
Dropwizard API security
Here's an interesting example of a security flaw in a popular framework used to build APIs.  https://github.com/dropwizard/dropwizard/issues/768

 

 
RyanSepe
50%
50%
RyanSepe,
User Rank: Ninja
6/25/2015 | 11:44:13 AM
More apt means of analyzing weakness
The last part of this article makes a very good point. Analyzing the application through normal use could yield better results than attacking. You would be able to discover the security pitfalls of your home through normal use and analysis instead of attacking it with mock intruding events. In the end, you could and probably would end up breaking things. Same with app security.


I also think its a good idea to point out that in the coding phase is when app sec should be continually reviewed. Today's agile methodology is very good at acknowledging this principle. If you don't ingrain security at every phase of the SDLC, it is hopeless to expect that post-creation testing will yield desirable results.
'PowerSnitch' Hacks Androids via Power Banks
Kelly Jackson Higgins, Executive Editor at Dark Reading,  12/8/2018
Windows 10 Security Questions Prove Easy for Attackers to Exploit
Kelly Sheridan, Staff Editor, Dark Reading,  12/5/2018
Starwood Breach Reaction Focuses on 4-Year Dwell
Curtis Franklin Jr., Senior Editor at Dark Reading,  12/5/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
10 Best Practices That Could Reshape Your IT Security Department
This Dark Reading Tech Digest, explores ten best practices that could reshape IT security departments.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-8651
PUBLISHED: 2018-12-12
A cross site scripting vulnerability exists when Microsoft Dynamics NAV does not properly sanitize a specially crafted web request to an affected Dynamics NAV server, aka "Microsoft Dynamics NAV Cross Site Scripting Vulnerability." This affects Microsoft Dynamics NAV.
CVE-2018-8652
PUBLISHED: 2018-12-12
A Cross-site Scripting (XSS) vulnerability exists when Windows Azure Pack does not properly sanitize user-provided input, aka "Windows Azure Pack Cross Site Scripting Vulnerability." This affects Windows Azure Pack Rollup 13.1.
CVE-2018-8617
PUBLISHED: 2018-12-12
A remote code execution vulnerability exists in the way that the Chakra scripting engine handles objects in memory in Microsoft Edge, aka "Chakra Scripting Engine Memory Corruption Vulnerability." This affects Microsoft Edge, ChakraCore. This CVE ID is unique from CVE-2018-8583, CVE-2018-8...
CVE-2018-8618
PUBLISHED: 2018-12-12
A remote code execution vulnerability exists in the way that the Chakra scripting engine handles objects in memory in Microsoft Edge, aka "Chakra Scripting Engine Memory Corruption Vulnerability." This affects Microsoft Edge, ChakraCore. This CVE ID is unique from CVE-2018-8583, CVE-2018-8...
CVE-2018-8619
PUBLISHED: 2018-12-12
A remote code execution vulnerability exists when the Internet Explorer VBScript execution policy does not properly restrict VBScript under specific conditions, aka "Internet Explorer Remote Code Execution Vulnerability." This affects Internet Explorer 9, Internet Explorer 11, Internet Exp...