Code Quality VS. Exploitable Vulnerabilities
There are many different perceptions of a “vulnerability” in the various tools available. What we at RIPS Technologies rank as a minor code quality issue, often is reported as a high-severe vulnerability by other vendors. The reason for this are different perspectives, the analysis capabilities, and the internal equation of bug categories. A tool that solely focuses on the detection of code quality issues by using fingerprints will classify any security-related finding as critical - although from a security expert’s perspective this finding may be only of informational value at most.
Here is a classical example.
But line 3 does not pose any real vulnerability that can be exploited by an attacker to cause harm. A real vulnerability would only exist if user input such as a
$_GET parameter is passed to
eval() so that an attacker can modify the executed PHP code. In our code example, static PHP code is evaluated instead which makes it bad quality code - but not vulnerable code.
In order to detect this fundamental difference, RIPS performs complex taint analysis which traces any data flow from user input into dangerous PHP functions, such as
eval(), across your PHP application’s code using a graph model. This allows RIPS to report code paths that pose real and exploitable security vulnerabilities (see real-world examples).
Clearly, this is a significantly different technology. Using only simple fingerprints to detect cross-site scripting vulnerabilities, for example, would lead to a warning for every single
echo call in your code and let you drown in thousands of false positives, even when your code is secure.
Security-relevant Code Quality
Since calls to
eval() are bad and rather rare, we agree that it is worth to inspect these - either for possible security implications or for the improvement of code quality. Hence, additionally to our in-depth taint analysis for remote code execution and other real vulnerabilities, RIPS now also reports the usage of dangerous PHP functions - but within a new category code quality and with a severity of low.
In total RIPS reports over 30 types of code quality issues that can have security implications. More examples include Hard-coded Passwords (CWE 259), Leftover Debug Code (CWE 489), Decision by IP (CWE 291), or Missing Error Handling (CWE 390).
The new classification between exploitable vulnerabilities and code quality issues further enables clearance of low-severe issue types already available in RIPS, for example a Cookie Misconfiguration (CWE 494) or the usage of a Weak Hash Function (CWE 327): these are now categorized as code quality issues rather than as security vulnerabilities.
With our new default analysis profiles you decide which issue types are permanently activated or deactivated for your scans. Before each scan, you can also choose if you would like to scan only for real security vulnerabilities, or also for code quality issues.
More traditional code quality issues, such as “Class name is too long” or “Too many function arguments”, are easy to detect but not reported by RIPS and are not considered helpful in the context of a security analysis solution. There are already plenty of great open source tools that can help to address pure code quality or typing issues that we can recommend:
RIPS’ focus remains on complex security bugs.
Advanced Code Quality Analysis
But RIPS’ unique security analysis capabilities allow to refine certain code quality analysis. For example, another code quality violation that RIPS now reports is the use of a Dynamic SQL Query. Whenever SQL code is dynamically concatenated it poses the risk that an attacker can inject malicious SQL syntax (SQL Injection). So far, RIPS only reported a SQL injection vulnerability if user input without sufficient sanitization is detected during data flow analysis. Contrarily, reporting every single dynamic SQL query as a code quality issue leads to thousands of reports for legacy PHP applications that do not use prepared statements.
As a solution, RIPS uses its unique context-sensitive taint analysis to distinguish between different dynamic SQL queries. The following code sample contains three dynamic SQL queries but no evident SQL injection vulnerability. RIPS only reports one dynamic SQL query in line 5 to indicate that the function
getById() poses a security risk when used with user input. No warning is reported for line 7 or 10 because these queries are correctly sanitized for their context.
The core value of RIPS is and remains the detection of critical and even complex vulnerabilities without false positive noise that no other solution is able to detect. Next to this in-depth security analysis, RIPS can now also report relevant code quality issues as a separated category. With the help of these new issue types, developers can further harden their PHP code against attackers and enhance the robustness and security of their business.