界: Code Quality

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

93 个项目已找到

弱点

Solidity Bad Practices: Lack of Explicit Variable Visibility

Solidity

Abstract

状态变量未显式指定可见性级别。

Explanation

在开发 Solidity 智能合约时，开发人员必须设置状态变量的可见性，以控制谁可以获取或设置这些变量。

显式设置状态变量的可见性可以更轻松地捕获有关谁可以访问该变量的错误假设。

示例 1：以下代码无法显式设置变量的可见性级别。


bytes16 data = "data";

References

[1] Enterprise Ethereum Alliance Code Linting

[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2

[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5

[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3

[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal

[6] Standards Mapping - Common Weakness Enumeration CWE ID 710

[7] Standards Mapping - Smart Contract Weakness Classification SWC-108

desc.structural.solidity.swc108

Solidity Bad Practices: Missing Constructor

Solidity

Abstract

合约未声明构造函数。

Explanation

当使用版本 0.5.0 之前的 Solidity 编译器版本时，开发人员可以通过创建与包含合约同名的函数来定义构造函数。一般来说，构造函数为敏感功能所保留，并且仅在创建合约时运行。如果构造函数存在拼写错误，导致名称与合约名称不匹配，那么将会暴露构造函数中的敏感功能。

示例 1：以下代码使用的是 0.5.0 以前的 Solidity 编译器版本，它尝试声明一个名称与合约名称不完全匹配的构造函数。在此示例中，合约名称和构造函数名称的大小写不匹配（Missing 和 missing）。


pragma solidity 0.4.20;

contract Missing {
    address private owner;
    function missing() public {
        owner = msg.sender;
    }
}

References

[1] Enterprise Ethereum Alliance Declare Explicit Constructors

[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2

[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2

[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3

[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal

[6] Standards Mapping - Common Weakness Enumeration CWE ID 665

[7] Standards Mapping - Smart Contract Weakness Classification SWC-118

desc.structural.solidity.swc118

Solidity Misconfiguration: Compiler With Known Vulnerabilities

Solidity

Abstract

该合约使用过时的 Solidity 编译器版本，可能会使其暴露于公开披露的错误和漏洞。

Explanation

创建 Solidity 智能合约时，开发人员可以指定要使用的编译器版本，以明确指定已经过测试的版本，并防止使用不同版本的编译器出现的任何问题。然而多年来，许多与编译器相关的漏洞已被公开披露，并且已经创建了更新的编译器修补版本来解决这些问题。

References

[1] Enterprise Ethereum Alliance Compiler Bugs

[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5

[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5

[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3

[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal

[6] Standards Mapping - Smart Contract Weakness Classification SWC-102

desc.structural.solidity.swc102

Solidity Misconfiguration: Floating Pragma

Solidity

Abstract

合约使用浮动 pragma 并且未将 Solidity 编译器锁定到特定版本。

Explanation

开发人员可以指定一系列兼容 Solidity 编译器版本以在创建智能合约时使用。因为合约通常仅在一种可能的版本中进行开发和测试，所以不建议这样做。这使得有可能使用具有已知安全漏洞的过时编译器版本对它进行编译。

示例 1：以下代码行设置了 pragma，以便智能合约不会在 0.4.5 之前的版本中进行编译，并且在版本 0.5.0 及更高版本的编译器上也行不通。


pragma solidity ^0.4.5;

References

[1] Enterprise Ethereum Alliance Source code, pragma, and compilers

[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5

[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5

[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3

[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal

[6] Standards Mapping - Common Weakness Enumeration CWE ID 664

[7] Standards Mapping - Smart Contract Weakness Classification SWC-103

desc.structural.solidity.swc103

Type Mismatch: Integer to Character

C/C++

Abstract

函数将返回转换为 int 的 unsigned char，但返回值将赋给 char 类型。

Explanation

当转换为整数的不带符号的字符赋给带符号的字符时，可能无法从 EOF 区别其值。

示例 1：以下代码会读取一个字符，并将其与 EOF 进行比较。


char c;

while ( (c = getchar()) != '\n' && c != EOF ) {
  ...
}

在这种情况下，来自 getchar() 的返回值将转换为 char 并与 EOF（一个 int）进行比较。假设 c 是一个带符号的 8 位值，EOF 是一个带符号的 32 位值，那么如果 getchar() 返回由 0xFF 表示的字符，则与 EOF 相比，c 的值将是 0xFFFFFFFF 的符号扩展。由于 EOF 通常定义为 -1 (0xFFFFFFFF)，因此该循环将错误地终止。

References

[1] Distinguish between characters read from a file and EOF or WEOF CERT

[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1

[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4

[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 192

[7] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 10.3

[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 5-0-3

[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6

[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6

[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6

[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6

[13] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4

[14] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection

[15] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection

[16] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection

[17] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3550 CAT I

[18] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3550 CAT I

[19] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3550 CAT I

[20] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3550 CAT I

[21] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3550 CAT I

[22] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3550 CAT I

[23] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3550 CAT I

desc.structural.cpp.type_mismatch_integer_to_character

Type Mismatch: Negative to Unsigned

C/C++

Abstract

该函数声明为返回无符号值，但在某些情况下它会尝试返回负值。

Explanation

依赖在带符号和不带符号的数字之间进行隐式转换是很危险的，因为转换的结果可能是一个超出预料的值，并且会违反程序员在程序中所作的其他假设。

示例 1：在此示例中，变量 amount 在返回时可能包含负值。由于函数已声明为返回不带符号的整数，因此 amount 将隐式转换为无符号的值。


unsigned int readdata () {
	int amount = 0;
    ...
	if (result == ERROR)
		amount = -1;
	...
	return amount;
}

如果满足Example 1 中的错误条件，则 readdata() 的返回值在使用 32 位整型的系统上将为 4,294,967,295。

在带符号和不带符号的值之间进行转换会引发各种错误，但从安全性角度来说，最常见的是引发 integer overflow 和 buffer overflow 漏洞。

References

[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1

[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4

[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 195

[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002824

[7] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 10.3

[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 5-0-3

[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-16 Memory Protection (P1)

[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-16 Memory Protection

[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6

[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6

[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6

[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6

[15] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4

[16] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection

[17] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection

[18] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection

[19] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3550 CAT I

[20] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3550 CAT I

[21] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3550 CAT I

[22] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3550 CAT I

[23] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3550 CAT I

[24] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3550 CAT I

[25] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3550 CAT I

[26] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002590 CAT I

[27] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002590 CAT I

[28] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002590 CAT I

[29] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002590 CAT I

[30] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002590 CAT I

[31] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002590 CAT I

[32] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002590 CAT I

[33] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002590 CAT I

[34] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002590 CAT I

[35] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002590 CAT I

[36] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002590 CAT I

[37] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002590 CAT I

[38] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002590 CAT I

[39] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002590 CAT I

desc.structural.cpp.type_mismatch_negative_to_unsigned

Type Mismatch: Signed to Unsigned

C/C++

Abstract

为无符号变量分配了一个有符号的数字。

Explanation

依赖在带符号和不带符号的数字之间进行隐式转换是很危险的，因为转换的结果可能是一个超出预料的值，并且会违反程序员在程序中所作的其他假设。

示例 1：在此示例中，根据 accecssmainframe() 的返回值，变量 amount 在返回时可能包含负值。由于函数已声明为返回不带符号的值，因此 amount 将隐式强制转换为无符号的数字。


unsigned int readdata () {
	int amount = 0;
    ...
    amount = accessmainframe();
    ...
	return amount;
}

如果 accessmainframe() 的返回值为 -1，则 readdata() 的返回值在一个 32 位整型系统上将为 4,294,967,295。

在带符号和不带符号的值之间进行转换会引发各种错误，但从安全性角度来说，最常见的是引发 integer overflow 和 buffer overflow 漏洞。