Page tree
Skip to end of metadata
Go to start of metadata

Bytecode

The User Input Security feature incorporates a "Dataflow Engine" that uses intermediate bytecode (known as "CASTIL") that is produced during the analysis:

JEE technology

There are two bytecode generators:

  • An extension called Security for Java is available - this can be manually included in AIP Console using the Application - Extensions interface or can be automatically installed when delivering source code via the "Security assessmentObjective.
  • The JEE Analyzer also generates intermediate bytecode "out of the box".
CAST highly recommends that the Security for Java extension is used since the bytecode it generates produces much more accurate results for the User Input Security feature.
.NET technologyThe bytecode is generated by the .NET Analyzer.

Dataflow Engine

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:

Click to enlarge

The Dataflow Engine works automatically on the bytecode - it does not use any information stored in the Analysis schema. So, for example, if you are making a quick code analysis targeting only User Input Security flaw detection, it is not necessary to configure (for example) dynamic links or the database code analysis itself - you just need to correctly configure your JEE and .NET analysis, enable the User Input Security feature and then generate a snapshot to trigger the User Input Security feature.

Because the best known user input vulnerability is SQL Injection, it is generally considered that the User Input Security feature requires an end-to-end analysis from the client code down to the database code, however, this is not the case. The Dataflow Engine only needs to explore the JEE or .NET code.

How does it work?

The bytecode is generated when a snapshot is generated and is then stored in the Large Intermediate Storage Area (LISA). The path to the bytecode storage folder is logged in the SecurityAnalyzer.log which logs all User Input Security actions. You can open the SecurityAnalyzer.log file as explained below.

Other related files that may be of interest:

  • BuildAgent.guid - this is generated by the JEE/.NET analyzer (i.e. is not related to anything generated by the Security for Java extension). This contains method GUIDs.
  • BuildAgent.datatransfer that logs any flaws that have been found ready for transfer to the CAST Analysis Service. This is generally used by CAST Support for troubleshooting.
  • BuildAgent.flaws which can be used by the FlawExplorer to browse the User Input Security results without using the CAST Engineering Dashboard.

AIP Console

Open the snapshot log:

Click to enlarge

Then select the SecurityAnalyzer log in the left hand panel:

The location of the bytecode storage folder can be found by searching for "converted" - this will be in the ConvertedCastIL folder in the LISA:

Click to enlarge

See Configure AIP Node storage folder locations - optional for more information about the LISA folder and its location.

CAST Management Studio

By clicking the link in the CAST Management Studio log window under the step Run DataFlow Security:

Click to enlarge

The LISA folder can be opened directly from the CAST Management Studio:

Click to enlarge

The bytecode is stored in the ConvertedCastIL folder in the LISA:

  • No labels