界: 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 在傳回的時候可能為一個負值。由於函數被宣告為傳回一個無符號的 int，因此 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 弱點。