Introduction
In order to detect User Input Security flaws, CAST provides an 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 Security Dataflow feature 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, intermediate results can be viewed in Console, full results (i.e. the security vulnerabilities) can be viewed in the CAST Engineering Dashboard as standard rules. As dataflow-based 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
- .NET
Predefined methods
Some well known Input Methods/Target Methods are already pre-defined and taken into account - see User Input Security - predefined methods for more information.
Enabling/disabling Security Dataflow
By default, Security Dataflow is disabled for all supported technologies. It can be activated for an Application by clicking the slider for the appropriate technology. 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:
Note that:
- CAST highly recommends using AIP Core ≥ 8.3.10 on your Nodes when Security Dataflow results are required.
- disabling or enabling Security Dataflow between successive snapshots may impact results: more or less violations may be returned.
- See User Input Security - how it works for more information about the internal mechanisms used by this feature.
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.
Viewing results
Intermediate results
When Security Dataflow options are enabled and a snapshot has been generated, intermediate results can be viewed in the Console at Application level. This gives a basic overview of results:
Click to enlarge
Analysis Findings
This table displays the number of User Input Targets and User Input Sources identified in the analysis, the number of Detected Flaws and the number of Blackboxes used:
| Targets | Number of calls to methods accessing resources considered for the rule |
|---|---|
| Sources | Number of calls to methods where variables are populated with user input |
| Detected Flaws | The number of flows from methods with user input down to methods accessing resources without prior sanitization |
| Black-boxes | The number of black-box files that have been loaded for the rule |
Analysis Status
A brief over overview of the success/failure of the Security Dataflow analysis, together with a comment to help debug in case of a failure.
Blackbox
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 Security Dataflow 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 Security Dataflow feature will automatically generate blackboxes on the fly during the process for methods with following characteristics:
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.). Based on the method signature and a statistical model, the on the fly feature will then decide on method behavior:
Note that only external methods written in English are supported by this automatic process. |
|---|---|
| Manual Blackboxing | If the Automatic Blackboxing feature (described above) 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. When the blackbox has been created, it can be added in to the analysis configuration in this panel. In the example below, one blackbox file (must have the .blackbox.xml file extension) has been added in. Once the blackbox has been created, and a new snapshot should be generated to ensure the manual blackbox is taken into account.
Adding blackbox files Click the Add button:
Click the "cloud" upload button in the bottom right corner and select the file from your local hard drive:
Now select the uploaded blackbox file and click Save:
The file will now be displayed in the list of blackbox files:
Removing a blackbox file To remove a blackbox file that you have added, click the trash icon next to the file:
Note that removing a blackbox file that has already been used in an analysis will impact the analysis results. |
Full results
The full results are displayed as rule violations in the CAST Engineering Dashboard and form part of the Security (60016) Health Measure and the Technical Criterion called Secure Coding - Input Validation (66062). In addition, 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 it works for more information.
Analyze Security Dataflow option
When an analysis has been run and Security Dataflow has been enabled for a technology in your Application, a button will be enabled in this panel:
This button enables you to run just the Security Dataflow part of an analysis, instead of having to run the entire analysis. This can save a lot of time if you are only interested in viewing the Security Dataflow results - for example, you may have added a manual blackbox and you would like to check the results before committing to using the blackbox in a full analysis.
Technical information
See the following pages for more technical information about Security Dataflow:
Log messages
Security dataflow fails with "Out of Memory" during Run Extensions at Application level
If your Security Dataflow analysis fails with "Out of Memory" errors, there are only two options available to resolve this:
- Increase the amount of RAM available to the Node and rerun the Security Dataflow analysis, if possible. Security Dataflow is very resource hungry both for JEE and .NET, and when using it with JEE projects (when using the Security for Java extension) CAST recommends a minimum amount of RAM (32GB).
- If you cannot increase the amount of RAM available to your Node, or if the issue persists even after increasing the available RAM allocation, the only remaining option is to:
- Split your existing Analysis Units into multiple smaller Analysis Units.
- Cleanup your existing CASTIL located in the LISA folders on your Node.
- Rerun the Security Dataflow analysis.
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.
