Cadet 3rd Class
Cadet 3rd Class
4419 views

Configure Fortify SCA to trust Internal utility libraries.

We are a .Net shop recently re-started using Fortify Static Code Analyzer 17.10.0156.

We are in the middle of a project to bring a large set of programs (100+) originally developed over several decades by many different developers to current framework versions, and standardizing the common aspects of each of them (configuration/data access/logging).

We have a collection of utility libraries that implement much of this common functionality.

The utility library projects themselves are scanned through Fortify with each change and we resolve all issues raised.

For the applications consuming these utility libraries, Fortify flags every value returned as untrusted resulting in a flood of false positives. When the source code for these functions is copied locally into the application projects Fortify does not complain. 

Both of these are minimum examples to demonstrate the problem. They both produce SQL Injection issues with scant evidence reported (evidence only lists the lines the OracleCommand is instantiated.) In the first example ReadEmbeddedSql is a library method, and in the second OurConfiguration.Current["sqlToExecute"] is. (we don't actually put sql in configuration, this is just an example to show anything coming out of our libraries is equally distrusted.)

 

    public void TestMethod1()
        {
            using (var connection = new OracleConnection())
            {
                var sql = ReadEmbeddedSql("someSql");
                using (var command = new OracleCommand(sql, connection))
                {
                    command.ExecuteNonQuery();
                }
            }
        }

 

        public void TestMethod8(string s)
        {
            using (var connection = new OracleConnection())
            {
                var sql = OurConfiguration.Current["sqlToExecute"];
using (var command = new OracleCommand(sql, connection)) { command.ExecuteNonQuery(); } } }

Analysis Evidence: (for first example, second example the only difference is the line number.)

 

TestDao.cs: 27 - OracleCommand()

Rule ID: 31D4607A-A3FF-447C-908A-CA2BBE4CE4B7
OracleCommand()

Details

 

Abstract:

On line 27 of TestDao.cs, the method TestMethod1() invokes a SQL query built using input coming from an untrusted source. This call could allow an attacker to modify the statement's meaning or to execute arbitrary SQL commands.

Explanation:

SQL injection errors occur when:

1. Data enters a program from an untrusted source.

In this case Fortify Static Code Analyzer could not determine if the string is always safe.

2. The data is used to dynamically construct a SQL query.

In this case the data is passed to OracleCommand() in TestDao.cs at line 27.

I attempted to create DataflowCleanseRules for these library methods as suggested in this similar question from a few years ago, I have verified that the custom rules are imported match with the methods being called, I've been able to create targetted CleanseRules for other methods that successfully remove specific taint flags, but this general untrusted state is impervious to my efforts.

Latest attempt at a cleanse rule:

 

            <DataflowCleanseRule formatVersion="17.10" language="dotnet">
                <RuleID>243E945A-34B4-48CC-A8BF-C5BF8576129B</RuleID>
                <FunctionIdentifier>
                    <NamespaceName>
                        <Pattern>Our.Utilities.Database</Pattern>
                    </NamespaceName>
                    <ClassName>
                        <Pattern>BaseDao</Pattern>
                    </ClassName>
                    <FunctionName>
                        <Pattern>ReadEmbeddedSql</Pattern>
                    </FunctionName>
                    <ApplyTo implements="true" overrides="true" extends="true"/>
                </FunctionIdentifier>
                <OutArguments>return</OutArguments>
            </DataflowCleanseRule>

 

I don't want to filter out the sink rules that check for this general untrusted state. Not every issue from this rule has been a false positive, but the amount of noise generated (128 issues in one project, with as much as one third to half showing up again with any given rescan.) has been greatly impairing.

TLDR; Is there a way to configure Fortify to trust these libraries that actually works? 

 

Labels (1)
0 Likes
3 Replies
Micro Focus Expert
Micro Focus Expert

I believe what you are seeking is called the Custom Rules for SCA/SSC.  Besides various other uses, one primary purpose for Custom Rules is to identify sanitizing functions to the SCA Analyzers.  In this way, they will suppress any Issues found when the data flow(s) passed through those identified sanitizing functions.

Review the SCA User Guide and the Custom Rules Guide.


-- Habeas Data
Micro Focus Fortify Customers-Only Forums – https://community.softwaregrp.com/t5/Fortify/ct-p/fortify
0 Likes
Cadet 3rd Class
Cadet 3rd Class

Thanks for the suggestion Hans, but as indicated in the question I've attempted to create custom cleanse rules, and have been successful for some specific types of taint. The xml definition for one of them is posted in the question. and I've been successful for some specific types of taint, but
0 Likes
Cadet 3rd Class
Cadet 3rd Class

oops, surprise comment submission... let me try again. Thanks for the suggestion Hans, but as indicated in the question I've attempted to create custom cleanse rules, and have been successful at removing some specific types of taint. This 'untrusted' status however remains for anything that is returned from my libraries, even when passed through generic cleanse rules. The xml definition for one of my attempts is posted in the question. Can you offer any more specific suggestion that might work?
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.