This documentation is no longer maintained and may contain obsolete information. You should instead refer to Application - Security Dataflow.
On this page:
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:
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:
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:
|See User Input Security - how does it work for more information about the internal mechanisms used by this feature.|
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:
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.
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.
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.
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.
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:
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:
|Note that only external methods written in English are supported by this automatic process.|
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.