界: Input Validation and Representation

输入验证与表示问题是由元字符、交替编码和数字表示引起的。安全问题源于信任输入。这些问题包括:“Buffer Overflows”、“Cross-Site Scripting”攻击、“SQL Injection”等其他问题。

175 个项目已找到
弱点
Abstract
该程序使用了界定不当的 format string,其中包含一个 %f 或 %F 浮点说明符。特别大的浮点值会导致该程序在分配的内存边界之外写入数据,这会损坏数据、引起程序崩溃或为恶意代码的执行提供机会。
Explanation
Buffer overflow 可能是人们最熟悉的一种软件安全漏洞。虽然绝大多数软件开发者都知道什么是 Buffer overflow 漏洞,但是无论是对继承下来的或是新开发的应用程序来说,Buffer overflow 攻击仍然是一种最常见的攻击形式。对于这个问题出现的原因,一方面是造成 buffer overflow 漏洞的方式有很多种,另一方面是用于防止 buffer overflow 的技术也容易出错。

在一个典型的 buffer overflow 攻击中,攻击者将数据传送到某个程序,程序会将这些数据储存到一个较小的堆栈缓冲区内。结果,调用堆栈上的信息会被覆盖,其中包括函数的返回指针。数据会被用来设置返回指针的值,这样,当该函数返回时,函数的控制权便会转移给包含在攻击者数据中的恶意代码。

虽然这种类型的堆栈 buffer overflow 在某些平台和开发组织中十分常见,但仍不乏存在其他各种类型的 buffer overflow,其中包括堆 buffer overflow 和 off-by-one 错误等。有关 buffer overflow 如何进行攻击的详细信息,许多优秀的著作都进行了相关介绍,如 Building Secure Software [1]、Writing Secure Code [2] 以及 The Shellcoder's Handbook [3]。

在代码层上,buffer overflow 漏洞通常会违反程序员的各种假设。C 和 C++ 中的很多内存处理函数都没有执行边界检查,因而可轻易地超出缓冲区所操作的、已分配的边界。即使是边界函数(如 strncpy()),使用方式不正确也会引发漏洞。对内存的处理加之有关数据段大小和结构方面所存在种种错误假设,是导致大多数 buffer overflow 漏洞产生的根源。

在这里,一个结构不良的 format string 会导致程序在分配的内存边界之外写入数据。

示例: 以下代码会溢出 buf,因为根据 f 的大小,格式字符串说明符 "%d %.1f ... " 可能会超出分配的内存大小。


