Introduction

In order to detect User Input Security flaws, CAST provides an optional analysis feature that implements a dataflow algorithm to detect variables that flow from the user down to a critical resource without prior sanitization, allowing hackers to send them data that will harm IT applications (security vulnerabilities).

As mentioned by the Common Weakness Enumeration (CWE), SANS Institute and OWASP, Improper Input Validation is the top group of web programming errors that can lead to security vulnerabilities.

Improper Input Validation is defined by the CWE follows:

"When software fails to validate input properly, an attacker is able to craft the input in a form that is not expected by the rest of the application. This will lead to parts of the system receiving unintended input, which may result in altered control flow, arbitrary control of a resource, or arbitrary code execution."

The User Input Security feature in the CAST Management Studio enables users to detect improper user input validation in the application's source code, which can lead to the following security vulnerabilities:

• SQL Injection (CWE-89)
• Cross-Site Scripting (CWE-79)
• LDAP Injection (CWE-90)
• OS Command Injection (CWE-78)
• XPath Injection (CWE-91)
• Path Manipulation (CWE-99)
• Avoid Log forging vulnerabilities (CWE-117)
• Avoid uncontrolled format string (CWE-134)
• Trust Boundary Violation (CWE-501)
• Sensitive Cookie in HTTPS Session Without 'Secure' Attribute (CWE-614)
• Use of hard-coded credential (java, C#, VB.Net languages) (CWE-798)

Once the source code analysis is complete, the results (i.e. the security vulnerabilities) can be viewed in the CAST Engineering Dashboard as standard Quality Rules. As dataflow-based Quality Rules, the flow of the user input can be tracked in the CAST Engineering Dashboard with bookmarked source code.

CAST currently supports User Input Security checks for the following technologies:

• JEE (using the JEE Analyzer extension)
• .NET (using the .NET Analyzer extension)

Enabling User Input Security checks

To enable User Input Security checks in your application analysis using the CAST Management Studio, it is necessary to activate the feature within the User Input Security tab in the Application editor - choosing the technology you want to target. This is all that is required in order to obtain results at the end of an analysis - this is due to the predefined methods that are supported out of the box and the automatic blackboxing that is used:

Performance impact when User Input Security is enabled

Enabling User Input Security checks will impact analysis performance - i.e. the analysis of a given Application will take longer to complete if you enable User Input Security checks. This is due to the additional checks and metrics that need to be processed during this type of analysis. However, the impact on performance will vary according to various different aspects related to the Applications you are analyzing:

• Number of lines of code (LOC)
• Number of objects after analysis
• Number of violations after analysis

In other words, the impact will be less noticeable on small/simple Applications, whereas the impact will be more significant for larger/complex Applications. See User Input Security - Advanced configuration to improve performance for more information about how you can improve performance. Note that these are advanced configuration options that require in-depth knowledge of the application and of CAST AIP.

Predefined methods

Some well known Input Methods/Target Methods are already pre-defined and taken into account by CAST AIP for the User Security Input feature. See User Input Security - predefined methods for more information.

Viewing results

The final results of the User Input Security analysis are displayed as Quality Rule violations in the Engineering Dashboard and form part of the Security (60016) Health Measure and the Technical Criterion called Secure Coding - Input Validation (66062). However for quick review, the results are also generated in an xml file called BuildAgent.flaw which can be loaded into the FlawExplorer - see User Input Security - Using FlawExplorer to speed up result check and also User Input Security - how does it work for more information.

Log messages

Reached limit while exploring stores instrs caller tree for field

You may see this message in the analysis log when the User Input Security feature is enabled:

Warning MODULMSG ; Job execution  Reached limit while exploring stores instrs caller tree for field XXX

This warning message has no impact on the analysis results: when the source code is explored a file can be be examined a limited number of times. When this warning message appears in the analysis log it shows that this limit has been reached.

Additional features

Blackboxing methods

When analyzing an application, this application has a defined analysis scope - i.e. some code is analyzed, some is not and is treated as external code. Any external code is "unknown" and cannot be accessed by the analyzer, and as such cannot be taken into account in the normal manner by the User Input Security feature. Therefore, security problems in this external source code would normally not be detected at all.

In order to resolve this problem, CAST uses the notion of "blackboxing methods". There are two ways that blackboxing is used:

Automatic Blackboxing

The User Input Security feature will automatically generate blackbox methods on the fly during the analysis process for all methods which do not have a body, i.e. all code that is deemed to be "external" to the application boundary. This includes the majority of assemblies for which no source code can be found (framework assemblies, third-party JARs/assemblies, internal frameworks without source code etc.). A category of implementation is deduced from the method signature (during the analysis) according to a statistical model. Methods are therfore classified into several categories:

• User input method : network read, console input, etc.
• Target method: network write, file open, etc.
• Pass-through method: similar to "collection" blackboxing

Manual Blackboxing

If the Automatic Blackboxing feature does not handle external code in the correct way then the recommended action is to create a black box manually to alter the way the automatic process functions. Once the blackbox has been created, a new snapshot should be generated to ensure the manual blackbox is taken into account.