SoftwareSecurity2012/Group 7/Code Scanning

RIPS

RIPS is basically a static code analysis to find known and unknown flaws within any web application. We have used RIPS 0.53 to analyze the security flaws present in FluxBB, which is a web application for an online forum. The data gathering using RIPS took about 5 - 8 minutes on our laptop.

Figure 1. overall result of RIPS

RIPS can be used in different levels of operation based on the level of tainting. It also gives the option of performing the analysis based on server-side or client-side vulnerabilities. We used RIPS in all possible combinations and we compare the extent of results here. The number of warnings for each level of operation are summarized in the table below.

	Level 1	Level 2	Level 3	Level 4
Server-side	11	18	53	894
Client-side	56	59	405	3341

Level 1: User tainted only
Level 2: File/DB tainted + level 1
Level 3: Show secured + level 1, 2
Level 4: Untainted + Level 1,2,3

Looking at the output produced by RIPS, we see that it clearly differentiates between different types of vulnerabilities such as File inclusion, Cross-site scripting, etc. It also gives us the option of analyzing from the server-side perspective or the client-side one. We have seen in our results that RIPS produces warnings for a particular piece of code and then lists a number of PHP functions which may be also triggering that vulnerability. This information is very useful while analysis especially if one identifies critical portions of the code and can check for these in the output deliberately. We also find that RIPS looks for Cross-site Scripting vulnerabilities in functions like admin_permissions.php, login.php, etc., which are critical from the Access Control point of view which is the Verification requirement that our group is focusing on. We identified these files to be critical from our security requirement's point of view and hence any attacks on these files, if identified, can be helpful for analysis. However, for our present analysis based on the verification requirements as mentioned in the ASVS document, we get precious little relevant data from this tool. We realized after looking at our output that Access Control is a security requirement which is hard to verify using automated tools. Nevertheless, RIPS does provide quite a lot of meaningful output about critical files but we get the feeling that automatic verification is more useful to other groups than ours. Given that automated analysis has very little scope in our analysis, we still feel that the RIPS was comparatively better than output produced by the other tools.

YASCA

We have used Yasca version 2.2 for our analysis. The output provided by Yasca is in the form of a webpage and can be opened directly in the web browser. Yasca also gives us the opportunity to use tools like RATS and PHPLint as plugins to it. Whe we use Yasca with RATS and PHPLint as plugins, it produces an output which contains the warnings from all three tools. A screenshot of the output from Yasca is shown below in Figure 2.

Installation

Installation(yasca-core 2.2) in Windows 7 64bits:-

In the command line go to the directory where yasca is extracted. Example-

C:\Users\user\Desktop\Yasca

Once you are in the directory,start analyzing the project. Example-

C:\Users\user\Desktop\Yasca> yasca.exe C:\Users\user\Desktop\fluxbb-1.5.0

Running along with the plugin.

yasca –p plugins/PluginName.php <target directory>

Output

The report produced total 103 errors while running only the yasca tool.

Figure 2. Yasca result

Yasca also categorizes the different vulnerabilities and groups them together in the output. Moreover, it provides different severity levels of warning with different color codes. The severity levels range from "Critical", displayed in Dark Orange, "High" in Light Orange, "Warning" in Yellow, "Low" in Light Blue and "Warning" in Light Green. Each severity level is further categorized into the type of vulnerability such as W3 Core vulnerability, Cross-site Scripting, etc.

When RATS and PHPLint are used as plugins, the warnings from these tools are also categorized under the severity levels and are grouped accordingly.

It is possible for Yasca to give basic summary grid result where each column in the grid represents a particular vulnerability (e.g. W3 core, Cross site scripting). This grid contains information about every function of the application and produces one row per function. It is a very useful feature of the Yasca tool as we can easily find out about the vulnerability in each function.This feature may be useful for us when we look specifically at functions which deal with Access Control of the application. It will provide us with an overview of vulnerabilities in any particular function at a quick glance. The grid is displayed in the figure below in Figure 3.

Figure 3. Basic Summary Grid

However, as mentioned in the RIPS section, most of the vulnerabilities mentioned by the tool are not relevant to access control and hence Yasca is not that useful for this particular security requirement.

RATS

