SoftwareSecurity2012/Group 2/Evaluation

Evaluation

FluxBB Documentation

Documentation could have been a usefull. The plugin did not come with any documentation at all. An API would have been nice to find every function and their use. Also coding rules should have been documented because the coding style was very incoherent.

Reflection on the review process

For verification, the ASV standard is used. This standard defines several area's for security requiremens, each area contains a number of requirements, and these requirements apply to one or multiple levels of verification. The requiremens are sometimes defined in a very specific manner - even naming language specific properties - while other requirements are very generic. The requirement 6.5 defines very specifically how to handle XML. Not all websites use XML, and website might also use techniques that are not named in these requirements. OWASP should maybe have made a decision to define the requirements on a very high level, naming only generic risks like input validation, handeling of escapes of commands, and not naming any language specific properties. If language specific properties are really important to define in a standard, they could have chosen to apply the generic requirements to a specific language and define specific requirements for this language in addition to these generic requirements. (Erik:I see your point. Still, given that certain languages are so commonly used in web app - SQL, XML, LDAP, etc - I think it does make sense that V6.* explicitly mention these. Note that V6.8 does mention `any interpreters not specifically listed above'. )

Reflection on code scanners RIPS and Yasca

In this section the code scanning results of the tools Yasca and RIPS are analysed. In the analysis is reflected on the installation procedure and the usability and speed of the tools.

Installation

RIPS

The installation requires a web-server to be installed on your system, which makes this tool a less attractive choice to use for code scanning.

Yasca

Yasca does not have an installation procedure. Yasca should be downloaded and extracted, afterwards it is directly functional.

Usability and Speed

RIPS

A scan of our size ( 1127kb in 98 php files) can take up to 15 minutes, there is no progress bar visible.

Yasca

Yasca provides warnings about security vulnerabilities, code-quality, performance, and conformance, as the developers claim on their website. However, we are only interested in the security issues. So a fair bit of the warnings generated by Yasca is not relevant from our point of view. The only warnings in which we are interested fall into the category "Cross-Site Scripting", which is about 15% of the warnings the tool provides. The relevant security warnings it provides about security issues like Cross-Site Scripting are however very useful.

Yasca works from the command line. To analyze source code, the directory including the code is passed to Yasca as a parameter. Yasca lists its results in a table in a html file. It stores this html-file in Windows' default desktop directory (which might not be the actual desktop library).

There are no clear verbosity levels for a scan with Yasca, there are however additional plugins which can enable for features.

A scan of our size (1127kb in 98 php files) takes less than a second to complete.

Summary

Both of these tools point to risky places in the code, however they do not point to any of the relevant code related to the Custom BBCode modification.

Yasca gives only 14 possible vulnerabilities related to what we are looking at, these are all echo's from dictionary-variables which only differ on the selected language or configuration.

RIPS gives too many possible vulnerabilities and it is really hard to filter something specific, which makes the user wonder if any of these possible vulnerabilities is worth looking at.