void formatString(int x, float f) {
char buf[40];
sprintf(buf, "%d %.1f ... ", x, f);
}
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[3] J. Koziol et al. The Shellcoder's Handbook: Discovering and Exploiting Security Holes John Wiley & Sons
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[8] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[10] Standards Mapping - CIS Kubernetes Benchmark complete
[11] Standards Mapping - Common Weakness Enumeration CWE ID 787
[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [12] CWE ID 787
[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [2] CWE ID 787
[14] Standards Mapping - Common Weakness Enumeration Top 25 2021 [1] CWE ID 787
[15] Standards Mapping - Common Weakness Enumeration Top 25 2022 [1] CWE ID 787
[16] Standards Mapping - Common Weakness Enumeration Top 25 2023 [1] CWE ID 787
[17] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002824
[18] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[19] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[20] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[21] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-16 Memory Protection (P1)
[22] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-16 Memory Protection
[23] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[24] Standards Mapping - OWASP Top 10 2013 A1 Injection
[25] Standards Mapping - OWASP Top 10 2017 A1 Injection
[26] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[27] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.2 - Terminal Software Attack Mitigation
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.2 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[40] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 119
[41] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 134
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3560 CAT I, APP3590.1 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3560 CAT I, APP3590.1 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3560 CAT I, APP3590.1 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3560 CAT I, APP3590.1 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3560 CAT I, APP3590.1 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3560 CAT I, APP3590.1 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3560 CAT I, APP3590.1 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002590 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002590 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002590 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002590 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002590 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002590 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002590 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002590 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002590 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002590 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002590 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002590 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002590 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002590 CAT I
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Buffer Overflow (WASC-07)
[64] Standards Mapping - Web Application Security Consortium 24 + 2 Buffer Overflow
desc.internal.cpp.buffer_overflow_format_string_%f_%F
Abstract
该程序在分配的内存边界之外写入数据,这可能会损坏数据、引起程序崩溃或为恶意代码的执行提供机会。
Explanation
Buffer overflow 可能是人们最熟悉的一种软件安全漏洞。虽然绝大多数软件开发者都知道什么是 Buffer overflow 漏洞,但是无论是对继承下来的或是新开发的应用程序来说,Buffer overflow 攻击仍然是一种最常见的攻击形式。对于这个问题出现的原因,一方面是造成 buffer overflow 漏洞的方式有很多种,另一方面是用于防止 buffer overflow 的技术也容易出错。

在一个典型的 buffer overflow 攻击中,攻击者将数据传送到某个程序,程序会将这些数据储存到一个较小的堆栈缓冲区内。结果,调用堆栈上的信息会被覆盖,其中包括函数的返回指针。数据会被用来设置返回指针的值,这样,当该函数返回时,函数的控制权便会转移给包含在攻击者数据中的恶意代码。

虽然这种类型的 off-by-one 错误在某些平台和开发组织中十分常见,但仍不乏存在其他各种类型的 buffer overflow,其中包括堆栈 buffer overflow 和堆 buffer overflow 等。有关 buffer overflow 如何进行攻击的详细信息,许多优秀的著作都进行了相关介绍,如 Building Secure Software [1]、Writing Secure Code [2] 以及 The Shellcoder's Handbook [3]。

在代码层上,buffer overflow 漏洞通常会违反程序员的各种假设。C 和 C++ 中的很多内存处理函数都没有执行边界检查,因而可轻易地超出缓冲区所操作的、已分配的边界。即使是边界函数(如 strncpy()),使用方式不正确也会引发漏洞。对内存的处理加之有关数据段大小和结构方面所存在种种错误假设,是导致大多数 buffer overflow 漏洞产生的根源。

示例:以下代码包含一个 off-by-one 缓冲区溢出,当 recv 返回的字节数达到最大允许读取的 sizeof(buf) 字节数时,便会发生此溢出。在这种情况下,随后对 buf[nbytes] 的间接引用会将 null 字节写入到所分配内存的边界之外。


void receive(int socket) {
char buf[MAX];
int nbytes = recv(socket, buf, sizeof(buf), 0);
buf[nbytes] = '\0';
...
}
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[3] J. Koziol et al. The Shellcoder's Handbook: Discovering and Exploiting Security Holes John Wiley & Sons
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[8] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[10] Standards Mapping - CIS Kubernetes Benchmark complete
[11] Standards Mapping - Common Weakness Enumeration CWE ID 129, CWE ID 131, CWE ID 193, CWE ID 787, CWE ID 805
[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [1] CWE ID 119, [3] CWE ID 020, [12] CWE ID 787
[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [5] CWE ID 119, [3] CWE ID 020, [2] CWE ID 787
[14] Standards Mapping - Common Weakness Enumeration Top 25 2021 [1] CWE ID 787, [4] CWE ID 020, [17] CWE ID 119
[15] Standards Mapping - Common Weakness Enumeration Top 25 2022 [1] CWE ID 787, [4] CWE ID 020, [19] CWE ID 119
[16] Standards Mapping - Common Weakness Enumeration Top 25 2023 [1] CWE ID 787, [6] CWE ID 020, [17] CWE ID 119
[17] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002824
[18] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[19] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[20] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1, Rule 18-0-5
[21] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-16 Memory Protection (P1)
[22] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-16 Memory Protection
[23] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[24] Standards Mapping - OWASP Top 10 2013 A1 Injection
[25] Standards Mapping - OWASP Top 10 2017 A1 Injection
[26] 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)
[27] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[28] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[29] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.2 - Terminal Software Attack Mitigation
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.2 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[41] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 119
[42] Standards Mapping - SANS Top 25 2010 Risky Resource Management - CWE ID 805, Risky Resource Management - CWE ID 129, Risky Resource Management - CWE ID 131
[43] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 131
[44] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3590.1 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3590.1 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3590.1 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3590.1 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3590.1 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3590.1 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3590.1 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002590 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002590 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002590 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002590 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002590 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002590 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002590 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002590 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002590 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002590 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002590 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002590 CAT I
[63] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002590 CAT I
[64] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002590 CAT I
[65] Standards Mapping - Web Application Security Consortium Version 2.00 Buffer Overflow (WASC-07)
[66] Standards Mapping - Web Application Security Consortium 24 + 2 Buffer Overflow
desc.internal.cpp.buffer_overflow_off_by_one
Abstract
该程序使用带符号的比较来检查稍后会被视为不带符号的值。这将会导致程序在分配的内存边界之外写入数据,这可能会损坏数据、引起程序崩溃或为恶意代码的执行提供机会。
Explanation
Buffer overflow 可能是人们最熟悉的一种软件安全漏洞。虽然绝大多数软件开发者都知道什么是 Buffer overflow 漏洞,但是无论是对继承下来的或是新开发的应用程序来说,Buffer overflow 攻击仍然是一种最常见的攻击形式。对于这个问题出现的原因,一方面是造成 buffer overflow 漏洞的方式有很多种,另一方面是用于防止 buffer overflow 的技术也容易出错。

在一个典型的 buffer overflow 攻击中,攻击者将数据传送到某个程序,程序会将这些数据储存到一个较小的堆栈缓冲区内。结果,调用堆栈上的信息会被覆盖,其中包括函数的返回指针。数据会被用来设置返回指针的值,这样,当该函数返回时,函数的控制权便会转移给包含在攻击者数据中的恶意代码。

虽然这种类型的堆栈 buffer overflow 在某些平台和开发组织中十分常见,但仍不乏存在其他各种类型的 buffer overflow,其中包括堆 buffer overflow 和 off-by-one 错误等。有关 buffer overflow 如何进行攻击的详细信息,许多优秀的著作都进行了相关介绍,如 Building Secure Software [1]、Writing Secure Code [2] 以及 The Shellcoder's Handbook [3]。

在代码层上,buffer overflow 漏洞通常会违反程序员的各种假设。C 和 C++ 中的很多内存处理函数都没有执行边界检查,因而可轻易地超出缓冲区所操作的、已分配的边界。即使是边界函数(如 strncpy()),使用方式不正确也会引发漏洞。对内存的处理加之有关数据段大小和结构方面所存在种种错误假设,是导致大多数 buffer overflow 漏洞产生的根源。

示例:以下代码尝试通过检查从 getInputLength() 中读取的不可信的值,验证其是否小于目标缓冲区 output 的大小,来避免 off-by-one buffer overflow。然而,因为 lenMAX 之间比较的是带符号的值,所以如果 len 为负值,在其转换为 memcpy() 不带符号的参数时,将会变成一个超级大的正数。


void TypeConvert() {
char input[MAX];
char output[MAX];

fillBuffer(input);
int len = getInputLength();

if (len <= MAX) {
memcpy(output, input, len);
}
...
}
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[3] J. Koziol et al. The Shellcoder's Handbook: Discovering and Exploiting Security Holes John Wiley & Sons
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[8] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[10] Standards Mapping - CIS Kubernetes Benchmark complete
[11] Standards Mapping - Common Weakness Enumeration CWE ID 195, CWE ID 805
[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [1] CWE ID 119
[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [5] CWE ID 119
[14] Standards Mapping - Common Weakness Enumeration Top 25 2021 [17] CWE ID 119
[15] Standards Mapping - Common Weakness Enumeration Top 25 2022 [19] CWE ID 119
[16] Standards Mapping - Common Weakness Enumeration Top 25 2023 [17] CWE ID 119
[17] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002824
[18] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[19] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[20] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[21] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-16 Memory Protection (P1)
[22] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-16 Memory Protection
[23] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[24] Standards Mapping - OWASP Top 10 2013 A1 Injection
[25] Standards Mapping - OWASP Top 10 2017 A1 Injection
[26] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[27] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.2 - Terminal Software Attack Mitigation
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.2 - Terminal Software Attack Mitigation
[40] Standards Mapping - SANS Top 25 2010 Risky Resource Management - CWE ID 805
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3550 CAT I, APP3590.1 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3550 CAT I, APP3590.1 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3550 CAT I, APP3590.1 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3550 CAT I, APP3590.1 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3550 CAT I, APP3590.1 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3550 CAT I, APP3590.1 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3550 CAT I, APP3590.1 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002590 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002590 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002590 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002590 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002590 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002590 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002590 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002590 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002590 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002590 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002590 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002590 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002590 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002590 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Buffer Overflow (WASC-07)
[63] Standards Mapping - Web Application Security Consortium 24 + 2 Buffer Overflow
desc.internal.cpp.buffer_overflow_signed_comparison
Abstract
用户控制的数据用作模板引擎的模板,这使得攻击者能够访问模板上下文,并在某些情况下在浏览器中注入和运行恶意代码。
Explanation
模板引擎用于使用动态数据呈现内容。此上下文数据通常由用户控制并通过模板设置格式,以生成 Web 页面、电子邮件等。模板引擎可通过条件、循环等代码构造处理上下文数据,从而允许在模板中使用功能强大的语言表达式来呈现动态内容。如果攻击者能够控制要呈现的模板,他们将能够通过注入表达式来公开上下文数据,并在服务器中运行恶意代码。

示例 1:以下示例显示了如何通过 URL 检索模板并使用模板在 AngularJS 中呈现信息。

function MyController(function($stateParams, $interpolate){
var ctx = { foo : 'bar' };
var interpolated = $interpolate($stateParams.expression);
this.rendered = interpolated(ctx);
...
}


在这种情况下,$stateParams.expression将采用可能受用户控制的数据,并将其作为用于指定上下文的模板进行计算。这又可能会允许恶意用户在浏览器中运行他们想要的代码、检索关于代码运行的上下文的信息、查找有关如何创建应用程序的额外信息,或将此代码转换为 full blown XSS 攻击。
References
[1] AngularJS Security Guide Google
desc.dataflow.javascript.client_side_template_injection
Abstract
如果使用未验证的用户输入来指定页面中包含的文件路径,会使攻击者能够在服务器中注入恶意代码或查看敏感文件。
Explanation
在以下情况中会发生 Unauthorized Include 漏洞:

1. 数据从一个不可信赖的数据源(最常见的是一个 Web 请求)进入 Web 应用程序。

2. 数据是字符串的一部分,该字符串指明了 <cfinclude> 标签的 template 属性。
示例:以下代码利用来自 Web 表单的输入构造了一条路径,通过这条路径可以找到用来设定用户主页格式的特殊文件。由此可以看出,程序员没有考虑到攻击者可能会提供恶意文件名,如 "../../users/wileyh/malicious",从而导致该应用程序执行攻击者主目录下文件的恶意内容。


<cfinclude template =
"C:\\custom\\templates\\#Form.username#.cfm">


如果攻击者可以指定 <cfinclude> 标签所包含的文件,即表示他们能使应用程序在当前页上包含服务器文件系统中几乎所有文件的内容。这至少会对两个方面产生重大影响。如果攻击者可以在服务器的文件系统上某个位置(如用户的主目录或一个通用的上传目录)进行写入,即表示他们能使应用程序在页面中包含一个恶意文件,并将由服务器执行该文件。即使不具备服务器文件系统的写权限,攻击者通常也能通过指定服务器上某个文件的路径,访问敏感或私人信息。
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[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 integrity
[6] Standards Mapping - Common Weakness Enumeration CWE ID 94
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [18] CWE ID 094
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [17] CWE ID 094
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[14] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2007 A3 Malicious File Execution
[16] Standards Mapping - OWASP Top 10 2010 A1 Injection
[17] Standards Mapping - OWASP Top 10 2013 A1 Injection
[18] Standards Mapping - OWASP Top 10 2017 A1 Injection
[19] Standards Mapping - OWASP Top 10 2021 A03 Injection
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.5 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.8 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 094
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3600 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3600 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3600 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3600 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3600 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3600 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3600 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-003300 CAT II
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.cfml.unauthorized_include
Abstract
执行不可信赖资源中的命令,或在不可信赖的环境中执行命令,都会导致程序以攻击者的名义执行恶意命令。
Explanation
Command Injection 漏洞主要表现为以下两种形式:

- 攻击者能够篡改程序执行的命令:攻击者直接控制了所执行的命令。

- 攻击者能够篡改命令的执行环境:攻击者间接地控制了所执行的命令。

在这种情况下,我们着重关注第一种情况,即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现:

1. 数据从不可信赖的数据源进入应用程序。

2. 数据被用作代表应用程序所执行命令的字符串,或字符串的一部分。

3. 通过命令的执行,应用程序会授予攻击者一种原本不该拥有的特权或能力。

例 1:下面这段来自系统实用程序的代码根据注册表项 APPHOME 来决定其安装目录,然后根据指定目录的相对路径执行初始化脚本。


...
CALL FUNCTION 'REGISTRY_GET'
EXPORTING
KEY = 'APPHOME'
IMPORTING
VALUE = home.

CONCATENATE home INITCMD INTO cmd.
CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[].
...
Example 1 中的代码可以使攻击者通过修改注册表项 APPHOME 以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限,继而随心所欲地执行命令。由于程序不会验证从注册表中读取的值,因此如果攻击者能够控制注册表项 APPHOME 的值,他们就能欺骗应用程序去运行恶意代码,从而取得系统控制权。

例 2:下面的代码来自一个管理 Web 应用程序,旨在使用户能够使用一个围绕 rman 实用程序的批处理文件封装器来启动 Oracle 数据库备份,然后运行一个 cleanup.bat 脚本来删除一些临时文件。脚本 rmanDB.bat 接受单个命令行参数,该参数指定了要执行的备份类型。由于访问数据库受限,所以应用程序执行备份需要具有较高权限的用户。


...
btype = request->get_form_field( 'backuptype' )
CONCATENATE `/K 'c:\\util\\rmanDB.bat ` btype `&&c:\\util\\cleanup.bat'` INTO cmd.

CALL FUNCTION 'SXPG_COMMAND_EXECUTE_LONG'
EXPORTING
commandname = cmd_exe
long_params = cmd_string
EXCEPTIONS
no_permission = 1
command_not_found = 2
parameters_too_long = 3
security_risk = 4
OTHERS = 5.
...


这里的问题是:程序没有对读取自用户的 backuptype参数进行任何验证。通常情况下 SXPG_COMMAND_EXECUTE_LONG 函数模块不会执行多条命令,但在这种情况下,程序会首先运行 cmd.exe shell,从而可以通过调用一次 CALL 'SYSTEM' 来执行多条命令。在调用该 shell 之后,它即会允许执行用两个与号分隔的多条命令。如果攻击者传递了一个形式为 "&& del c:\\dbms\\*.*" 的字符串,那么应用程序将随程序指定的其他命令一起执行此命令。由于该应用程序的特性,运行该应用程序需要具备与数据库进行交互所需的权限,这就意味着攻击者注入的任何命令都将通过这些权限得以运行。

示例 3:下面的代码来自一个 Web 应用程序,用户可通过该应用程序提供的界面在系统上更新他们的密码。在某些网络环境中更新密码时,其中的一个步骤就是在 /var/yp 目录中运行 make 命令。


...
MOVE 'make' to cmd.
CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[].
...


这里的问题在于程序没有在它的构造中指定一个绝对路径,并且没能在执行 CALL 'SYSTEM' 调用前清除它的环境变量。如果攻击者能够修改 $PATH 变量,把它指向名为 make 恶意二进制代码,程序就会在其指定的环境下执行,然后加载该恶意二进制代码,而非原本期望的代码。由于应用程序自身的特性,运行该应用程序需要具备执行系统操作所需的权限,这意味着攻击者会利用这些权限执行自己的 make,从而可能导致攻击者完全控制系统。
References
[1] SAP OSS notes 677435, 686765, 866732, 854060, 1336776, 1520462, 1530983 and related notes.
desc.dataflow.abap.command_injection
Abstract
执行不可信赖资源中的命令,或在不可信赖的环境中执行命令,都会导致程序以攻击者的名义执行恶意命令。
Explanation
Command Injection 漏洞主要表现为以下两种形式:

- 攻击者能够篡改程序执行的命令:攻击者直接控制了所执行的命令。

- 攻击者能够篡改命令的执行环境:攻击者间接地控制了所执行的命令。

在这种情况下,我们着重关注第一种情况,即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现:

1. 数据从不可信赖的数据源进入应用程序。

2. 数据被用作代表应用程序所执行命令的字符串,或字符串的一部分。

3. 通过命令的执行,应用程序会授予攻击者一种原本不该拥有的特权或能力。

例 1:下面这段代码根据配置文件的输入来决定其安装目录,然后根据指定目录的相对路径执行初始化脚本。


...
var fs:FileStream = new FileStream();
fs.open(new File(String(configStream.readObject())+".txt"), FileMode.READ);
home = String(fs.readObject(home));
var cmd:String = home + INITCMD;
fscommand("exec", cmd);
...
Example 1 中的代码可以使攻击者通过修改配置文件 configStream 的内容以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限,继而随心所欲地执行命令。由于程序不会验证从该文件读取的值,因此如果攻击者可以控制这些值,他们就能欺骗应用程序去运行恶意代码,从而取得系统控制权。

例 2:下面的代码来自一个管理 Web 应用程序,旨在使用户能够使用一个围绕 rman 实用程序的批处理文件封装器来启动 Oracle 数据库备份,然后运行一个 cleanup.bat 脚本来删除一些临时文件。脚本 rmanDB.bat 接受单个命令行参数,该参数指定了要执行的备份类型。由于访问数据库受限,所以应用程序执行备份需要具有较高权限的用户。


...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var btype:String = String(params["backuptype"]);
var cmd:String = "cmd.exe /K \"c:\\util\\rmanDB.bat " + btype + "&&c:\\util\\cleanup.bat\"";
fscommand("exec", cmd);
...


这里的问题是:程序没有对读取自用户的 backuptype参数进行任何验证。通常情况下 fscommand() 函数不会执行多条命令,但在这种情况下,程序会首先运行 cmd.exe shell,从而可以通过调用一次 fscommnd() 来执行多条命令。在调用该 shell 之后,它即会允许执行用两个与号分隔的多条命令。如果攻击者传递了一个形式为 "&& del c:\\dbms\\*.*" 的字符串,那么应用程序将随程序指定的其他命令一起执行此命令。由于该应用程序的特性,运行该应用程序需要具备与数据库进行交互所需的权限,这就意味着攻击者注入的任何命令都将通过这些权限得以运行。

示例 3:下面的代码来自一个 Web 应用程序,用户可通过该应用程序提供的界面在系统上更新他们的密码。在某些网络环境中更新密码时,其中的一个步骤就是在 /var/yp 目录中运行 make 命令。


...
fscommand("exec", "make");
...


这里的问题在于程序没有在它的构造中指定一个绝对路径,并且没能在执行 fscommand() 调用前清除它的环境变量。如果攻击者能够修改 $PATH 变量,把它指向名为 make 恶意二进制代码,程序就会在其指定的环境下执行,然后加载该恶意二进制代码,而非原本期望的代码。由于应用程序自身的特性,运行该应用程序需要具备执行系统操作所需的权限,这意味着攻击者会利用这些权限执行自己的 make,从而可能导致攻击者完全控制系统。
desc.dataflow.actionscript.command_injection
Abstract
执行不可信赖资源中的命令,或在不可信赖的环境中执行命令,都会导致程序以攻击者的名义执行恶意命令。
Explanation
Command Injection 漏洞主要表现为以下两种形式:

- 攻击者能够篡改程序执行的命令:攻击者直接控制了所执行的命令。

- 攻击者能够篡改命令的执行环境:攻击者间接地控制了所执行的命令。

在这种情况下,我们着重关注第一种情况,即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现:

1. 数据从不可信赖的数据源进入应用程序。

2. 数据被用作代表应用程序所执行命令的字符串,或字符串的一部分。

3. 通过命令的执行,应用程序会授予攻击者一种原本不该拥有的特权或能力。

例 1:下面这段来自系统实用程序的代码根据系统属性 APPHOME 来决定其安装目录,然后根据指定目录的相对路径执行一个初始化脚本。


...
string val = Environment.GetEnvironmentVariable("APPHOME");
string cmd = val + INITCMD;
ProcessStartInfo startInfo = new ProcessStartInfo(cmd);
Process.Start(startInfo);
...
Example 1 中的代码可以使攻击者通过修改系统属性 APPHOME 以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限,继而随心所欲地执行命令。由于程序不会验证从环境中读取的值,因此如果攻击者能够控制系统属性 APPHOME 的值,他们就能欺骗应用程序去运行恶意代码,从而取得系统控制权。

例 2:下面的代码来自一个管理 Web 应用程序,旨在使用户能够使用一个围绕 rman 实用程序的批处理文件封装器来启动 Oracle 数据库备份,然后运行一个 cleanup.bat 脚本来删除一些临时文件。脚本 rmanDB.bat 接受单个命令行参数,该参数指定了要执行的备份类型。由于访问数据库受限,所以应用程序执行备份需要具有较高权限的用户。


...
string btype = BackupTypeField.Text;
string cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat"
+ btype + "&&c:\\util\\cleanup.bat\""));
Process.Start(cmd);
...


这里的问题是:程序没有对 BackupTypeField进行任何验证。通常情况下 Process.Start() 函数不会执行多条命令,但在这种情况下,程序会首先运行 cmd.exe shell,从而可以通过调用一次 Process.Start() 来执行多条命令。在调用该 shell 之后,它即会允许执行用两个与号分隔的多条命令。如果攻击者传递了一个形式为 "&& del c:\\dbms\\*.*" 的字符串,那么应用程序将随程序指定的其他命令一起执行此命令。由于该应用程序的特性,运行该应用程序需要具备与数据库进行交互所需的权限,这就意味着攻击者注入的任何命令都将通过这些权限得以运行。

示例 3:以下代码来自一个 Web 应用程序,该应用程序可以使用户访问一个界面以更新其在系统中的密码。在此网络环境中更新密码时,其中一个步骤就是运行 update.exe 命令,如下所示:


...
Process.Start("update.exe");
...


这里的问题在于,程序没有指定一个绝对的路径,并且在执行 Process.start() 调用之前未清除其环境变量。如果攻击者能够修改 $PATH 变量,把它指向名为 update.exe 恶意二进制代码,程序就会在其指定的环境下执行,然后加载该恶意二进制代码,而非原本期望的代码。由于应用程序自身的特性,运行该应用程序需要具备执行系统操作所需的权限,这意味着攻击者会利用这些权限执行自己的 update.exe,从而可能导致攻击者完全控制系统。
desc.dataflow.dotnet.command_injection
Abstract
执行包含无效用户输入的命令,会导致应用程序以攻击者的名义执行操作。
Explanation
Command Injection 漏洞主要表现为以下两种形式:

- 攻击者能够篡改程序执行的命令:攻击者直接控制了所执行的命令。

- 攻击者能够篡改命令的执行环境:攻击者间接地控制了所执行的命令。

在这种情况下,我们着重关注第一种情况,既攻击者显式地控制了所执行的命令。这种类型的 Command Injection 漏洞会在以下情况下出现:

1. 数据从不可信赖的数据源进入应用程序。


2. 数据是字符串的一部分,应用程序将该字符串作为命令加以执行。


3. 通过命令的执行,应用程序会授予攻击者一种原本不该拥有的特权或能力。

示例 1:以下这个简单的程序将文件名作为命令行参数加以接受,并将文件的内容回显给用户。该程序是按照 setuid root 安装的,因为其最初的用途是一种学习工具,以便让那些仍在正在接受培训的系统管理员查看特权系统文件,而不授予其篡改权限或损坏系统的权力。


int main(char* argc, char** argv) {
char cmd[CMD_MAX] = "/usr/bin/cat ";
strcat(cmd, argv[1]);
system(cmd);
}


因为程序是利用 root 权限运行的,所以也会以 root 权限来调用 system()。如果用户指定了标准的文件名,那么调用就可按照您期望的方式进行。然而,如果攻击者传递了一个 ";rm -rf /" 形式的字符串,由于缺少参数,对 system() 的调用无法成功地执行 cat,然后程序会逐层删除根分区中的内容。

示例 2:以下代码来自于一个特权程序,该程序使用环境变量 $APPHOME 来确定应用程序的安装目录,然后在该目录中执行一个初始化脚本。


...
char* home=getenv("APPHOME");
char* cmd=(char*)malloc(strlen(home)+strlen(INITCMD));
if (cmd) {
strcpy(cmd,home);
strcat(cmd,INITCMD);
execl(cmd, NULL);
}
...


Example 1 中所示,该示例中的代码允许攻击者使用更高的应用程序权限来执行任意命令。在此示例中,攻击者可以篡改环境变量 $APPHOME 以指定包含恶意版本 INITCMD 的其他路径。由于程序不会验证从环境中读取的值,因此攻击者可通过控制该环境变量来诱骗应用程序去运行恶意代码。

因为攻击者使用环境变量来控制程序调用的命令,所以在本例中,环境的影响是不言而喻的。现在,我们转移一下注意力,看看如果攻击者能够改变命令的解析方式,会发生什么情况。

示例 3:以下代码来自一个基于 Web 的 CGI 实用程序,用户可以利用此实用程序修改其密码。通过 NIS 执行的密码更新过程包括在 /var/yp 目录中运行 make。请注意,由于程序更新了密码记录,因此它已按照 setuid root 安装。

程序会调用 make,如下所示:


system("cd /var/yp && make &> /dev/null");


与上一个示例不同,因为本例中的命令采用硬编码形式,所以攻击者不能控制传输到 system() 的参数。但是,因为程序没有指定 make 的绝对路径,而且没有在调用命令之前清除任何环境变量,所以攻击者就能够篡改它们的 $PATH 变量,以便指向一个名为 make 的恶意二进制代码,并在 shell 提示符中执行 CGI 脚本。而且,因为程序已按照 setuid root 安装,所以攻击者的 make 目前会在 root 的权限下执行。

在 Windows 中,还存在其他风险。

示例 4:直接或通过调用 _spawn() 家族中的某项函数调用 CreateProcess() 时,如果可执行文件或路径中存在空格,必须谨慎操作。


...
LPTSTR cmdLine = _tcsdup(TEXT("C:\\Program Files\\MyApplication -L -S"));
CreateProcess(NULL, cmdLine, ...);
...
CreateProcess() 解析空格时,操作系统尝试执行的第一个可执行文件将是 Program.exe,而不是 MyApplication.exe。因此,如果攻击者能够在系统上安装名称为 Program.exe 的恶意应用程序,任何使用 Program Files 目录错误调用 CreateProcess() 的程序将运行此恶意应用程序,而非原本期望的应用程序。

环境在程序的系统命令执行中扮演了一个十分重要的角色。由于诸如 system()exec()CreateProcess() 之类的函数利用调用这些函数的程序的环境,因此攻击者有可能影响这些调用行为。
desc.dataflow.cpp.command_injection
Abstract
在不指定绝对路径的情况下执行命令,使攻击者能够通过更改 $PATH 或程序执行环境的其他方面使用该程序执行恶意二进制代码。
Explanation
Command Injection 漏洞主要表现为以下两种形式:

- 攻击者能够篡改程序执行的命令:攻击者直接控制命令。

- 攻击者能够控制程序的参数。

- 攻击者能够篡改命令的执行环境:攻击者间接地控制了所执行的命令。

在这种情况下,我们着重关注第二种情形,即攻击者能够通过篡改一个环境变量或预先在搜索路径中输入可执行的恶意内容,进而更改命令所代表的原始含义。这种形式的 Command Injection 漏洞在以下情况下发生:

1.攻击者修改应用程序的环境。

2.应用程序在不指定绝对路径或验证正在执行二进制代码的情况下执行命令。



3.通过命令的执行,应用程序会授予攻击者一种原本不该拥有的特权或能力。

示例 1:此示例演示了攻击者更改命令解释方式时将会发生什么。以下代码来自一个基于 Web 的 CGI 实用程序,用户可以利用此实用程序更改其密码。通过 NIS 执行的密码更新过程包括在 /var/yp 目录中运行 make。请注意,由于程序更新了密码记录,因此它已按照 setuid root 安装。

程序会调用 make,如下所示:


MOVE "cd /var/yp && make &> /dev/null" to command-line
CALL "CBL_EXEC_RUN_UNIT" USING command-line
length of command-line
run-unit-id
stack-size
flags


此示例中的命令采用硬编码,因此攻击者无法控制传递到 CBL_EXEC_RUN_UNIT 的参数。然而,由于程序无法指定 make 的绝对路径,并且无法在调用命令之前擦除其环境变量,攻击者能够修改其 $PATH 变量以指向名为 make 的恶意二进制代码并通过 Shell 提示符执行 CGI 脚本。此外,由于程序已安装 setuid root,因此攻击者版本的 make 现在以 root 权限运行。

示例 2:以下代码使用环境变量确定包含要通过 pdfprint 命令打印的文件的临时目录。


DISPLAY "TEMP" UPON ENVIRONMENT-NAME
ACCEPT ws-temp-dir FROM ENVIRONMENT-VARIABLE
STRING "pdfprint " DELIMITED SIZE
ws-temp-dir DELIMITED SPACE
"/" DELIMITED SIZE
ws-pdf-filename DELIMITED SPACE
x"00" DELIMITED SIZE
INTO cmd-buffer
CALL "SYSTEM" USING cmd-buffer


与之前的示例类似,该命令采用硬编码。然而由于程序无法指定 pdfprint 的绝对路径,因此攻击者能够修改其指向恶意二进制代码的 $PATH 变量。此外,尽管 DELIMITED SPACE 短语能够阻止 ws-temp-dirws-pdf-filename 中的嵌入空间,仍然可能有 Shell 元字符(例如 &&)嵌入在这两者之一。
desc.semantic.cobol.command_injection
Abstract
执行不可信赖资源中的命令,或在不可信赖的环境中执行命令,都会导致程序以攻击者的名义执行恶意命令。
Explanation
Command Injection 漏洞主要表现为以下两种形式:

- 攻击者能够篡改程序执行的命令:攻击者直接控制了所执行的命令。

- 攻击者能够篡改命令的执行环境:攻击者间接地控制了所执行的命令。

在这种情况下,我们着重关注第一种情况,即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现:

1. 数据从不可信赖的数据源进入应用程序。

2. 数据被用作代表应用程序所执行命令的字符串,或字符串的一部分。

3. 通过命令的执行,应用程序会授予攻击者一种原本不该拥有的特权或能力。

例 1:攻击者可以利用下列代码通过 cmd 请求参数指定任意指令。


...
<cfset var="#url.cmd#">
<cfexecute name = "C:\windows\System32\cmd.exe"
arguments = "/c #var#"
timeout = "1"
variable="mycmd">
</cfexecute>
...
desc.dataflow.cfml.command_injection
Abstract
执行不可信赖资源中的命令,或在不可信赖的环境中执行命令,都会导致程序以攻击者的名义执行恶意命令。
Explanation
Command Injection 漏洞主要表现为以下两种形式:

- 攻击者能够篡改程序执行的命令:攻击者直接控制命令。

- 攻击者能够篡改命令的执行环境:攻击者间接地控制了所执行的命令。

在这种情况下,我们着重关注第一种情况,即攻击者控制所执行命令的可能性。这种形式的 Command Injection 漏洞在以下情况下发生:

1.数据从不可信赖的数据源进入应用程序。

2.数据作为代表应用程序所执行命令的一个字符串或部分字符串使用。

3.通过命令的执行,应用程序会授予攻击者一种原本不该拥有的特权或能力。

示例 1:系统实用程序中的以下代码使用系统属性 APPHOME 来确定其安装目录,然后根据指定目录的相对路径执行初始化脚本。


...
final cmd = String.fromEnvironment('APPHOME');
await Process.run(cmd);
...
Example 1 中的代码可以使攻击者通过修改系统属性 APPHOME 以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限,继而随心所欲地执行命令。由于程序不会验证从环境中读取的值,因此如果攻击者能够控制系统属性 APPHOME 的值,他们就能欺骗应用程序去运行恶意代码,从而取得系统控制权。
desc.dataflow.dart.command_injection
Abstract
执行不可信赖资源中的命令,或在不可信赖的环境中执行命令,都会导致程序以攻击者的名义执行恶意命令。
Explanation
Command Injection 漏洞主要表现为以下两种形式:

- 攻击者能够篡改程序执行的命令:攻击者直接控制命令。

- 攻击者能够篡改命令的执行环境:攻击者间接地控制了所执行的命令。

在这种情况下,我们着重关注第一种情况,即攻击者控制命令的可能性。这种形式的 Command Injection 漏洞在以下情况下发生:

1.数据从不可信赖的数据源进入应用程序。


2.数据作为代表应用程序所执行命令的一个字符串或部分字符串使用。

3.通过命令的执行,应用程序会授予攻击者一种原本不该拥有的特权或能力。

示例:以下代码会运行用户控制的命令。


cmdName := request.FormValue("Command")
c := exec.Command(cmdName)
c.Run()
desc.dataflow.golang.command_injection
Abstract
执行不可信赖资源中的命令,或在不可信赖的环境中执行命令,都会导致程序以攻击者的名义执行恶意命令。
Explanation
Command Injection 漏洞主要表现为以下两种形式:

- 攻击者能够篡改程序执行的命令:攻击者直接控制了所执行的命令。

- 攻击者能够篡改命令的执行环境:攻击者间接地控制了所执行的命令。

在这种情况下,我们着重关注第一种情况,即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现:

1. 数据从不可信赖的数据源进入应用程序。

2. 数据被用作代表应用程序所执行命令的字符串,或字符串的一部分。

3. 通过命令的执行,应用程序会授予攻击者一种原本不该拥有的特权或能力。

例 1:下面这段来自系统实用程序的代码根据系统属性 APPHOME 来决定其安装目录,然后根据指定目录的相对路径执行一个初始化脚本。


...
String home = System.getProperty("APPHOME");
String cmd = home + INITCMD;
java.lang.Runtime.getRuntime().exec(cmd);
...
Example 1 中的代码可以使攻击者通过修改系统属性 APPHOME 以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限,继而随心所欲地执行命令。由于程序不会验证从环境中读取的值,因此如果攻击者能够控制系统属性 APPHOME 的值,他们就能欺骗应用程序去运行恶意代码,从而取得系统控制权。

例 2:下面的代码来自一个管理 Web 应用程序,旨在使用户能够使用一个围绕 rman 实用程序的批处理文件封装器来启动 Oracle 数据库备份,然后运行一个 cleanup.bat 脚本来删除一些临时文件。脚本 rmanDB.bat 接受单个命令行参数,该参数指定了要执行的备份类型。由于访问数据库受限,所以应用程序执行备份需要具有较高权限的用户。


...
String btype = request.getParameter("backuptype");
String cmd = new String("cmd.exe /K
\"c:\\util\\rmanDB.bat "+btype+"&&c:\\util\\cleanup.bat\"")
System.Runtime.getRuntime().exec(cmd);
...


这里的问题是:程序没有对读取自用户的 backuptype参数进行任何验证。通常情况下 Runtime.exec() 函数不会执行多条命令,但在这种情况下,程序会首先运行 cmd.exe shell,从而可以通过调用一次 Runtime.exec() 来执行多条命令。在调用该 shell 之后,它即会允许执行用两个与号分隔的多条命令。如果攻击者传递了一个形式为 "&& del c:\\dbms\\*.*" 的字符串,那么应用程序将随程序指定的其他命令一起执行此命令。由于该应用程序的特性,运行该应用程序需要具备与数据库进行交互所需的权限,这就意味着攻击者注入的任何命令都将通过这些权限得以运行。

示例 3:下面的代码来自一个 Web 应用程序,用户可通过该应用程序提供的界面在系统上更新他们的密码。在某些网络环境中更新密码时,其中的一个步骤就是在 /var/yp 目录中运行 make 命令。


...
System.Runtime.getRuntime().exec("make");
...


这里的问题在于程序没有在它的构造中指定一个绝对路径,并且没能在执行 Runtime.exec() 调用前清除它的环境变量。如果攻击者能够修改 $PATH 变量,把它指向名为 make 恶意二进制代码,程序就会在其指定的环境下执行,然后加载该恶意二进制代码,而非原本期望的代码。由于应用程序自身的特性,运行该应用程序需要具备执行系统操作所需的权限,这意味着攻击者会利用这些权限执行自己的 make,从而可能导致攻击者完全控制系统。

有些人认为在移动世界中,典型的漏洞(如 Command Injection)是无意义的 -- 为什么用户要攻击自己?但是,谨记移动平台的本质是从各种来源下载并在相同设备上运行的应用程序。恶意软件在银行应用程序附近运行的可能性很高,它们会强制扩展移动应用程序的攻击面(包括跨进程通信)。

例 4:以下代码可从 Android Intent 中读取要执行的命令。


...
String[] cmds = this.getIntent().getStringArrayExtra("commands");
Process p = Runtime.getRuntime().exec("su");
DataOutputStream os = new DataOutputStream(p.getOutputStream());
for (String cmd : cmds) {
os.writeBytes(cmd+"\n");
}
os.writeBytes("exit\n");
os.flush();
...


在经过 root 的设备上,恶意应用程序会强迫受攻击应用程序使用超级用户权限执行任意命令。
References
[1] IDS07-J. Sanitize untrusted data passed to the Runtime.exec() method CERT
desc.dataflow.java.command_injection
Abstract
执行不可信赖资源中的命令,或在不可信赖的环境中执行命令,都会导致程序以攻击者的名义执行恶意命令。
Explanation
Command Injection 漏洞主要表现为以下两种形式:

- 攻击者能够篡改程序执行的命令:攻击者直接控制了所执行的命令。

- 攻击者能够篡改命令的执行环境:攻击者间接地控制了所执行的命令。

在这种情况下,我们着重关注第一种情况,即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现:

1. 数据从不可信赖的数据源进入应用程序。


2. 数据被用作代表应用程序所执行命令的字符串,或字符串的一部分。

3. 通过命令的执行,应用程序会授予攻击者一种原本不该拥有的特权或能力。

示例 1:以下来自系统实用程序的代码根据环境变量 APPHOME 来决定其安装目录,然后根据指定目录的相对路径来执行初始化脚本。


var cp = require('child_process');
...
var home = process.env('APPHOME');
var cmd = home + INITCMD;
child = cp.exec(cmd, function(error, stdout, stderr){
...
});
...
Example 1 中的代码可以使攻击者通过修改系统属性 APPHOME 以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限,继而随心所欲地执行命令。由于程序不会验证从环境中读取的值,因此如果攻击者能够控制系统属性 APPHOME 的值,他们就能欺骗应用程序去运行恶意代码,从而取得系统控制权。

示例 2:下面的代码来自一个管理 Web 应用程序,旨在使用户能够使用一个围绕 rman 实用程序的批处理文件封装器来启动 Oracle 数据库备份。脚本 rmanDB.bat 接受单个命令行参数,该参数指定了要执行的备份类型。由于访问数据库受限,所以应用程序执行备份需要具有较高权限的用户。


var cp = require('child_process');
var http = require('http');
var url = require('url');

function listener(request, response){
var btype = url.parse(request.url, true)['query']['backuptype'];
if (btype !== undefined){
cmd = "c:\\util\\rmanDB.bat" + btype;
cp.exec(cmd, function(error, stdout, stderr){
...
});
}
...
}
...
http.createServer(listener).listen(8080);


这里的问题是:程序除了验证读取自用户的 backuptype参数是否存在之外,没有对其进行任何验证。在调用该 shell 之后,就可能允许执行多个命令,并且由于该应用程序的特性,该应用程序将会使用与数据库进行交互的必要权限来运行,这就意味着攻击者注入的任何命令都会通过这些权限来运行。

示例 3:下面的代码来自一个 Web 应用程序,用户可通过该应用程序提供的界面在系统上更新他们的密码。在某些网络环境中更新密码时,其中的一个步骤就是在 /var/yp 目录中运行 make 命令。


...
require('child_process').exec("make", function(error, stdout, stderr){
...
});
...


这里的问题在于,程序没有指定 make 的绝对路径,因此没能在执行 child_process.exec() 调用前清理其环境。如果攻击者能够修改 $PATH 变量,把它指向名为 make 恶意二进制代码,程序就会在其指定的环境下执行,然后加载该恶意二进制代码,而非原本期望的代码。由于应用程序自身的特性,运行该应用程序需要具备执行系统操作所需的权限,这意味着攻击者会利用这些权限执行自己的 make,从而可能导致攻击者完全控制系统。
desc.dataflow.javascript.command_injection
Abstract
执行不可信赖资源中的命令,或在不可信赖的环境中执行命令,都会导致程序以攻击者的名义执行恶意命令。
Explanation
Command Injection 漏洞主要表现为以下两种形式:

- 攻击者能够篡改程序执行的命令:攻击者直接控制了所执行的命令。

- 攻击者能够篡改命令的执行环境:攻击者间接地控制了所执行的命令。

在这种情况下,我们着重关注第一种情况,即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现:

1. 数据从不可信赖的数据源进入应用程序。

2. 数据被用作代表应用程序所执行命令的字符串,或字符串的一部分。

3. 通过命令的执行,应用程序会授予攻击者一种原本不该拥有的特权或能力。

例 1:下面这段来自系统实用程序的代码根据系统属性 APPHOME 来决定其安装目录,然后根据指定目录的相对路径执行一个初始化脚本。


...
$home = $_ENV['APPHOME'];
$cmd = $home . $INITCMD;
system(cmd);
...
Example 1 中的代码可以使攻击者通过修改系统属性 APPHOME 以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限,继而随心所欲地执行命令。由于程序不会验证从环境中读取的值,因此如果攻击者能够控制系统属性 APPHOME 的值,他们就能欺骗应用程序去运行恶意代码,从而取得系统控制权。

例 2:下面的代码来自一个管理 Web 应用程序,旨在使用户能够使用一个围绕 rman 实用程序的批处理文件封装器来启动 Oracle 数据库备份,然后运行一个 cleanup.bat 脚本来删除一些临时文件。脚本 rmanDB.bat 接受单个命令行参数,该参数指定了要执行的备份类型。由于访问数据库受限,所以应用程序执行备份需要具有较高权限的用户。


...
$btype = $_GET['backuptype'];
$cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat " . $btype . "&&c:\\util\\cleanup.bat\"";
system(cmd);
...


这里的问题是:程序没有对读取自用户的 backuptype参数进行任何验证。通常情况下 Runtime.exec() 函数不会执行多条命令,但在这种情况下,程序会首先运行 cmd.exe shell,从而可以通过调用一次 Runtime.exec() 来执行多条命令。在调用该 shell 之后,它即会允许执行用两个与号分隔的多条命令。如果攻击者传递了一个形式为 "&& del c:\\dbms\\*.*" 的字符串,那么应用程序将随程序指定的其他命令一起执行此命令。由于该应用程序的特性,运行该应用程序需要具备与数据库进行交互所需的权限,这就意味着攻击者注入的任何命令都将通过这些权限得以运行。

示例 3:下面的代码来自一个 Web 应用程序,用户可通过该应用程序提供的界面在系统上更新他们的密码。在某些网络环境中更新密码时,其中的一个步骤就是在 /var/yp 目录中运行 make 命令。


...
$result = shell_exec("make");
...


这里的问题在于程序没有在它的构造中指定一个绝对路径,并且没能在执行 Runtime.exec() 调用前清除它的环境变量。如果攻击者能够修改 $PATH 变量,把它指向名为 make 恶意二进制代码,程序就会在其指定的环境下执行,然后加载该恶意二进制代码,而非原本期望的代码。由于应用程序自身的特性,运行该应用程序需要具备执行系统操作所需的权限,这意味着攻击者会利用这些权限执行自己的 make,从而可能导致攻击者完全控制系统。
desc.dataflow.php.command_injection
Abstract
执行不可信赖资源中的命令,或在不可信赖的环境中执行命令,都会导致程序以攻击者的名义执行恶意命令。
Explanation
Command Injection 漏洞主要表现为以下两种形式:

- 攻击者能够篡改程序执行的命令:攻击者直接控制了所执行的命令。

- 攻击者能够篡改命令的执行环境:攻击者间接地控制了所执行的命令。

在这种情况下,我们着重关注第一种情况,即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现:

1. 数据从不可信赖的数据源进入应用程序。

2. 数据被用作代表应用程序所执行命令的字符串,或字符串的一部分。

3. 通过命令的执行,应用程序会授予攻击者一种原本不该拥有的特权或能力。

示例:以下代码定义了一个 T-SQL 存储过程,当使用不可信的数据调用该过程时,将执行攻击者控制的系统命令。


...
CREATE PROCEDURE dbo.listFiles (@path NVARCHAR(200))
AS

DECLARE @cmd NVARCHAR(500)
SET @cmd = 'dir ' + @path

exec xp_cmdshell @cmd

GO
...
References
[1] xp_cmdshell
desc.dataflow.sql.command_injection
Abstract
执行不可信赖资源中的命令,或在不可信赖的环境中执行命令,都会导致程序以攻击者的名义执行恶意命令。
Explanation
Command Injection 漏洞主要表现为以下两种形式:

- 攻击者能够篡改程序执行的命令:攻击者直接控制了所执行的命令。

- 攻击者能够篡改命令的执行环境:攻击者间接地控制了所执行的命令。

在这种情况下,我们着重关注第一种情况,即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现:

1. 数据从不可信赖的数据源进入应用程序。

2. 数据被用作代表应用程序所执行命令的字符串,或字符串的一部分。

3. 通过命令的执行,应用程序会授予攻击者一种原本不该拥有的特权或能力。

例 1:下面这段来自系统实用程序的代码根据系统属性 APPHOME 来决定其安装目录,然后根据指定目录的相对路径执行一个初始化脚本。


...
home = os.getenv('APPHOME')
cmd = home.join(INITCMD)
os.system(cmd);
...
Example 1 中的代码可以使攻击者通过修改系统属性 APPHOME 以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限,继而随心所欲地执行命令。由于程序不会验证从环境中读取的值,因此如果攻击者能够控制系统属性 APPHOME 的值,他们就能欺骗应用程序去运行恶意代码,从而取得系统控制权。

例 2:下面的代码来自一个管理 Web 应用程序,旨在使用户能够使用一个围绕 rman 实用程序的批处理文件封装器来启动 Oracle 数据库备份,然后运行一个 cleanup.bat 脚本来删除一些临时文件。脚本 rmanDB.bat 接受单个命令行参数,该参数指定了要执行的备份类型。由于访问数据库受限,所以应用程序执行备份需要具有较高权限的用户。


...
btype = req.field('backuptype')
cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat " + btype + "&&c:\\util\\cleanup.bat\""
os.system(cmd);
...


这里的问题是:程序没有对读取自用户的 backuptype参数进行任何验证。通常情况下 Runtime.exec() 函数不会执行多条命令,但在这种情况下,程序会首先运行 cmd.exe shell,从而可以通过调用一次 Runtime.exec() 来执行多条命令。在调用该 shell 之后,它即会允许执行用两个与号分隔的多条命令。如果攻击者传递了一个形式为 "&& del c:\\dbms\\*.*" 的字符串,那么应用程序将随程序指定的其他命令一起执行此命令。由于该应用程序的特性,运行该应用程序需要具备与数据库进行交互所需的权限,这就意味着攻击者注入的任何命令都将通过这些权限得以运行。

示例 3:下面的代码来自一个 Web 应用程序,用户可通过该应用程序提供的界面在系统上更新他们的密码。在某些网络环境中更新密码时,其中的一个步骤就是在 /var/yp 目录中运行 make 命令。


...
result = os.system("make");
...


这里的问题在于程序没有在它的构造中指定一个绝对路径,并且没能在执行 os.system() 调用前清除它的环境变量。如果攻击者能够修改 $PATH 变量,把它指向名为 make 恶意二进制代码,程序就会在其指定的环境下执行,然后加载该恶意二进制代码,而非原本期望的代码。由于应用程序自身的特性,运行该应用程序需要具备执行系统操作所需的权限,这意味着攻击者会利用这些权限执行自己的 make,从而可能导致攻击者完全控制系统。
desc.dataflow.python.command_injection
Abstract
执行不可信赖资源中的命令,或在不可信赖的环境中执行命令,都会导致程序以攻击者的名义执行恶意命令。
Explanation
Command Injection 漏洞主要表现为以下两种形式:

- 攻击者能够篡改程序执行的命令:攻击者直接控制了所执行的命令。

- 攻击者能够篡改命令的执行环境:攻击者间接地控制了所执行的命令。

在这种情况下,我们着重关注第一种情况,即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现:

1. 数据从不可信赖的数据源进入应用程序。


2. 数据被用作代表应用程序所执行命令的字符串,或字符串的一部分。

3. 通过命令的执行,应用程序会授予攻击者一种原本不该拥有的特权或能力。

例 1:下面这段来自系统实用程序的代码根据系统属性 APPHOME 来决定其安装目录,然后根据指定目录的相对路径执行一个初始化脚本。


...
home = ENV['APPHOME']
cmd = home + INITCMD
Process.spawn(cmd)
...
Example 1 中的代码可以使攻击者通过修改系统属性 APPHOME 以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限,继而随心所欲地执行命令。由于程序不会验证从环境中读取的值,因此如果攻击者能够控制系统属性 APPHOME 的值,他们就能欺骗应用程序去运行恶意代码,从而取得系统控制权。

例 2:下面的代码来自一个管理 Web 应用程序,旨在使用户能够使用一个围绕 rman 实用程序的批处理文件封装器来启动 Oracle 数据库备份,然后运行一个 cleanup.bat 脚本来删除一些临时文件。脚本 rmanDB.bat 接受单个命令行参数,该参数指定了要执行的备份类型。由于访问数据库受限,所以应用程序执行备份需要具有较高权限的用户。


...
btype = req['backuptype']
cmd = "C:\\util\\rmanDB.bat #{btype} &&C:\\util\\cleanup.bat"
spawn(cmd)
...


这里的问题是:程序没有对读取自用户的 backuptype参数进行任何验证。在通过 Kernel.spawn 调用该 shell 之后,它即会允许执行用两个与号分隔的多条命令。如果攻击者传递了一个形式为 "&& del c:\\dbms\\*.*" 的字符串,那么应用程序将随程序指定的其他命令一起执行此命令。由于该应用程序的特性,运行该应用程序需要具备与数据库进行交互所需的权限,这就意味着攻击者注入的任何命令都将通过这些权限得以运行。

示例 3:下面的代码来自一个 Web 应用程序,用户可通过该应用程序提供的界面在系统上更新他们的密码。在某些网络环境中更新密码时,其中的一个步骤就是在 /var/yp 目录中运行 make 命令。


...
system("make")
...


这里的问题在于程序没有在它的构造中指定一个绝对路径,并且没能在执行 Kernel.system() 调用前清除它的环境变量。如果攻击者能够修改 $PATH 变量,把它指向名为 make 恶意二进制代码,程序就会在其指定的环境下执行,然后加载该恶意二进制代码,而非原本期望的代码。由于应用程序自身的特性,运行该应用程序需要具备执行系统操作所需的权限,这意味着攻击者会利用这些权限执行自己的 make,从而可能导致攻击者完全控制系统。
desc.dataflow.ruby.command_injection
Abstract
执行包含无效用户输入的命令,会导致应用程序以攻击者的名义执行恶意命令。
Explanation
Command Injection 漏洞主要表现为以下两种形式:

- 攻击者能够篡改程序执行的命令:攻击者直接控制了所执行的命令。

- 攻击者能够篡改命令的执行环境:攻击者间接地控制了所执行的命令。

在这种情况下,我们着重关注第二种情况,即攻击者有可能通过篡改一个环境变量或预先在搜索路径中输入可执行的恶意内容,进而更改命令所代表的原始含义。这种类型的 Command Injection 漏洞会在以下情况下出现:

1.攻击者篡改某一应用程序的环境。

2.应用程序在没有指明绝对路径,或者没有检验所执行的二进制代码的情况下就执行命令。

3.通过命令的执行,应用程序会授予攻击者一种原本不该拥有的特权或能力。

示例:下面的代码来自一个 Web 应用程序,用户可通过该应用程序提供的界面在系统上更新他们的密码。


def changePassword(username: String, password: String) = Action { request =>
...
s'echo "${password}" | passwd ${username} --stdin'.!
...
}
References
[1] IDS07-J. Sanitize untrusted data passed to the Runtime.exec() method CERT
desc.dataflow.scala.command_injection
Abstract
执行不可信赖资源中的命令,或在不可信赖的环境中执行命令,都会导致程序以攻击者的名义执行恶意命令。
Explanation
Command Injection 漏洞主要表现为以下两种形式:

- 攻击者能够篡改程序执行的命令:攻击者直接控制了所执行的命令。

- 攻击者能够篡改命令的执行环境:攻击者间接地控制了所执行的命令。

在这种情况下,我们着重关注第一种情况,即攻击者有可能控制所执行命令。这种类型的 Command Injection 漏洞会在以下情况下出现:

1. 数据从不可信赖的数据源进入应用程序。

2. 数据被用作代表应用程序所执行命令的字符串,或字符串的一部分。

3. 通过命令的执行,应用程序会授予攻击者一种原本不该拥有的特权或能力。

例 1:下面这段来自系统实用程序的代码根据系统属性 APPHOME 来决定其安装目录,然后根据指定目录的相对路径执行一个初始化脚本。


...
Dim cmd
Dim home

home = Environ$("AppHome")
cmd = home & initCmd
Shell cmd, vbNormalFocus
...
Example 1 中的代码可以使攻击者通过修改系统属性 APPHOME 以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限,继而随心所欲地执行命令。由于程序不会验证从环境中读取的值,因此如果攻击者能够控制系统属性 APPHOME 的值,他们就能欺骗应用程序去运行恶意代码,从而取得系统控制权。

例 2:下面的代码来自一个管理 Web 应用程序,旨在使用户能够使用一个围绕 rman 实用程序的批处理文件封装器来启动 Oracle 数据库备份,然后运行一个 cleanup.bat 脚本来删除一些临时文件。脚本 rmanDB.bat 接受单个命令行参数,该参数指定了要执行的备份类型。由于访问数据库受限,所以应用程序执行备份需要具有较高权限的用户。


...
btype = Request.Form("backuptype")
cmd = "cmd.exe /K " & Chr(34) & "c:\util\rmanDB.bat " & btype & "&&c:\util\cleanup.bat" & Chr(34) & ";
Shell cmd, vbNormalFocus
...


这里的问题是:程序没有对读取自用户的 backuptype参数进行任何验证。在调用该 shell 之后,它即会允许执行用两个与号分隔的多条命令。如果攻击者传递了一个形式为 "&& del c:\\dbms\\*.*" 的字符串,那么应用程序将随程序指定的其他命令一起执行此命令。由于该应用程序的特性,运行该应用程序需要具备与数据库进行交互所需的权限,这就意味着攻击者注入的任何命令都将通过这些权限得以运行。

示例 3:下面的代码来自一个 Web 应用程序,用户可通过该应用程序提供的界面在系统上更新他们的密码。在某些网络环境中更新密码时,其中的一个步骤就是在 /var/yp 目录中运行 make 命令。


...
$result = shell_exec("make");
...


这里的问题在于程序没有在它的构造中指定一个绝对路径,并且没能在执行 Runtime.exec() 调用前清除它的环境变量。如果攻击者能够修改 $PATH 变量,把它指向名为 make 恶意二进制代码,程序就会在其指定的环境下执行,然后加载该恶意二进制代码,而非原本期望的代码。由于应用程序自身的特性,运行该应用程序需要具备执行系统操作所需的权限,这意味着攻击者会利用这些权限执行自己的 make,从而可能导致攻击者完全控制系统。
desc.dataflow.vb.command_injection
Abstract
直接引用 GitHub Actions 运行脚本中的特定 GitHub Action 表达式会使系统容易受到 Command Injection 的攻击。
Explanation
对运行脚本中 GitHub Action 表达式的直接引用是动态生成的。这使得任何能够控制输入的人都可以通过使用 Command Injection 来破坏系统。

示例 1:以下 GitHub Action 代码直接引用了运行脚本中的表达式,这会使系统面临 Command Injection 风险。


...
steps:
- run: echo "${{ github.event.pull_request.title }}"
...


运行操作时,会动态执行 shell 脚本,包括 github.event.pull_request.title 值表示的任何代码。如果 github.event.pull_request.title 包含恶意可执行代码,会导致该操作运行恶意代码,从而导致 Command Injection 攻击。

References
[1] Security Hardening for GitHub Actions - Good Practices for Mitigating Script Injection Attacks
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark complete
[8] Standards Mapping - Common Weakness Enumeration CWE ID 77, CWE ID 78
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [11] CWE ID 078
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [10] CWE ID 078
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [5] CWE ID 078, [25] CWE ID 077
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[13] Standards Mapping - FIPS200 SI
[14] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[15] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[16] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[19] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[21] Standards Mapping - OWASP Top 10 2010 A1 Injection
[22] Standards Mapping - OWASP Top 10 2013 A1 Injection
[23] Standards Mapping - OWASP Top 10 2017 A1 Injection
[24] Standards Mapping - OWASP Top 10 2021 A03 Injection
[25] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.2 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.3 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.5 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.8 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.8 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 10.3.2 Deployed Application Integrity Controls (L1 L2 L3), 12.3.2 File Execution Requirements (L1 L2 L3), 12.3.5 File Execution Requirements (L1 L2 L3)
[26] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[27] Standards Mapping - OWASP Mobile 2024 M2 Inadequate Supply Chain Security
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[39] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 078
[40] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 078
[41] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 078
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[63] Standards Mapping - Web Application Security Consortium Version 2.00 OS Commanding (WASC-31)
[64] Standards Mapping - Web Application Security Consortium 24 + 2 OS Commanding
desc.structural.yaml.command_injection_github_actions