SoftwareSecurity2012/Group 7/Code Scanning Reflection

Uit Werkplaats
Ga naar: navigatie, zoeken

(You mention that the tools are not so useful for the Access Control verification requirements. Note that it is hard to think of could tool support that could help here, as access control is really specific to a particular web application. )

RIPS

RIPS tool was quite easy to install and did not require much time. A web-server package like LAMP (under linux environment) was required for it to run and thereafter it was quite easy to operate. We tried to analyze Fluxbb using RIPS and we could quickly see the results. It has a nice user interface with various options to select specific vulnerability types, for instance server side vulnerabilities (e.g. code execution, file inclusion, etc.) and client side vulnerabilities ( e.g. Cross site scripting or HTTP response splitting). RIPS also has the option of controlling the verbosity level (untainted, user tainted, etc.) and it is indeed useful in order to regulate the amount of information that one wants to get from the scan. We observed that RIPS produced a staggering amount of output, a total of 4246 warnings (without opt to subdirs) with cross site scripting being the most popular vulnerability detected in the entire code scanning results. As we understand from OWASP application security verification standard 2009, the source code scanning (static analysis) is level 1B and we need to verify only one requirement at this level for our security requirement. This is V4.1, which states - "Verify that users can only access protected functions for which they possess specific authorization". Therefore, from our results, we have 26 SQL injection warnings on the source codes which it is indeed related to access control vulnerability (perhaps some of the Cross site scripting vulnerabilities and file inclusion vulnerabilities too).

As we began to play with the tool, we realized that the interface of RIPS is quite understandable and it has neat categorization of its results. It also informs us which line of the specific code to look into for a particular warning and which files are affected with any specific vulnerability. In addition to this, it has a window option for scanned files and includes an option where we can choose list or graph tree to model the application and its vulnerabilities. We found it a really interesting option as this gave a clear perspective about the exact presence of the different vulnerabilities in the code.

Having said all that, we have realized during the course of this project that automatic code scanning (level 1B) for access control in this particular project was not very fruitful. The data produced by any of the tools (including RIPS) was not very helpful for us in analyzing the access control checks of the FluxBB application.

RATS

RATS performs only a rough analysis of source code (as is suggested by its name, Rough Auditing Tool for Security). It is not able to find every error in the code and may also find things that are not errors (false positive and false negatives) so that the manual scanning of the code is still necessary. It can be explained to be an aid to manual code scanning. RATS also provides potential trouble spots, the brief description of the problem and the explanation how can we fix it. In addition, when we install RATS as a plugin for Yasca, it gives the severity level of each problem to help us to see the priority of the problem. In our overall experience, we did not find the data produced by RATS to be that useful for our analysis.

PHPLint

PHPLint as Yasca plugin

PHPLint is a code scanning tool which basically performs syntax checks on the given PHP code. It does not look at security vulnerabilities as such and it fails to translate the errors/warnings into possible security vulnerabilities. This makes the data obtained from this tool useless for our purpose.

PHPLint as standalone tool

As mentioned earlier, PHPLint is a good tool for getting more in-depth knowledge about a specific piece of code and not about the security vulnerabilities of the FluxBB source code. RIPS or Yasca are more suited for a better overview of the possible security vulnerabilities. PHPLint mainl lists the bugs which it finds in its code and it can be useful for code analysis in general but its data is quite pointless for identifying security vulnerabilities and especially those related to access control.

It gives errors and warnings on where code can be improved, but not to what purposes it can be exploited. RIPS does this with scanning code and labeling different errors/warning with e.g. XSS vulnerabilities or SQL injection possibilities and hence RIPS is more useful in identifying security vulnerabilities as compared to PHPLint.

Yasca

Having basic knowledge in command line functions installing yasca-core 2.2 is relativity simple in the platform Windows 7 and Linux.Yasca tool is easy to integrate with plug-ins(Except for pHpLint),which gives boost to yasca to analyze the source code/project.It also handles java,pHp,c++ source codes to analyze.It produces a simple report in HTML format clearly giving the severity level classification.Of course it helps out with the warnings,but is not very useful for real security analysis at higher level.

Scanning the project fluxbb 1.5 only with Yasca standalone with out any plugins,gives out very fast results.Considering for the access control requirements it was not useful.admin_permissions/options/maintaince/groups:php:6,the tool produces informational(46 warnings) as possible license restrictions.As a result admin_users.php:807 report to be high severity as a bug,which is quite useful.As an overview CSS warnings(14) produces by yasca is useful to look.

Overall impression of the tool is easy to install,use and quickly get a view of the project vulnerabilities.The report generated is easy to go through.