SoftwareSecurity2012/Group 6/Code Scanning

Uit Werkplaats
< SoftwareSecurity2012‎ | Group 6
Versie door S4159721 (overleg | bijdragen) op 18 jun 2012 om 22:10 (Code Secure)
(wijz) ← Oudere versie | Huidige versie (wijz) | Nieuwere versie → (wijz)
Ga naar: navigatie, zoeken

RIPS

Options

The scan was done at level 2, which includes user-tainted and file/DB tainted, using the subdirectories option. Level 1 seemed inadequate for our purposes since it only includes user-tainted options, and we're meant to check all output. It used the latest version of FluxBB.

Code Scanning Results

RIPS warns you the scan might take very long if that option is used, and the estimated time it gives while scanning the code is pretty long, but for the FluxBB code it ended in less than 3 minutes. Even if the subdirectories are not included, RIPS will go by PHP includes and check most of the code, so this option may be used to save some time. In total, 277 vulnerabilities were found using RIPS. The full output can be found here.

Conclusions

There were 277 total vulnerabilities found in the code with RIPS, but only two of them are related to SQL. Since our group's subject is Output Encoding/Escaping (SQL), these may be helpful for us. The largest amount of vulnerabilities were XSS vulnerabilities (223 of them).

RATS

Options

RATS does not offer a GUI, but it is not so hard to use it from the command line. It provides various useful commandline options, like only outputing where a special function given as parameter is used, or set a warning level. Depending on the warning level, which can be set to low, medium or high, RATS gives various alerts:

Code Scanning Results

Warning Level Amount Cause
high 1 A maybe untrusted source in fopen()
medium 2 high level + a potential TOCTOU (Time of Check, time of Read)
low 8 medium level + various potential race conditions

The whole output of RATS get be found here

Conclusions

Concerning our part of the analysis, Output Encoding/Escaping (SQL), we have to conclude that the tool did not provide any useful output. The reason therefore is that the tool is not able to detect vulnerabilities regarding SQL (like SQL-Injection). This is because RATS is not actively developed anymore, the last version is from 2002. Back there, SQL-Injection where not well known yet and therefore probably not considered by the programmers.

PHPLint

Options

PHPLint does not offer a GUI unlike RIPS, only command line is available. In terms of options, the tool focuses more in the behavior of the output instead of the depth of the scanning; only one level of scanning is available. Among the output options, one can specify which type of alerts should be displayed, for example, warnings, notices and errors. The programmer can also specify between displaying the alert along with the source code or only the line of code and its corresponding alert.

Scanning Results

Due to the fact that this tool can analyze one page at a time, for our particular interest of SQL Output/Encoding, we randomly chose a PHP file that contains SQL statements; login.php was a good candidate. For this file, PHPLint returned three types of alerts: warning, error and fatal error totaling 131 alerts. The percentages and main type of alerts are displayed in the table below and the complete scan result can be found here.

Alert Type Amount  % Cause
Warning 91 69.4 comparing variables of different type; using uninitialized variables or undeclared functions.
Error 40 30.5 invalid type variable pass as argument; initializing variable with certain type and returning a different type; pass too many arguments to function
Fatal Error 1 0.007 usage of valid old-style syntax in bult-in functions, e.g. if/while conditional, for loop, etc.

The page register.php was also scanned to verify if similar results were obtained. In this case, PHPLint returned 121 alerts, thus it is valid to assume that the rest of pages will return more less the same amount of alerts, if scanned.

Conclusions

None of the alerts output by this tool were related to SQL encoding/decoding. PHP syntax, variable types and initialization is the main focus of this tool, making it not useful for our task. Moreover, the amount of output returned can be confusing; for us it was better to save the output in a file for later inspection, rather than displaying it in the terminal because sometimes the window size was not big enough or contained too much data, which did not allowed us to perform a good evaluation. Even though, this tool can be overwhelming at times, one cannot deny that is very thorough, which can be good when trying to implement programming best practices, especially when many people participate in a project.

Yasca

Options

Yasca is a general purpose tool which can be extended with third party tools, like for example PHPLint which is described below. But it can be run on its own too. Because we already tried out PHPlint separately, we report here on Yasca itself and the extension Pixy only.

Scanning Results

Without any extensions, Yasca detected some Cross-Site Scripting vulnerabilities, some statements not conforming to the W3 standard and some suggestions for better performance. See the full report here.

With the extension Pixy, it detected more than 1500 XSS but no SQL Injection vulnerabilities. The whole report: here.

Conclusions

Concerning our part of the analysis, Output Encoding/Escaping (SQL), we have to conclude that the tool did not provide any useful output.

Code Secure

Options

The installation process of CodeSecure was carried out with no errors/interruption. Repository: [1]. When fully installed, the tool is deployed on the localhost of our system (OS tested: Windows 7). The CodeSecure software package supports the following features to perform static code analysis: compiler independence (analysis is independent of build enviroment), verification techniques and tainted data flow analysis. Source:[2].

The CodeSecure software analysis tool is a commercial tool available to us under the free, educational community license acquired by Radboud University. Severe limitations are imposed because of this license: the limit to the code that can be analyzed is set to 10000 lines of code, thus not letting us parse the whole fluxbb-1.4.8 project all at once. We adapted our methodology to breaking the fluxbb source code into several parts and examining the parts independently. Still, CodeSecure relies on data flow analysis, which can be crippled if the source code is not examined as a whole (to fully resolve all dependencies and all possible datapaths). This is reflected on the unresolved dependencies which are reported in all analysis results that CodeSecure outputs.

The tool was used to analyze several parts of the code under strict and loose scan settings: Strict scans searched for all possible vulnerabilities, all source types, 10 vulnerable tracebacks and propagating unresolved functions while loose scans were configured less strict and more default scan settings (all vulnerabilities, default source types, 1 vulnerable traceback, non propagating unresolved functions).

Scanning results

  • Part 1 of source code(alphabetically from rootfolder/admin_bans.php until rootfolder/header.php). Results: 13 vulnerabilities, 10 high severity, 3 low severity. Report in XML (the only available report format for the community license) is here: [3].
Part 1
Vulnerability Type Amount  %
Cross-Site Scripting 7 53.85
Reflection Injection 2 15.38
File Inclusion 1 7.69
Obsolete Functions 1 7.69
Information Leak of System Data 1 7.69
Insecure Randomness 1 7.69
  • Part 2 of source code (help.php until viewtopic.php and rootfolder/lang/English admin_bans.php until userlist.php). Results: 5 vulnerabilities, 4 high severity, 1 low severity. Report in XML (the only available report format for the community license) is here:[https://rapidshare.com/files/1920149766/14_3.xml].
Part 2
Vulnerability Type Amount  %
Cross-Site Scripting 4 80
Risky Cryptographic Algorithm 1 20
  • Part 3 of source code (root/include/dblayer/* and root/include/* files mysqli, innodb, email, cache, common, pgsql, sqlite, common_admin): No vulnerabilities found.
  • Part 4 of source code ( root/include/utf8/* folder .php files): No vulnerabilities found.

Conclusions

There were no vulnerabilities found by this tool that related to SQL injection. Thus, we conclude that it was not very useful for our purposes.