界: Code Quality

代码质量不佳会导致不可预测的行为。对于用户来说,通常表现为可用性差。对于攻击者来说,提供了以意外方式对系统施加压力的机会。

93 个项目已找到
弱点
Abstract
NaN 进行对比始终是一个错误。
Explanation
如果与 NaN 进行比较,得出的计算结果将始终为 false!= 运算符是个例外,因为 NaN 未经排序,所以始终会得出 true 结果)。

示例 1:以下示例尝试验证变量并非为 NaN


...
if (result == Double.NaN){
//something went wrong
throw new RuntimeException("Something went wrong, NaN found");
}
...


这将尝试验证 result 并非 NaN,但是使用带有 NaN 的运算符 == 将始终得出 false 值,所以此检查将永远不会抛出异常。
References
[1] NUM07-J. Do not attempt comparisons with NaN CERT
[2] Java Language Specification Chapter 4. Types, Values, and Variables Oracle
[3] INJECT-9: Prevent injection of exceptional floating point values Oracle
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[8] Standards Mapping - Common Weakness Enumeration CWE ID 486
desc.structural.java.code_correctness_comparison_with_nan
Abstract
类的构造函数会调用可以被覆盖的函数。
Explanation
如果构造函数调用了可覆盖的函数,则在该对象完全初始化之前,攻击者将可以访问 this 引用,进而导致出现漏洞。

示例 1:以下示例调用了可覆盖的方法。


...
class User {
private String username;
private boolean valid;
public User(String username, String password){
this.username = username;
this.valid = validateUser(username, password);
}
public boolean validateUser(String username, String password){
//validate user is real and can authenticate
...
}
public final boolean isValid(){
return valid;
}
}


由于函数 validateUser 和该类并非 final,这意味着它们是可以被覆盖的,对将覆盖此该函数的子类的变量执行初始化会允许避开 validateUser 功能。例如:


...
class Attacker extends User{
public Attacker(String username, String password){
super(username, password);
}
public boolean validateUser(String username, String password){
return true;
}
}
...
class MainClass{
public static void main(String[] args){
User hacker = new Attacker("Evil", "Hacker");
if (hacker.isValid()){
System.out.println("Attack successful!");
}else{
System.out.println("Attack failed");
}
}
}
Example 1 中的代码会输出“Attack successful!”,因为 Attacker 类会覆盖从超类 User 的构造函数调用的 validateUser() 函数,并且 Java 将首先在子类中查找从该构造函数调用的函数。
References
[1] MET05-J. Ensure that constructors do not call overridable methods CERT
[2] EXTEND-5: Limit the extensibility of classes and methods Oracle
[3] OBJECT-4: Prevent constructors from calling methods that can be overridden Oracle
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
desc.structural.java.code_correctness_constructor_invokes_overridable_function
Abstract
根据对象的类名称确定对象类型会导致意外行为或致使攻击者注入恶意的类。
Explanation
攻击者可以故意复制类名称,使程序执行恶意代码。因此,类名称并非合适的类型标识符,且不应用作向给定对象授予信任的基础。

示例 1:以下代码根据 inputReader 对象的类名称确认是否信任该对象的输入。如果攻击者能够提供一种执行恶意命令的 inputReader 实现方式,则此代码将无法区分该对象是善意的还是恶意的。


if (inputReader.GetType().FullName == "CompanyX.Transaction.Monetary")
{
processTransaction(inputReader);
}
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 486
desc.dataflow.dotnet.code_correctness_erroneous_class_compare
Abstract
根据对象的类名称确定对象类型会导致意外行为或致使攻击者注入恶意的类。
Explanation
攻击者可以故意复制类名称,使程序执行恶意代码。因此,类名称并非合适的类型标识符,且不应用作向给定对象授予信任的基础。

示例 1: 以下代码根据 inputReader 对象的类名称确认是否信任该对象的输入。如果攻击者能够提供一种执行恶意命令的 inputReader 实现方式,则此代码将无法区分该对象是善意的还是恶意的。


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 - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[6] Standards Mapping - Common Weakness Enumeration CWE ID 486
desc.dataflow.java.code_correctness_erroneous_class_compare
Abstract
基于对象的类名称确定对象的类型可能会导致意外行为或允许攻击者注入恶意类。
Explanation
攻击者可以故意复制类名称,使程序执行恶意代码。因此,类名称并非合适的类型标识符,且不应用作向给定对象授予信任的基础。

示例 1: 以下代码根据 inputReader 对象的类名称确认是否信任该对象的输入。如果攻击者能够提供一种执行恶意命令的 inputReader 实现方式,则此代码将无法区分该对象是善意的还是恶意的。


if (inputReader::class.qualifiedName == "com.example.TrustedClass") {
input = inputReader.getInput()
...
}
References
[1] OBJ09-J. Compare classes and not class names CERT
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[6] Standards Mapping - Common Weakness Enumeration CWE ID 486
desc.dataflow.kotlin.code_correctness_erroneous_class_compare
Abstract
字段被错误分配了负值。
Explanation
此字段被标注为 FortifyNonNegative,表示不允许使用负值。
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 20
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3)
[10] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 020
desc.structural.java.erroneous_negative_value_field
Abstract
表达式 x = NULLx != NULL 将始终为 false。
Explanation
在 PL/SQL 中,NULL 的值是不确定的。它不等于任何值,甚至不等于另一个 NULL 值。同样,一个 null 值永远不会等于另一个值。

例 1:以下语句将始终为 false。


checkNull BOOLEAN := x = NULL;
例 2:以下语句将始终为 false。


checkNotNull BOOLEAN := x != NULL;
References
[1] Steven Feuerstein Oracle PL/SQL Best Practices O'Reilly
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[6] Standards Mapping - Common Weakness Enumeration CWE ID 480
desc.structural.sql.code_correctness_erroneous_null_comparison_plsql
Abstract
进行字符串对比时,应采用 equals() 方法,而不是==!= 方法。
Explanation
程序采用 ==!= 来比较两个字符串是否相等,其实质比较的是两个对象,而不是字符串的值。因此,若采用这个方法,两个引用将永远不会相等。

例 1:以下分支语句将永远不会被执行。


if (args[0] == STRING_CONSTANT) {
logger.info("miracle");
}


==!= 标记符被用来比较相同对象中包含的字符串时,它们只会按照预期的那样运行。要出现这种情况,最常用的方法就是将字符串内置,这样一来,就可以将字符串添加到一个由 String 类维护的对象池中。一旦字符串内置,在使用该字符串时,都会采用相同的对象,相等运算符也会按照预期的那样执行。所有字符串文字和带值的字符串常量都会自动内置。其他字符串可以通过调用 String.intern() 来手动内置,并会返回一个规范的当前字符串实例,必要时也会创建一个实例。
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 597
desc.structural.java.code_correctness_erroneous_string_compare
Abstract
变量被错误分配了零值。
Explanation
此字段被标注为 FortifyNonZero,表示不允许使用零值。
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 20
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3)
[10] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 020
desc.structural.java.erroneous_zero_value_field