Kingdom: Code Quality
Poor code quality leads to unpredictable behavior. From a user's perspective that often manifests itself as poor usability. For an attacker it provides an opportunity to stress the system in unexpected ways.
Code Correctness: Erroneous Class Compare
Abstract
Determining an object's type based on its class name can lead to unexpected behavior or allow an attacker to inject a malicious class.
Explanation
Attackers can deliberately duplicate class names in order to cause a program to execute malicious code. For this reason, class names are not good type identifiers and should not be used as the basis for granting trust to a given object.
Example 1: The following code determines whether to trust input from an
Example 1: The following code determines whether to trust input from an
inputReader object based on its class name. If an attacker can supply an implementation of inputReader that executes malicious commands, this code cannot differentiate the benign and malicious versions of the object.
if (inputReader.GetType().FullName == "CompanyX.Transaction.Monetary")
{
processTransaction(inputReader);
}
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 486
desc.dataflow.dotnet.code_correctness_erroneous_class_compare
Abstract
Determining an object's type based on its class name can lead to unexpected behavior or allow an attacker to inject a malicious class.
Explanation
Attackers can deliberately duplicate class names in order to cause a program to execute malicious code. For this reason, class names are not good type identifiers and should not be used as the basis for granting trust to a given object.
Example 1: The following code determines whether to trust input from an
Example 1: The following code determines whether to trust input from an
inputReader object based on its class name. If an attacker can supply an implementation of inputReader that executes malicious commands, this code cannot differentiate the benign and malicious versions of the object.
if (inputReader.getClass().getName().equals("com.example.TrustedClass")) {
input = inputReader.getInput();
...
}
References
[1] OBJ09-J. Compare classes and not class names CERT
[2] Standards Mapping - Common Weakness Enumeration CWE ID 486
desc.dataflow.java.code_correctness_erroneous_class_compare
Abstract
Determining an object's type based on its class name can lead to unexpected behavior or allow an attacker to inject a malicious class.
Explanation
Attackers can deliberately duplicate class names in order to cause a program to execute malicious code. For this reason, class names are not good type identifiers and should not be used as the basis for granting trust to a given object.
Example 1: The following code determines whether to trust input from an
Example 1: The following code determines whether to trust input from an
inputReader object based on its class name. If an attacker can supply an implementation of inputReader that executes malicious commands, this code cannot differentiate the benign and malicious versions of the object.
if (inputReader::class.qualifiedName == "com.example.TrustedClass") {
input = inputReader.getInput()
...
}
References
[1] OBJ09-J. Compare classes and not class names CERT
[2] Standards Mapping - Common Weakness Enumeration CWE ID 486
desc.dataflow.kotlin.code_correctness_erroneous_class_compare