CAST Engineering Dashboard - Quality Rule - Missing Quality Rule - Dataflow security diagnostics

Some violations are missing in dataflow Security Diagnostics.

1. Check if it is expected to not have this diagnostics fired
2. if it is not expected then Check if it is not a known limitation
3. If it is not due to a known limitationAsk for customer input
4. Check for Errors in CAST MS log
5. Reproduce the issue
6. Transmit the issue to the R&D team

Check if it is expected to not have this diagnostics fired

In some cases, it is normal that the security QRs are not fired:

You need to ensure that you checked the input security checkbox in the CAST-MS as this is a mandatory action for the data flow security diags to be activated

Also, you have to ensure that your input methods are the expected ones. For example, for .Net analyzer, Their are 3 default inputs from System.Web library considered for the computation of the input security diags:

• System.Web.HttpRequest.Form

• System.Web.HttpRequest.QueryString

• System.Web.HttpRequest.Cookies

If these inputs are not used in your .NET analysis, the scope will be null  and nothing will be displayed for “Secure Coding - Input Validation” category. You can check whether these inputs are used in your .Net analysis by looking at LISA folder (file BuildAgent.symbols). If you cannot find any reference to this inputs on your BuildAgent.symbols file, it means that they are not use

If it is the case, in order to trigger something, you have to identify user inputs in your application, and to parameter CAST-MS configuration to type the method signatures, according to the .NET Naming convention (see $flat\configuration\dataflowsecurity\dotnet\FlawSpec_DotNet.xml )

Check if it is not a known limitation

• CAST User Input Security Analyzer has some known limitations (up to version 7.0) reported in the official documentation (Cookbooks > CB - 017 - User Input Security > Analysis requirements and troubleshooting)

Requirements

Analysis Units

The User Input Security Analyzer will only work on code that is analyzed within one single Analysis Unit. (This limitation applies for J2EE Analyzer only).

File types

The User Input Security Analyzer does not take into account code located in JSP files.

Dependencies

Make sure the application is analyzed with all necessary libraries selected and make sure you avoid unresolved methods especially in the Input, Target and Sanitization methods.

• Flaw source/sink hidden behind frameworks:

  The default flaw source/sink cannot be detected correctly because it is hidden behind several frameworks such as spring. A workaround consists to add a custom sources/sinks through CAST-MS that are easier to detect. To find a good candidate you need to know the application architecture.

Ask for customer input

• CAST MS log file
• Customer bytecode folder in the LISA folder (XXXX\LISA\$appID\)
• Customer flaw specification xml files if different from the default ones (XXXX\LISA\$appID\Tempflaws.xml)

Two first input files are gathered by Sherlock 3.0. Tempflaws.xml should be asked to the customer.

Check for Errors in CAST MS log 

Look in the CAST MS log for errors during inference engine computation that could explain some missing input for dataflaw detection.

For exemple, consider following log:

...

FlawOutputFile=XXX\LISA\$appID\Scr$srcID\BuildAgent.flaw.fragment
INF: 2013-05-21 04:41:41:  DatatransfertOutputFile=XXX\LISA\$appID\Scr$srcID\\BuildAgent.datatransfer.fragment
INF: 2013-05-21 04:41:41:  InfEngDebugOutputFile=(not set)
INF: 2013-05-21 04:41:41:  JobId=3
INF: 2013-05-21 04:41:41:  info :     Inference Engine Options
INF: 2013-05-21 04:41:41:  info :         Use Inference Engine=Yes
INF: 2013-05-21 04:41:41:  info :         VersionV1=No
INF: 2013-05-21 04:41:41:  info :         LimitSubTarget=50000
INF: 2013-05-21 04:41:41:  info :         LimitString=10000
INF: 2013-05-21 04:41:41:  info :         LimitLocalSubTarget=100000
INF: 2013-05-21 04:41:41:  info :         ACTIVATE_TRACE_INFENG=No
INF: 2013-05-21 04:41:41:  Loading and instrumenting
INF: 2013-05-21 04:41:41:  Loading file=XXX\LISA\$appID\Scr$srcID\BuildAgent.symbols

....

INF: 2013-05-21 04:46:11:  FATAL ERROR: Error in inference engine

Go through the log to find the last error that generated the FATAL ERROR:

INF: 2013-05-21 04:45:00:  Loading file XXX\LISA\$appID\ScrYYYY\BuildAgent.bytecode
INF: 2013-05-21 04:45:00:  Loading bytecode : 0%
INF: 2013-05-21 04:45:00:  Loading bytecode : 1%
INF: 2013-05-21 04:45:00:  Loading bytecode : 2%
INF: 2013-05-21 04:45:00:  Loading bytecode : 3%
INF: 2013-05-21 04:45:00:  Loading bytecode : 4%
INF: 2013-05-21 04:45:00:  Loading bytecode : 5%
INF: 2013-05-21 04:45:00:  Loading bytecode : 6%

INF: 2013-05-21 04:45:04:  Line: 437700: CBuildAgentAdapter::convertRuleID. Symbol=659763 RuleInput=14 => could not find mapping

...

INF: 2013-05-21 04:46:02:  CBuildAgentXmlLoader: Too many errors. Aborting

Reproduce the issue

Use customer to reproduce the issue using the DataflowRunner.exe command line (available in CAST flat).

If we take, the previous example, error occurs when loading file XXX\LISA\$appID\ScrYYYY\BuildAgent.bytecode. Use the following command to reproduce the issue:

C:\XXXX\CAST\7.0.X>DataflowRunner.exe -jobId 99 -flawSpec "FlawSpec_DotNet.xml" -bytecodeFolder " XXX\LISA\$appID\ScrYYYY

 where: 

-jobId can be set to an arbitrary value.

-flawSpec point to the flaw specification xml file provided by the customer (depending if we analyze .net or j2ee, use FlawSpec_DotNet.xml or  FlawSpec_J2EE.xml file)

 -bytecodeFolder point the folder containing the last loaded file (the one causing the error)

Transmit the issue to the R&D team

Transmit to the team in charge of dataflow security with the input to identify the source code syntaxe causing the issue