Ways to suppress a finding in Fixinator

Code is complex, so any static application security testing (SAST) tool will find things that may not be an actual security issue. Fixinator has a few different ways we can deal with this problem. For example, let's suppose you have a variable application.maxstories=10 set in Application.cfc, and you use that variable in a different file like this:

<cfquery name="news">
SELECT headline, story 
FROM news
ORDER BY date_published DESC
LIMIT #application.maxstories#
</cfquery>

Assuming that application.maxstories is always defined, this query isn't vulnerable to SQL injection because you can't change the value of application.maxstories unless you can change the application source code.

Quick aside: If the application.maxstories variable is defined conditionally, then it is a different story. The value of the variable in the query could be manipulated via something I call scope injection via url.application.maxstories for example. But that depends on application.maxstores being undefined.

Suppressing a single finding with Fixinator

If you are using Fixinator then we have a few different ways to suppress this finding. We can add a comment as such:

<cfquery name="news">
SELECT headline, story 
FROM news
ORDER BY date_published DESC
<!--- ignore:sqlinjection because application.maxstories is always defined --->
LIMIT #application.maxstories#
</cfquery>

When Fixinator finds an issue, it will check to see if there is a comment with the pattern ignore:scanner-type directly above or on the same line as the issue. You can optionally add a reason to the comment, which I always like to do.

However if this were my code, I would rather just do this:

LIMIT #int(application.maxstories)#

Fixinator understands that wrapping a variable with int() is a safe solution. I prefer that approach over a comment.

Suppressing a type of finding over many files with Fixinator

Fixinator has a setting called ignorePatterns that can be defined in a .fixinator.json file. For the above example, we might use something like this:

{
  "ignorePatterns": {
    "sqlinjection": ["application.maxstories"]
  }
}

That will tell fixinator to ignore any SQL Injection finding where the variable contains application.maxstories, pretty handy way to keep your fixinator report free of any false positives.

Here's another example... let's assume we fixed XSS issues in our app before the encodeForHTML was builtin to CF by creating our own function called xssEncoder. Perhaps our own function originally called ESAPI directly via java, but now is just an alias to encodeForHTML. This abstraction isn't a bad thing, it even allows us to switch to a different encoder in the future if a better one comes along. We can tell Fixinator about it like this:

{
  "ignorePatterns": {
    "sqlinjection": ["application.maxstories"],
    "xss": ["xssEncoder("]
  }
}

Of course you have to be careful about what you ignore, but I think it is an important feature to have. Without a good way to manage false positives you are either giving developers pointless work just to please the scanner, or the reports are full of false positives and end up being ignored. Neither lead to better security.