Understanding False Positives When using CAT.NET

Andreas Fuchsberger here…

As CAT.NET performs its static analysis, it attempts to approximate the application's data flow which occurs at runtime.  When there is a question to whether the approximation is accurate, the engine errs on the side of caution.  This causes false positives to be generated.  For example, indexing a collection or an array can cause a false positive:

 A[1] = txtInput.Text;
Response.Write(A[2]);  // this would be flagged as XSS 

When CAT.NET encounters data that is assigned to or accessed in a collection or array, it will NOT consider the index location in determining whether a dataflow graph connection should be made.  In the example shown above, the taint from the first assignment is propagated to the entire array.  Any subsequent access of the array is therefore also tainted.

How to manually suppress false positives

If your code generates false positive messages that cannot be mitigated by a change in source code, CAT.NET allows you to suppress these messages in several different ways.  If you would like suppress a false positive by defining a class and method through which the data flow passes, you can specify the method through the Suppressions tab of the Settings dialog.  Generally, you should suppress false positives through the suppressions tab if the chosen method is a filter or the encoding function has not been previously identified in a CAT.NET rule.  

Entering data into the Suppressions tab of the Settings dialog persists an entry in the CAT.NETSuppressions.xml file in the current project directory and will be referenced in subsequent scans.  The same CAT.NETSuppressions.xml file can also be used when you run CAT.NET as a command line tool.

An interactive method to suppress false positive

A second way to suppress a false positive is to right mouse click on a specific message in the Analysis Window you like to suppress and select Suppress from the context menu.  This inserts an entry into the CAT.NETSuppressions.xml file that identifies the dataflow path unique to the message.  Below is an example:

Suppressed messages are not removed from the analysis results.  They are simply filtered from the Analysis Window output.  To begin seeing the suppressed messages again, click the Show Suppressed Issues button.  The messages again appear in the analysis window, formatted as stricken-out text.

The programmatic method to suppress false positives

The third  to suppress false positive messages is to use the SuppressMessageAttribute class.  This attribute class is defined in the Code Analysis libraries that ship with Visual Studio Team Suite.  This attribute works the same as it does for VS Code Analysis as well as FXCop.

In CAT.NET, the attribute can be defined at the assembly (global) level or at the method level.  For the attribute to be used, the CODE_ANALYSIS compiler directive must be defined and the CodeAnalysis library namespace included.  

The ID of the rule to be suppressed should be used as the second parameter in the attribute.  If more than one rule is to be suppressed, then a separate instance of the attribute should be defined.  One advantage of using SuppressMessageAttribute is that no separate XML is needed to manage suppression and it is compatible with FXCop/VS Code Analysis.  Here is an example of how to use the attribute:

 #define CODE_ANALYSIS

using System.Diagnostics.CodeAnalysis;
[assembly: SuppressMessage("", "ACESEC01"]  //  an assembly-level suppression
namespace Project.Common
{
     public class BusObject
     {
        [SuppressMessage("", "ACESEC05")]  // a method-level suppression
         public string ProcessItems()
         {
            string returnValue ="";
            foreach (BusItem it in Items)
            {
                returnValue += it.Name;
            }
            return returnValue;
         }
      }
}