界: Time and State

分散式運算與時間和狀態相關。也就是說,為了使多個元件進行通訊,必須共用狀態,並且這一切都需要時間。

大多數的程式設計師將他們的工作擬人化。他們想採用一種控制執行緒來執行整個程式,就像他們必須自己完成這項工作一樣。但是,現代的電腦可以非常快速地切換工作,並且在多核心多 CPU 或分散式系統中,兩個事件可能恰好同時發生。瑕疵急於填補程式設計師在程式執行模型與實際情況之間的差距。這些瑕疵與執行緒、處理序、時間和資訊之間的意外互動有關。這些互動透過共用狀態發生:信號、變數、檔案系統,以及基本上任何可以儲存資訊的項目。

19 找到的項目
弱點
Abstract
將不可序列化的物件當作 HttpSessionState 屬性儲存,會破壞應用程式的可靠性。
Explanation
根據預設,ASP.NET 伺服器會儲存 HttpSessionState 物件,以及在記憶體中它參照的屬性和任何物件。此模型會將作用中的階段作業狀態限制為,僅由單一機器的系統記憶體來提供。為了擴充這些限制的容量,要頻繁的配置伺服器以維持階段作業狀態資訊,如此不僅可擴充容量,還可在多台機器上進行複製以增進整體的效能。為了要維持其階段作業狀態,伺服器必須序列化 HttpSessionState 物件,此作業要求所有儲存在伺服器中的物件皆為可序列化的。

為了使階段作業能夠正確的進行序列化,所有應用程式儲存為階段作業屬性的物件必須聲明 [Serializable] 屬性。此外,如果物件要求自訂的序列化方法,它還必須執行 ISerializable 介面。

範例 1:以下的類別把自己新增至階段作業中,但因為它不可序列化,這個階段作業也就不能正確也序列化。


public class DataGlob {
String GlobName;
String GlobValue;

public void AddToSession(HttpSessionState session) {
session["glob"] = this;
}
}
References
[1] Session State Providers Microsoft Corporation
[2] Underpinnings of the Session State Implementation in ASP.NET Microsoft Corporation
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.1
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 579
[8] Standards Mapping - OWASP Top 10 2004 A3 Broken Authentication and Session Management
[9] Standards Mapping - OWASP Top 10 2007 A7 Broken Authentication and Session Management
[10] Standards Mapping - OWASP Top 10 2010 A3 Broken Authentication and Session Management
[11] Standards Mapping - OWASP Top 10 2017 A2 Broken Authentication
[12] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[13] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.3
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.7
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.10
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.10
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.10
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
desc.structural.dotnet.asp_dotnet_bad_practices_non_serializable_object_stored_in_session
Abstract
呼叫 sleep() 的同時還持續鎖定,會降低效能,而且可能造成鎖死。
Explanation
如果多個執行緒嘗試鎖定資源,呼叫 sleep() 的同時還持續鎖定會讓所有其他執行緒等待資源釋放,這會導致效能降低與鎖死。

範例 1:下列程式碼會呼叫 sleep() 並同時持續鎖定。

