The User Input Security Analyzer uses a Dataflow Engine that works automatically on an intermediate byte code file that is produced by the J2EE Analyzer and the .NET Analyzer. It does not use the CAST Analysis Service and the dependencies stored in it. Everything is done in memory after the source code analysis and using the byte code produced.
The Dataflow Engine uses a tainted variable mechanism to track the user input that has not been sanitized. The engine will track vulnerabilities via tainted data that flows from the user input down to the target methods, as shown in the image below showing an "SQL Injection" scenario:
The Dataflow Engine works automatically on the Java or .NET code. As mentioned above, it does not use any information stored in the CAST Analysis Service. So, for example, if you are making a quick code analysis targeting only User Input Security flaw detection, it is not necessary to configureof dynamic links or the database code analysis itself - you just need to have a correctly configured Java or .NET analysis.
Because the best known user input vulnerability is SQL Injection, users tend to think that the User Input Security feature requires an analysis from end-to-end from the JSP or ASP pages down to the database code, however, this is not the case. The Dataflow Engine only needs to explore the Java or .NET code.
How does it work?
The J2EE Analyzer and the .NET Analyzer produce internal intermediate files that get stored in the CAST Large Intermediate Storage Area (LISA):
- A main file called BuildAgent.bytecode that will be used directly by the Dataflow Engine (it is not human readable)
- A second file called BuildAgent.symbols that can be used for troubleshooting and checking if the input methods or target methods are resolved properly
The path to these files is log in CAST-MS by the analyzer.
The location of the LISA folder can be changed at will via the CAST Management Studio.
The final results of the User Input Security analysis are displayed in the CAST Engineering Dashboard as part of the Security health factor and the technical criteria called User Input Validation. 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.