界: Time and State

分布式计算是关于时间和状态的。也就是说,为了让多个组件相互通信,必须共享状态,所有这些都需要时间。

大多数程序员都会将其工作拟人化。他们会让一个控制线程以同样的方式(他们必须自己完成工作时采取的方式)执行整个程序。然而,现代计算机不同任务之间切换得非常快,在多核、多 CPU 或分布式系统中,两个事件可能完全同时发生。程序员预期的程序执行过程与实际情况之间存在差距,即存在缺陷。这些缺陷与线程、流程、时间和信息之间的意外交互有关。这些交互是通过共享状态发生的:信号量、变量、文件系统,以及总而言之,可以存储信息的任何内容。

18 个项目已找到
弱点
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 - Common Weakness Enumeration CWE ID 579
[4] Standards Mapping - OWASP Top 10 2004 A3 Broken Authentication and Session Management
[5] Standards Mapping - OWASP Top 10 2007 A7 Broken Authentication and Session Management
[6] Standards Mapping - OWASP Top 10 2010 A3 Broken Authentication and Session Management
[7] Standards Mapping - OWASP Top 10 2013 A2 Broken Authentication and Session Management
[8] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[9] Standards Mapping - OWASP Top 10 2017 A2 Broken Authentication
[10] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.3
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.7
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.10
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.10
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.10
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[21] 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 - Common Weakness Enumeration CWE ID 557
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[6] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[8] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[9] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[10] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[11] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[12] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[29] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[30] 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() 对象。有关更多详细信息,请参见 The "Double-Checked Locking is Broken" Declaration [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 - Common Weakness Enumeration CWE ID 609
[4] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[5] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[6] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[8] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[9] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[10] 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,而其他线程会继续等待 mutex。


...
pthread_mutex_lock(&count_mutex);

// Signal waiting thread
pthread_cond_signal(&count_threshold_cv);
...
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 373
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[3] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[6] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[8] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[9] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[10] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[11] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[12] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[29] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[30] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.structural.cpp.code_correctness_erroneous_synchronization
Abstract
创建和使用 insecure temporary file 会容易使应用程序和系统数据受到攻击。
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 属性来打开文件,这样,如果文件已经存在,该操作就会失败,因此可以有效地防止上述攻击类型。然而,如果攻击者可以准确预测一系列临时文件名,那么就可以阻止应用程序打开必要的临时存储空间,从而导致拒绝服务 (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
创建和使用 insecure temporary file 会容易使应用程序和系统数据受到攻击。
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 的系统上,如果攻击者预先创建了一个作为另一个重要文件链接的文件,则可能会引发更加严重的攻击。然后,如果应用程序被截短或向文件中写入数据,那么它可能会在不知不觉中帮助攻击者,为其执行各种恶意操作。如果程序再使用提高了的权限运行,那会使问题变得更加严重。

最后,最好通过使用 os.O_CREATos.O_EXCL 标记调用 open() 来打开文件,如果该文件已存在,则操作将失败,从而可防止上述攻击类型。然而,如果攻击者可以准确预测一系列临时文件名,那么就可以阻止应用程序打开必要的临时存储空间,从而导致拒绝服务 (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
会话持续时间越长,攻击者危害用户帐户的机会就越大。当会话处于活动状态时,攻击者可能会强力攻击用户的密码、破解用户的无线加密密钥或者通过打开的浏览器强占会话。如果创建大量的会话,较长的会话超时时间还会阻止系统释放内存,并最终导致 denial of service。

例 1: 以下示例中的代码为实现最长不活动时间间隔而设置了负值,以使会话保持无限期的活动状态。

...
HttpSession sesssion = request.getSession(true);
sesssion.setMaxInactiveInterval(-1);
...
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 613
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000879, CCI-002361
[3] Standards Mapping - FIPS200 IA
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-12 Session Termination (P2)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-12 Session Termination
[6] Standards Mapping - OWASP Top 10 2004 A3 Broken Authentication and Session Management
[7] Standards Mapping - OWASP Top 10 2007 A7 Broken Authentication and Session Management
[8] Standards Mapping - OWASP Top 10 2010 A3 Broken Authentication and Session Management
[9] Standards Mapping - OWASP Top 10 2013 A2 Broken Authentication and Session Management
[10] Standards Mapping - OWASP Mobile 2014 M9 Improper Session Handling
[11] Standards Mapping - OWASP Top 10 2017 A2 Broken Authentication
[12] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures
[13] Standards Mapping - OWASP Mobile 2023 M3 Insecure Authentication/Authorization
[14] 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)
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.3, Requirement 8.5.15
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.7, Requirement 8.5.15
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8, Requirement 8.5.15
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.10, Requirement 8.1.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.10, Requirement 8.1.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10, Requirement 8.1.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.10, Requirement 8.1.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 8.2.8
[23] 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
[24] 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
[25] 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
[26] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3415 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3415 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3415 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3415 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3415 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3415 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3415 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000070 CAT II, APSC-DV-000080 CAT II, APSC-DV-001980 CAT II
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Session Expiration (WASC-47)
[48] 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 - Common Weakness Enumeration CWE ID 382
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[6] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[8] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[9] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[10] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[11] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[12] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[29] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[30] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.semantic.java.j2ee_badpractices_jvm_termination