ReentrantLock rl = new ReentrantLock();
...
rl.lock();
Thread.sleep(500);
...
rl.unlock();
References
[1] LCK09-J. Do not perform operations that can block while holding a lock CERT
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[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 557
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[10] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[12] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II, APSC-DV-002950 CAT II
[33] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[34] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.java.code_correctness_call_to_sleep_in_lock
Abstract
Double-checked locking 是一種不正確且不能達到預期效果的方法。
Explanation
許多聰穎的人花了大量的時間精神,試圖找出如何使用 double-checked locking 來增進效能。但都沒有人成功。

範例 1:乍看之下,它似乎既能避免不必要的同步處理又能保障執行緒的安全。


if (fitz == null) {
synchronized (this) {
if (fitz == null) {
fitz = new Fitzer();
}
}
}
return fitz;


程式設計師希望保證只分配一個 Fitzer() 物件,但是又不希望每次呼叫此程式碼時都進行一次同步化。這就是所謂的 double-checked locking。

不幸的是,這並沒有用,且可分配多個 Fitzer() 物件。請參閱 Double-Checked Locking is Broken 聲明以取得更多詳細資訊 [1]。
References
[1] D. Bacon et al. The "Double-Checked Locking is Broken" Declaration
[2] LCK10-J. Use a correct form of the double-checked locking idiom CERT
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 609
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[12] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[13] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[14] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
desc.structural.java.code_correctness_double_checked_locking
Abstract
如果執行緒沒能在向其他執行緒發訊號後解除 mutex 鎖定,其他執行緒仍會維持鎖定,並在 mutex 繼續等待。
Explanation
在執行緒對其他在 mutex 等待的執行緒發出訊號後,它必須在另一個 pthread_mutex_unlock() 函數能開始執行之前,先呼叫此函數來解除 mutex 鎖定。如果發出訊號的執行緒沒能解除 mutex 鎖定,就不會回傳在第二個執行緒呼叫的 pthread_cond_wait(),而且也不會執行該執行緒。

範例 1:以下程式碼藉由呼叫 pthread_cond_signal(),對一個在 mutex 上等待的執行緒發出訊號,但卻無法解除另一個執行緒在等待的 mutex 鎖定。


...
pthread_mutex_lock(&count_mutex);

// Signal waiting thread
pthread_cond_signal(&count_threshold_cv);
...
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[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 373
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[7] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[10] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[12] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II, APSC-DV-002950 CAT II
[33] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[34] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.structural.cpp.code_correctness_erroneous_synchronization
Abstract
建立和使用不安全的暫存檔案會使得應用程式和系統資料產生安全性弱點,容易受到攻擊。
Explanation
應用程式需要非常頻繁地呼叫暫存檔案,許多種不同的機制都是為了在 C 程式庫或 Windows(R) API 中建立暫存檔案而存在的。大多函數很容易受到多種形式的攻擊。
範例:以下程式碼會在對從網路收集的直接資料進行處理之前,使用暫存檔案進行儲存。


...
if (tmpnam_r(filename)){
FILE* tmp = fopen(filename,"wb+");
while((recv(sock,recvbuf,DATA_SIZE, 0) > 0)&&(amt!=0))
amt = fwrite(recvbuf,1,DATA_SIZE,tmp);
}
...


這程式碼並不容易被注意到,但卻容易受到很多不同的攻擊,因為它建立暫存檔案的方式並不安全。以下各節將詳述由此函數及其它內容所造成的安全弱點。大部分臭名昭著與暫存檔案建立有關的安全問題已在 Unix 作業系統上出現,但是 Windows 應用程式同樣存在著這樣的風險。此章節討論的主題為在 Unix 和 Windows 上建立暫存檔案。

不同系統間使用的方法和運作方式可能是不同的,但是各自造成的基本風險則相差不大。請參閱「建議事項」一節,以瞭解核心安全語言的相關資訊及安全建立暫存檔案的相關建議方法。

設計用來幫助建立暫存檔案的函數可依據其是否是提供檔案名稱或實際開啟新檔,而分成兩個部分。

群組 1 -「唯一的」檔案名稱:

第一組 C 程式庫和 WinAPI 函數是用來幫助建立暫存檔案,其透過產生唯一的檔案名稱來建立要被某程式打開的新暫存檔案。這部分包含了如 tmpnam()tempnam()mktemp() 這樣的 C 程式庫函數以及與其等價的以 _ (下劃線) 開頭的 C++ 文件和 Windows API 中的 GetTempFileName() 函數。這組函數在檔案名稱選擇方面很可能會有 Race Condition 的麻煩。雖然函數保證在選取檔案時,其檔案名稱是唯一的,但是沒有機制能防止其他處理或攻擊者在選取檔案後和應用程式試圖開啟檔案之前的這段時間內,建立一個相同檔案名稱。相比一個由其他程式呼叫相同函數所引發的合法衝突,攻擊者非常有可能建立一個惡意的衝突,因為由這些函數建立的檔案名稱沒有充分的隨機化來使猜測更加困難。

如果建立了特定名稱的檔案,那麼根據這個檔案的開啟方式,現有內容或存取權限都可能保持不變。如果現有檔案內容實質上是惡意的,攻擊者就可以在應用程式從暫存檔案讀取資料時向程式注入危險資料。如果攻擊者預先建立了一個能輕鬆獲取存取權限的檔案,那麼被應用程式儲存在暫存檔案裏的資料將被存取、修改或毀壞。在 Unix 系統上,如果攻擊者預先定義了一個檔案作為另一個重要檔案的連接,那麼更狡猾的攻擊也可能存在。那麼,如果應用程式從檔案截取資料或將資料寫入檔案,它將不知不覺地為攻擊者執行惡意操作。如果程式是以提升過的權限執行,那將是極其嚴重的威脅。

最後,最好的情況就是呼叫 open() 函數並使用 O_CREATO_EXCL 旗標,或者呼叫 CreateFile() 函數並使用 CREATE_NEW 屬性來開啟檔案。如此一來,如果檔案已經存在,那麼檔案建立就會失敗,也可以防範以上所描述的攻擊類型。然而,如果攻擊者可以準確預測一個檔案序列的檔案名稱,那麼應用程式將被強制禁止開啟所需的臨時儲存空間,進而引發 Denial of Service (DoS) 攻擊。如果使用由這些函數產生的一小部分亂數來選擇檔案名稱,那麼這種類型的攻擊將不難實現。

群組 2 -「唯一的」檔案:

C 程式庫函數的第二部分是藉由產生唯一的檔案名稱且開啟該檔案,來解決一些與暫存檔案有關的安全問題。這部分包含了像 tmpfile() 這樣的 C 函數和與之對應的以 _ (下劃線) 開頭的 C++ 函數,以及表現更為出色的 C 程式庫函數 mkstemp()

類似 tmpfile() 的函數構成唯一的檔案名稱,並藉由與傳遞 "wb+" 標記時 fopen() 使用的相同方法開啟檔案,就像讀/寫模式下的二位元檔一樣。如果檔案已存在,tmpfile() 將把檔案大小縮小為 0,藉此緩和前面提到的有關存在於唯一檔案名稱選擇與隨之打開選取檔案之間的 Race Condition 的安全問題。然而,這個運作方式顯然不能解決函數的安全性問題。首先,攻擊者可能使用可能由 tmpfile().開啟的檔案所保存的寬鬆存取權限來預先建立檔案。其次,在 Unix 系統上,如果攻擊者預先建立了一個檔案作為其他重要檔案的一個連接,應用程式可能會使用其被提升的權限去縮小該檔案,這樣就能按照攻擊的意願執行破壞。最後,如果 tmpfile() 建立了一個新檔案,那麼套用在此檔案上的存取權限在不同的作業系統間是不同的;如此一來,應用程式就極易受到攻擊,而攻擊者甚至不需要預先猜測到將被使用的檔案名稱也可進行攻擊。

最後,mkstemp() 函數是建立暫存檔案的安全方式。它將以一個使用者結合一組隨機生成的字元提供的檔案名稱範本的方式,來建立並開啟唯一的檔案。如果它不能建立此檔案,它將回傳 -1 表示失敗。在先進的系統上,是使用模式0600 來開啟檔案,這就意味著這個檔案將免受干擾,除非使用者改變其存取權限。然而,mkstemp() 仍然會受到使用能夠預先推測的檔案名稱的威脅,而且如果攻擊是藉由猜測或預先建立將要使用的檔案名稱的檔案導致 mkstemp() 函數失效的話,將使應用程式極易受到 Denial of Service 攻擊。
References
[1] B. Schneier Yarrow: A secure pseudorandom number generator
[2] CryptLib
[3] Crypto++
[4] BeeCrypt
[5] OpenSSL
[6] CryptoAPI: CryptGenRandom() Microsoft
[7] RtlGenRandom() Microsoft
[8] .NET System.Security.Cryptography: Random Number Generation Microsoft
desc.semantic.cpp.insecure_temporary_file
Abstract
建立和使用不安全的暫存檔案會使得應用程式和系統資料產生安全性弱點,容易受到攻擊。
Explanation
應用程式需要非常頻繁地使用暫存檔案,許多不同機制都是為了建立暫存檔案而存在的。大多函數很容易受到多種形式的攻擊。
範例:以下程式碼使用暫存檔案在它被處理之前用來儲存從網路上收集到的中間資料。


...
try:
tmp_filename = os.tempnam()
tmp_file = open(tmp_filename, 'w')
data = s.recv(4096)
while True:
more = s.recv(4096)
tmp_file.write(more)
if not more:
break
except socket.timeout:
errMsg = "Connection timed-out while connecting"
self.logger.exception(errMsg)
raise Exception
...


這程式碼並不容易被注意到,但卻容易受到很多不同的攻擊,因為它建立暫存檔案的方式並不安全。以下各節將詳述由此函數及其它內容所造成的安全弱點。大部分臭名昭著與暫存檔案建立有關的安全問題已在 Unix 作業系統上出現,但是 Windows 應用程式同樣存在著這樣的風險。

不同系統間使用的方法和運作方式可能是不同的,但是各自造成的基本風險則相差不大。請參閱「建議事項」一節,以瞭解核心安全語言的相關資訊及安全建立暫存檔案的相關建議方法。

設計用來幫助建立暫存檔案的函數可依據其是否是提供檔案名稱或實際開啟新檔,而分成兩個部分。

群組 1 -「唯一的」檔案名稱:

第一組函數是用來幫助建立暫存檔案,這組函數透過產生唯一的檔案名稱來建立稍後程式會開啟的新暫存檔案。這組函數在檔案名稱選擇方面很可能會有 Race Condition 的麻煩。雖然函數保證在選取檔案時,其檔案名稱是唯一的,但是沒有機制能防止其他處理或攻擊者在選取檔案後和應用程式試圖開啟檔案之前的這段時間內,建立一個相同檔案名稱。相比一個由其他程式呼叫相同函數所引發的合法衝突,攻擊者非常有可能建立一個惡意的衝突,因為由這些函數建立的檔案名稱沒有充分的隨機化來使猜測更加困難。

如果建立了特定名稱的檔案,那麼根據這個檔案的開啟方式,現有內容或存取權限都可能保持不變。如果現有檔案內容實質上是惡意的,攻擊者就可以在應用程式從暫存檔案讀取資料時向程式插入危險資料。如果攻擊者預先建立了一個能輕鬆獲取存取權限的檔案,那麼被應用程式儲存在暫存檔案裏的資料將被存取、修改或毀壞。在 Unix 系統上,如果攻擊者預先定義了一個檔案做為另一個重要檔案的連接,那麼更狡猾的攻擊也可能存在。那麼,如果應用程式從檔案截取資料或將資料寫入檔案,它將不知不覺地為攻擊者執行惡意操作。如果程式是以提升過的權限執行,那將是極其嚴重的威脅。

最後,最好的情況就是呼叫 open() 函數並使用 os.O_CREATos.O_EXCL 旗標來開啟檔案。如此一來,如果檔案已經存在,那麼檔案建立就會失敗,也可以防範以上所描述的攻擊類型。然而,如果攻擊者可以準確預測一個檔案序列的檔案名稱,那麼應用程式將被強制禁止開啟所需的臨時儲存空間,進而引發 Denial of Service (DoS) 攻擊。如果使用由這些函數產生的一小部分亂數來選擇檔案名稱,那麼這種類型的攻擊將不難實現。

群組 2 -「唯一的」檔案:

函數的第二部分是藉由產生唯一的檔案名稱並開啟該檔案,來嘗試解決一些與暫存檔案有關的安全問題。這一部分包含諸如 tmpfile() 的函數。

類似 tmpfile() 的函數構成唯一的檔案名稱,並藉由與傳遞 "wb+" 標記時 open() 使用的相同方法開啟檔案,就像讀/寫模式下的二位元檔一樣。如果檔案已存在,tmpfile() 將把檔案大小縮小為 0,藉此緩和前面提到的有關存在於唯一檔案名稱選擇與隨之打開選取檔案之間的 Race Condition 的安全問題。然而,這個運作方式顯然不能解決函數的安全性問題。首先,攻擊者可能使用可能由 tmpfile().開啟的檔案所保存的寬鬆存取權限來預先建立檔案。其次,在 Unix 系統上,如果攻擊者預先建立了一個檔案作為其他重要檔案的一個連接,應用程式可能會使用其被提升的權限去縮小該檔案,這樣就能按照攻擊的意願執行破壞。最後,如果 tmpfile() 建立了一個新檔案,那麼套用在此檔案上的存取權限在不同的作業系統間是不同的;如此一來,應用程式就極易受到攻擊,而攻擊者甚至不需要預先猜測到將被使用的檔案名稱也可進行攻擊。
References
[1] B. Schneier Yarrow: A secure pseudorandom number generator
[2] Python Library Reference: os Python
[3] Python Library Reference: tempfile Python
[4] Symlink race WikiPedia
[5] Time of check to time of use WikiPedia
desc.semantic.python.insecure_temporary_file
Abstract
該方法設定永遠不會過期的階段作業。
Explanation
開啟階段作業時間愈久,攻擊者威脅使用者帳戶的機率就愈大。階段作業仍為作用中時,攻擊者可能會暴力破解使用者密碼、破解使用者的無線加密金鑰,或是從開啟的瀏覽器控制階段作業。如果足夠大量的階段作業正在執行,較長的階段作業逾時時間也會導致無法釋放記憶體,最後造成阻斷服務。

範例 1:以下範例中的程式碼為未活動時間間隔上限設定了負值,導致階段作業無限期地處於作用中狀態。

...
HttpSession sesssion = request.getSession(true);
sesssion.setMaxInactiveInterval(-1);
...
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 613
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000879, CCI-002361
[8] Standards Mapping - FIPS200 IA
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-12 Session Termination (P2)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-12 Session Termination
[11] Standards Mapping - OWASP Top 10 2004 A3 Broken Authentication and Session Management
[12] Standards Mapping - OWASP Top 10 2007 A7 Broken Authentication and Session Management
[13] Standards Mapping - OWASP Top 10 2010 A3 Broken Authentication and Session Management
[14] Standards Mapping - OWASP Top 10 2017 A2 Broken Authentication
[15] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures
[16] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.8.1 Single or Multi Factor One Time Verifier Requirements (L1 L2 L3), 2.8.6 Single or Multi Factor One Time Verifier Requirements (L2 L3), 3.3.1 Session Logout and Timeout Requirements (L1 L2 L3), 3.3.2 Session Logout and Timeout Requirements (L1 L2 L3), 3.3.4 Session Logout and Timeout Requirements (L2 L3), 3.6.1 Re-authentication from a Federation or Assertion (L3), 3.6.2 Re-authentication from a Federation or Assertion (L3)
[17] Standards Mapping - OWASP Mobile 2014 M9 Improper Session Handling
[18] Standards Mapping - OWASP Mobile 2024 M3 Insecure Authentication/Authorization
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.3, Requirement 8.5.15
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.7, Requirement 8.5.15
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8, Requirement 8.5.15
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.10, Requirement 8.1.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.10, Requirement 8.1.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10, Requirement 8.1.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.10, Requirement 8.1.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 8.2.8
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.3 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.3 - Authentication and Access Control
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.3 - Authentication and Access Control, Control Objective C.2.1.2 - Web Software Access Controls, Control Objective C.2.3.2 - Web Software Access Controls
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3415 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3415 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3415 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3415 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3415 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3415 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3415 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Session Expiration (WASC-47)
[52] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Session Expiration
desc.structural.java.j2ee_bad_practices_insufficient_session_expiration
Abstract
Web 應用程式不應嘗試關閉自身的容器。
Explanation
讓 Web 應用程式嘗試關閉自身的容器是不對的。呼叫終結方法可能是殘餘除錯程式碼的一部分,或是從非 J2EE 應用程式所匯入程式碼的一部分。
References
[1] ERR09-J. Do not allow untrusted code to terminate the JVM CERT
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1
[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 382
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[10] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[12] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[33] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[34] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.semantic.java.j2ee_badpractices_jvm_termination