We used RATS as a plugin for Yasca (figure 2) and we also tried it as a separate standalone scanning tool in VM linux, and we found it hard to see any essential data if we analyze it as standalone because it is only plain XML-based data. When we used RATS as a plugin for Yasca, it produces warnings for most of the php files of the FluxBB project. The data is much more understandable when we used RATS as a plugin and we could at least interpret the warnings.

We can also see in Figure 2 that RATS also looks at file operation vulnerabilities where it flags any untrusted source trying to pass any parameters to PHP functions related with file access. This is possibly related to Access Control which is our Verification requirement. However, we could not answer any of the verification requirements mentioned in the ASVS using the data produced by this tool

PHPlint

PHPLint as Yasca plugin

PHPLint is a tool which looks mostly at the syntax of the code which it analyzes. It did not classify the warnings under vulnerabilities. We used PHPlint as a plugin to the Yasca tool. Some results are shown in the Figure 4 below.

Figure 4. PHPlint as a plugin for Yasca

PHPLint gave a lot of warnings about the code it analyzed but they were mostly related to syntax issues within the code. It mainly looked at things like assignment and declaration of variables and functions and flagged irregularities. We acknowledge that these are important issues in the code but they are not related to the Level 2 requirements of access control as written in the ASVS document. It did not focus that much on the security vulnerabilities that might result from any irregularities in the code and hence we feel that it might not be very useful for our current project.

PHPLint - Standalone mode

When used as a standalone tool, PHPLint is installed as an command line utility. With the use of activeTCL, it is possible to create a GUI for PHPLint. The difference between PHPLint running as a standalone tool or as a Yasca plugin is that it provides a much more detailed scan when used as a standalone tool. This is convenient for more in-depth debugging and analysis. The standalone tool is not meant to scan a whole directory that is why Yasca is a better way to perform a scan to generate a better overview of the PHP application. An example of the GUI output of PHPLint is given in Figure 5 below.

Figure 5. PHPlint as a standalone tool - Example output

The figure shows Errors and Warnings of a test buggy file. The red circle shows that "Pi" can be declared in a better way which is also mentioned in the debugging. Solutions and hints are given by PHPLint. Therefor the feedback is very good. We provide an output screenshot if we use PHPLint to scan the admin_permissions.php file from the FluxBB source in Figure 6.

Figure 6. PHPlint as a standalone tool - Scan of FluxxBB\admin_permissions.php

In Figure 6 we see different errors and warnings. However, PHPLint gives feedback on programming errors (or suggestions to improve the programming) but it does not offer a great deal in terms of identifying security vulnerabilities. Looking at all these errors/warnings, one has to interpret as to how they would translate into security vulnerabilities. This is very time consuming and therefore, we think that RIPS is better suited to perform code scanning with respect to security requirements.

Doxygen

In order to review source code it is necessary to have a good understanding on how the web application works. We use Doxygen (which is a php code documentation tool) to create the necessary documentation required in order to understand how the FluxBB application works.

In Figure 7 we can see how all the variables are summarized and information about these variables is shown. It lists all the php files, the functions present in these files, the data items and all the constituents of the entire project in an organized manner. It makes debugging/understanding the FluxBB application a little bit easier.

Figure 7 - Doxygen output

System specifications

This section contains the systems that we use during this project. The five of us used two different Virtual machines, both of which are described below. The purpose of this section is for discussing compatibility issues. For example: If Marco mentions in the log that he is having compatibility issues and can't run a specific tool then other groups can save time and use this information to their benefits. Sharing is caring :-)

Marco: [Virtual machine]

Windows Server 2008 Enterprise SP1 1GB RAM 32-bit

IIS v7.0

MySQL server v5.1

PhpMyAdmin v3.5

FluxBB v1.4.8

RIPS v0.53

RATS v2.3 (Command Line)

Yasca v2.1

PHPLint v1.1 (GUI plugin -> ActiveTCL 8.5)

Doxygen v1.8.0

Terence: [Virtual machine]

Windows XP SP3 1GB RAM 32-bit

IIS 6

MySQL server v5.1

PhpMyAdmin v3.5

FluxBB v1.4.8

RIPS v0.53

Yasca v2.1

RATS (Yasca Plugin) v2.3

PHPLint (Yasca Plugin) v1.1