SoftwareSecurity2012/Group 9/Code Scanning

RIPS

Installation

Installation requires more work and a lot of extra software. You can download the program from their website [1], but you'll also need to have an HTTP-server (for example: apache2) with PHP. One easy way is to get XAMPP [2]. Alternatively you can install the components separately.

You must extract the software into your webserver's directory. On SUSE Linux this is /srv/www/htdocs.

You will need to start the webserver and then you can access it in you local browser via http://localhost/*ripsdirectoryname*. RIPS now provides and comfortable and easy-to-use webinterface.

Results

We decided to use the most recent release v0.53. In the webinterface you can easily configure the verbosity level and vulnerability types you would want to search for. After running RIPS on the entire FluxBB-code, we got the following results for different verbosity levels:

Verbosity level	Code Execution	Command Execution	Header Injection	File Disclosure	File Inclusion	File Manipulation	SQL Injection	Cross-Site Scripting	HTTP Response Splitting	Positive Flow Control	Unserialize	Sum
1. user tainted only	0	0	1	0	2	6	2	33	1	0	0	45
2. file/DB tainted +1	1	0	1	6	12	12	2	223	2	0	18	277
3. show secured +1,2	4	0	1	6	12	16	2	364	3	0	19	427
4. untainted +1,2,3	140	1	2	28	327	34	26	2662	73	222	20	3535

Representation of the file structure with level 1 vulnerabilities

RIPS also provides a nice overview page with statistics after scanning or visualizations about the files.

Feedback

RIPS creates nice formatted output. You can choose your favorite syntax highlighting style. It is great, that along with the possible bugs, they often show you, what you actually can do to improve these lines of code.

RIPS warns that it does not support object-oriented code which might decrease the accuracy of the results as fluxbb uses object oriented programming.

Conclusion

However, as we are mainly focused on error handling and logging, we don't need RIPS to consider all vulnerability types, because they are not related to error handling and logging. For other groups though this seems to be a more useful tool.

YASCA

Yasca architecture

Yasca is free open source tool for source code analysis. It can scan code written in Java, C/C++, HTML, JavaScript, ASP, ColdFusion, PHP, COBOL, .NET, and other languages. Yasca has a plugin-based architecture and is logically consisted of a basic front-end, a set of scanning plugins and report renderers and an engine to tie them all together. The tool itself can be easily integrated and extended with plugins such as RATS, PHPLint and others, you can also create your own plugin using Grep (included by default).

In the case of our group, we scanned the PHP/JavaScript files of the forum application FluxBB.

First Impressions

Running and Installation

Yasca doesn't have any kind of installation. After downloading the binary at yasca.org you can run it directly using the command-line.

In Windows:

yasca [code directory]

Ex: yasca c:\path\to\source

In Linux:

./yasca [code directory]

Ex: ./yasca path/to/source

Yasca will then generate a file with the code scan results. The default output format is HTML, however, Yasca can also generate output in XML and CSV format. There's a manual for Yasca with a list of commands available in http://www.scovetta.com/yasca/yasca-manual.pdf.

Feedback

Screenshot of a html file generated by Yasca

The file generated presents all the vulnerabilities found in the source code. To each vulnerability addressed in the output file, there are three fields:

- The first field represents the number of the vulnerability and its severity. The severity is represented by the color of present in the field. There are five types of severity: critical, high, warning, low and informational.

- The second field presents the file and line in which the vulnerability was found as well as a small description about it.

- The third field presents the piece of code (or part of it) in which the vulnerability as fonud.

The five levels of vulnerabilities in Yasca, from the most severe to the least severe.

If the user wishes to, s/he can also see all the scanned files in a list or a basic summary grid, which shows a short table with the file and the vulnerabilities associated to it.

Results

We ran Yasca on the code and we found 104 vulnerabilities. The vulnerabilities are described in the table below:

Type/Severity	Critical	High	Warning	Low	Informational	Total
W3Core	2	2	2	0	4	10
Cross-Site Scripting	14	0	0	0	0	14
Bug: Script tag	0	2	0	0	0	2
Peformance	0	0	0	4	26	30
Licensing restictions	0	0	0	0	46	46
Total	16	4	2	4	78	104

At first glance it seems that the feedback given is not very useful as:

• Most vulnerabilities found were classified as informational (possible licensing restrictions and performance issues).

• Critical severity vulnerabilities found are related to cross-site scripting and to JavaScript commands that are not fully supported in Internet Explorer.

• High severity vulnerability found are related to some small bugs found in the PHP code.

• The rest of the vulnerabilities found are related to peformance issues and licensing restictions.

As far as we could see Yasca did not show any important security issues about SQL-injections, which are important vulnerability type (which could also mean that there is NO vulnerability no SQL-injection, but we can't assure that). As for error handling and logging, we still aren't sure as how a tool can find this type of vulnerability statically.

Conclusion

In the end, it seems that additional plugins are necessary for Yasca to make a deeper and more precise analysis. At least for our requirements the tool was not helpful.