In a large ASP.NET project there are a large number of false positives that shared sink to a legitimate vulnerability. For example, a string is initialized as a String.Empty and then later set to be a value from the database. The vulnerability is a Cross-Site Scripting: Persistent vulnerability and is legitimate. However it is listed as a shared sink to many other unrelated pieces of code that are never used in this page or related business or data access logic. The only thing remotely linking these to the legitimate vulnerability is that these other pieces of code also have strings that initialize as String.Empty.Even the Diagram shows that these supposedly shared sinks never intersect with the legitimate vulnerability. It seems Fortify SCA treats System.String.Empty as a variable that is an alias and not a value.
Example:
Class MyPage
{
String ReturnValueToUser = String.Empty
....logic to get string value from database, set ReturnValueToUser as that string
}
Class SomeCompletelyUnrelatedClass
{
String InternalStringNeverOutputtedToUser = String.Empty
....some internal logic completely unrelated in a different class
}
It seems SCA is linking these two unrelated classes and incorrectly counting SomeCompletelyUnrelatedClass in the XSS:Persistent findings based solely on it's assumption that String.Empty is a common alias for a variable instead of a value for the true variables.
Has anyone else run up against this? Is it a known issue? I am using v 6.0.38 of the scan engine with all the latest rulepacks.
