A few weeks ago, I investigated a customer report of a false positive. The issue was a Path Manipulation found in a web application that allows users to upload zip files. The program validates the uploaded filename, ensures it is alphanumeric and ends with “.zip”. The program then opens the zip file and unzips everything into a specific folder. Here is some representative code:

		ZipInputStream zin = new ZipInputStream(...);
		while((entry = zin.getNextEntry()) != null) {
			// SCA reports Path Manipulation in the following line
			File file = new File(dir, entry.getName());			
		}    
    

It took me just 10 minutes to write a test program to prove to the customer the file name stored in ZipEntry is an unvalidated string and can contain anything, including "../". The reported Path Manipulation is a true positive because an attacker can cause a file to be written to an arbitrary location.

And then I realized he would not be the only developer who believes ZipEntry is “safe”. I did some simple tests with the following zip files and unzip implementations:

• Test case1: a zip file with a dot-dot-slash entry "../abc.def"
• Test case2: a zip file with Unicode dot-dot-slash entry "%C0%AE%C0%AE/abc.def"
• Test case3: a zip file with an absolute entry name "/abc.def"
• Test case4: a zip file with a special character between dot-dot ".%03./abc.def"

Name*	Vulnerable?	Comment
7zip 9.2	No	It will strip “../” and continue to run without error
WinXP SP2 Built-in Uncompress	No	It will prompt error message and stop
WinRAR 3.71	No	It will strip “../” and continue to run without error
Win32 unzip 5.42	YES
Linux unzip 5.52	No	It will strip “../” and display a warning message
JDK 1.6.0_23 "jar"	YES
Tomcat 5.0, 5.5, 6.0	YES
Tomcat 7.0.8	No	It will throw exception

* These are zip programs already installed on my laptop

For Tomcat, I created a WAR file with an entry “../ROOT/index.html” and successfully overwrote the ROOT home page in Tomcat 5.0, 5.5 and 6.0. However, Tomcat 7 is not vulnerable and will throw an exception. But even if you are running a vulnerable version of Tomcat, you probably don’t need to rush to upgrade to Tomcat 7 unless you are running a J2EE web hosting service. If anyone can deploy an application to your Tomcat server, you have a bigger problem than Path Manipulation.

Time and time again, we hear complaints from our SCA customers about reporting vulnerabilities without taking validation logic into consideration. While deciding whether the data are properly validated is out of the question for any automatic tool (a discussion worthy of a separate blog post), there are a number of things the tools can do to aid the auditor in deciding the criticality of the finding. To start off, the analyzer can reprioritize the findings based on whether any kind of validation mechanism is detected during the scan. Obviously, the analyzer needs to base its decision on some piece of evidence, so why not show this additional information to the auditor? That way, instead of spending time digging through the application source code looking for this information, the auditor can concentrate on actually determining whether the validation mechanism is doing the right thing. Finally, it would also help a lot if the auditor could quickly search for reprioritized findings and easily distinguish them from those that were not.

We call this feature Context Sensitive Ranking (CSR). And guess what? You can take advantage of it now if you use Fortify 360 v3.0 together with Q1’11 update to the Fortify Secure Coding Rulepacks. At this point, we support four validation frameworks: Struts I and II on the Java side and Microsoft ASP.NET Request Validation and WCF on the .NET side. To further illustrate this exciting feature, let’s consider an example.

Above is a screenshot of a cross-site scripting finding in a sample web application scan project opened in the Fortify Audit Workbench. The application is written with Struts I framework. In Struts I, the application defines a set of action forms that represent input supplied by the user, a set of actions that can be performed on the data, and, optionally, a set of corresponding validators that get invoked implicitly by the framework and make sure that the data supplied by the user are well-formed. Cross-site scripting findings are usually prioritized as critical, but if we zoom in on the Issues view of the AWB, we can see that this particular cross-site scripting finding appears under the High folder. This is because it has been reprioritized by CSR.

The finding shows that the application is vulnerable to cross-site scripting because user input enters the application via the name field of the XSS20Form and gets written to the web page. So how does context-sensitive ranking help the auditor decide the criticality of the issue?

If we expand the arrow next to Struts Validation in the Analysis Evidence view, we get to see additional evidence accompanying the finding. We can see that the application defines the validator for the name field of the XSS20Form. The auditor can now review the logic behind the validator to decide whether it is sufficient to prevent cross-site scripting. And to top it all, the auditor can use the Data Validation filter set in order to quickly identify the findings that are reprioritized when validation logic is detected by the SCA engine. The cross-site scripting issue we are discussing here appears under the Struts Validation folder.

Context Sensitive Ranking applies to any type of vulnerability and any type of context. Even though in the first incarnation of the feature the focus was on validation frameworks, we are planning on extending CSR to other types of contexts. And of course, we’ll keep you posted on our progress.

Real-Time Hybrid Correlation addresses the problems of individual vulnerability detection techniques by correlating vulnerability data from multiple sources. The most common complaint a security practitioner has when looking at results from a black-box analysis, like HP's WebInspect, is that the results are hard to act on. The most common complaint when looking at static analysis results (like Fortify SCA) is that they are prone to false positives. Correlating the results of both of these techniques overcomes the shortcomings of both to produce reliable, actionable results.

We have shown that we can enhance SCA to produce information which can glue black-box analysis results and static analysis issues together. Now we are providing a second key element, called Fortify SecurityScope, that produces the "glue" information required for correlation. SecurityScope has the unique capability to see both web request and the execution of the code. The complete workflow, and how all of these pieces fit together is shown below.



In action, the information gathering and correlation process goes as follow. First, the attack web request (http://company.com/index?name=‘ or '1'='1) is made by WebInspect to the webserver and is recorded by both WebInspect and SecurityScope. A unique id (ID=234) is used to correlate the WebInspect with the SecurityScope results. Second, SecurityScope inspects the executed code (NewClass.java:27) and searches for similar, known issues produced by SCA. SCA reveals the analysis evidence in the code (Source: in.jsp:33:getParameter(), ..., Sink: NewClass.java:27:java.sql.Statement.executeQuery()). The result is three pieces of solid evidence for one issue.

This approach is extremely valuable in rooting out server-side injection bugs. Black-box analysis tools do a great job sending out attack vectors to the application, but they have problems validating the intended impact of the attack on the server-side components and pointing out the problem in code. SecurityScope augments black-box testing by validating the attack. SCA does great job pointing out the problem in code. Combined, these three techniques will revolutionize the way we do software security.