Avoiding False Null Dereference Error in Fortify

I use “HP Fortify v3.50” in a java project, and I find many false positives on “Null Dereference” because Fortify does not see the control against null in another method. How can I reduce false positives and maintain the rule?

Here is the POC

public class MyClass { public static void main(String[] args) { String string01 = null; String string02 = null; int i; if (args[0].equals("A")) { string01 = "X"; string02 = "Y"; } if (!isNull(string02)){ i = string02.length();} //False Positive else { i = string02.length(); } // Yes, it is an error! } public static boolean isNull(Object toBeTested){ return (null == toBeTested); } } 

Result:

 [E8837DB548E01DB5794FA71F3D5F51C8 : medium : Null Dereference : controlflow ] MyClass.java(13) : Assigned null : string02 MyClass.java(16) : Branch not taken: (!args[0].equals("A")) MyClass.java(20) : Branch taken: (!isNull(string02)) //False Positive MyClass.java(21) : Dereferenced : string02 [E8837DB548E01DB5794FA71F3D5F51C9 : medium : Null Dereference : controlflow ] MyClass.java(13) : Assigned null : string02 MyClass.java(16) : Branch not taken: (!args[0].equals("A")) MyClass.java(20) : Branch not taken: isNull(string02) MyClass.java(23) : Dereferenced : string02 
+5
source share
2 answers

This is more like an SCA problem that you should take to your support team. Alternatively, just check it as an unimportant problem. This is not something that can be fixed with a custom rule.

0
source

Declaring a null pointer or entering an infinite loop can lead to a denial of service attack, but it can also create the conditions necessary for an attacker to use some poorly thought out error handling code.

See https://cwe.mitre.org/data/definitions/476.html and https://www.owasp.org/index.php/Null_Dereference

-4
source

Source: https://habr.com/ru/post/1439845/


All Articles