160 个项目已找到
弱点
Abstract
允许用户输入以直接更改文件权限可能导致攻击者能够访问以其他方式保护的系统资源。
Explanation
当满足以下任一条件时,就会发生 File Permission Manipulation 错误:

1.攻击者可能会指定操作中所用的路径,以修改文件系统上的权限。

2.攻击者可能会指定文件系统上的操作所分配的权限。

示例 1:以下代码使用系统环境变量中的输入设置文件权限。如果攻击者可更改系统环境变量,则他们可能会使用该程序获得程序所处理文件的访问权限。如果程序依然易受 Path Manipulation 的攻击,那么攻击者可能会利用这一漏洞来访问系统中的任意文件。


permissions := strconv.Atoi(os.Getenv("filePermissions"));
fMode := os.FileMode(permissions)
os.chmod(filePath, fMode);
...
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark complete
[8] Standards Mapping - Common Weakness Enumeration CWE ID 264, CWE ID 732
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[13] Standards Mapping - FIPS200 AC
[14] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[17] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[18] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[19] Standards Mapping - OWASP Application Security Verification Standard 4.0 4.1.3 General Access Control Design (L1 L2 L3), 4.1.5 General Access Control Design (L1 L2 L3), 4.2.1 Operation Level Access Control (L1 L2 L3), 4.3.3 Other Access Control Considerations (L2 L3), 7.3.3 Log Protection Requirements (L2 L3)
[20] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[21] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[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, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[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 5.4 - Authentication and Access Control
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.golang.file_permission_manipulation
Abstract
允许用户输入以直接更改文件权限可能导致攻击者能够访问以其他方式保护的系统资源。
Explanation
当满足以下任一条件时,就会产生 file permission manipulation 错误:

1. 攻击者能够指定在 file system 中修改权限的操作所使用的路径。

2. 攻击者能够指定 file system 上的操作所分配的权限。

示例 1:以下代码使用来自系统属性的输入来设置默认权限掩码。如果攻击者更改了系统属性,则他们可以使用该程序获得该程序所处理文件的访问权限。如果程序还容易受路径篡改攻击,那么攻击者可能会利用这一漏洞访问系统中的任意文件。


String permissionMask = System.getProperty("defaultFileMask");
Path filePath = userFile.toPath();
...
Set<PosixFilePermission> perms = PosixFilePermissions.fromString(permissionMask);
Files.setPosixFilePermissions(filePath, perms);
...
References
[1] FIO01-J. Create files with appropriate access permissions CERT
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark complete
[9] Standards Mapping - Common Weakness Enumeration CWE ID 264, CWE ID 732
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[14] Standards Mapping - FIPS200 AC
[15] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[18] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[19] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 4.1.3 General Access Control Design (L1 L2 L3), 4.1.5 General Access Control Design (L1 L2 L3), 4.2.1 Operation Level Access Control (L1 L2 L3), 4.3.3 Other Access Control Considerations (L2 L3), 7.3.3 Log Protection Requirements (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[36] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[37] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[38] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[39] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[53] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.file_permission_manipulation
Abstract
允许用户输入以直接更改文件权限可能导致攻击者能够访问以其他方式保护的系统资源。
Explanation
当满足以下任一条件时,就会产生 file permission manipulation 错误:

1. 攻击者能够指定在 file system 中修改权限的操作所使用的路径。

2. 攻击者能够指定 file system 上的操作所分配的权限。

示例:以下代码旨在为用户设置适当的文件权限以通过 FTP 上载网页。它使用来自 HTTP 请求的输入将文件标记为外部用户可查看的文件。


$rName = $_GET['publicReport'];
chmod("/home/". authenticateUser . "/public_html/" . rName,"0755");
...


但是,如果攻击者为 publicReport 提供恶意值(例如,../../localuser/public_html/.htpasswd),那么应用程序将允许攻击者读取指定文件。

示例 2:以下代码使用来自配置文件的输入来设置默认权限掩码。如果攻击者可以篡改配置文件,则他们可以使用该程序获得该程序所处理文件的访问权限。如果程序还容易受路径篡改攻击,那么攻击者可能会利用这一漏洞访问系统中的任意文件。


...
$mask = $CONFIG_TXT['perms'];
chmod($filename,$mask);
...
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark complete
[9] Standards Mapping - Common Weakness Enumeration CWE ID 264, CWE ID 732
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[14] Standards Mapping - FIPS200 AC
[15] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[18] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[19] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 4.1.3 General Access Control Design (L1 L2 L3), 4.1.5 General Access Control Design (L1 L2 L3), 4.2.1 Operation Level Access Control (L1 L2 L3), 4.3.3 Other Access Control Considerations (L2 L3), 7.3.3 Log Protection Requirements (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[36] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[37] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[38] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[39] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[53] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.php.file_permission_manipulation
Abstract
允许用户输入以直接更改文件权限可能导致攻击者能够访问以其他方式保护的系统资源。
Explanation
当满足以下任一条件时,就会产生 File Permission Manipulation 错误:

1. 攻击者能够指定在文件系统上修改权限的操作所使用的路径。

2. 攻击者能够指定文件系统上的操作所分配的权限。

示例 1: 以下代码使用系统环境变量中的输入设置文件权限。 如果攻击者可更改系统环境变量,则他们可能使用该程序获得程序所处理文件的访问权限。 如果程序还容易受 Path Manipulation 攻击,那么攻击者可能会利用这一漏洞访问系统中的任意文件。


permissions = os.getenv("filePermissions");
os.chmod(filePath, permissions);
...
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark complete
[8] Standards Mapping - Common Weakness Enumeration CWE ID 264, CWE ID 732
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[13] Standards Mapping - FIPS200 AC
[14] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[17] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[18] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[19] Standards Mapping - OWASP Application Security Verification Standard 4.0 4.1.3 General Access Control Design (L1 L2 L3), 4.1.5 General Access Control Design (L1 L2 L3), 4.2.1 Operation Level Access Control (L1 L2 L3), 4.3.3 Other Access Control Considerations (L2 L3), 7.3.3 Log Protection Requirements (L2 L3)
[20] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[21] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[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, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[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 5.4 - Authentication and Access Control
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.python.file_permission_manipulation
Abstract
允许用户输入以直接更改文件权限可能导致攻击者能够访问以其他方式保护的系统资源。
Explanation
当满足以下任一条件时,就会产生 file permission manipulation 错误:

1. 攻击者能够指定在 file system 中修改权限的操作所使用的路径。

2. 攻击者能够指定 file system 上的操作所分配的权限。

示例:以下代码旨在为用户设置适当的文件权限以通过 FTP 上载网页。它使用来自 HTTP 请求的输入将文件标记为外部用户可查看的文件。


...
rName = req['publicReport']
File.chmod("/home/#{authenticatedUser}/public_html/#{rName}", "0755")
...


但是,如果攻击者为 publicReport 提供恶意值(例如,../../localuser/public_html/.htpasswd),那么应用程序将允许攻击者读取指定文件。

示例 2:以下代码使用来自配置文件的输入来设置默认权限掩码。如果攻击者可以篡改配置文件,则他们可以使用该程序获得该程序所处理文件的访问权限。如果程序还容易受路径篡改攻击,那么攻击者可能会利用这一漏洞访问系统中的任意文件。


...
mask = config_params['perms']
File.chmod(filename, mask)
...
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark complete
[9] Standards Mapping - Common Weakness Enumeration CWE ID 264, CWE ID 732
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[14] Standards Mapping - FIPS200 AC
[15] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[18] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[19] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 4.1.3 General Access Control Design (L1 L2 L3), 4.1.5 General Access Control Design (L1 L2 L3), 4.2.1 Operation Level Access Control (L1 L2 L3), 4.3.3 Other Access Control Considerations (L2 L3), 7.3.3 Log Protection Requirements (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[36] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[37] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[38] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[39] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[53] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.ruby.file_permission_manipulation
Abstract
程序会定义过于宽松的跨域策略。
Explanation
默认情况下,Flash 应用程序需要遵循 Same Origin Policy(同源策略),该策略可确保来自同一个域的两个 SWF 应用程序能够访问彼此的数据。Adobe Flash 允许开发人员通过编程或 crossdomain.xml 配置文件中的相应设置来更改该策略。不过,更改此设置时应小心谨慎,如果跨域策略过于宽松,恶意应用程序就能趁机采用不当方式与受害者应用程序进行通信,从而导致发生欺骗、数据被盗、转发及其他攻击。

示例 1:以下摘录的代码示例使用通配符以编程方式指定允许与应用程序通信的域。


flash.system.Security.allowDomain("*");


* 作为 allowDomain() 的参数表明该应用程序的数据可供来自任何域的其他 SWF 应用程序访问。
References
[1] Peleus Uhley Creating more secure SWF web applications
[2] Matt Wood and Prajakta Jagdale Auditing Adobe Flash through Static Analysis
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 942
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[15] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.6 HTTP Security Headers Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[28] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.semantic.actionscript.flash_misconfiguration_overly_permissive_cross_domain_policy
Abstract
程序定义了一个过于宽松的自定义标头策略。
Explanation
默认情况下,Flash 应用程序需要遵循 Same Origin Policy(同源策略),该策略可确保来自同一个域的两个 SWF 应用程序能够访问彼此的数据。Adobe Flash 允许开发人员通过编程或 crossdomain.xml 配置文件中的相应设置来更改该策略。从 Flash Player 9,0,124,0 开始,Adobe 还引入了定义 Flash Player 可以跨域发送的自定义标头的功能。但是,在定义这些设置时应小心谨慎,因为当过于宽松的自定义标头策略与过于宽松的跨域策略一起应用时,将允许恶意应用程序将其选择的标头发送到目标应用程序,从而可能导致各种攻击,或导致不知道如何处理接收到的标头的应用程序在执行中出现错误。

示例 1:以下配置显示了如何使用通配符指定 Flash Player 可以跨域发送的标头。


<cross-domain-policy>
<allow-http-request-headers-from domain="*" headers="*"/>
</cross-domain-policy>


使用 * 作为 headers 属性的值表明可以跨域发送任何标头。
References
[1] Peleus Uhley Creating more secure SWF web applications
[2] Matt Wood and Prajakta Jagdale Auditing Adobe Flash through Static Analysis
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[13] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[14] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[15] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[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 5.4 - Authentication and Access Control
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[25] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.actionscript.flash_misconfiguration_overly_permissive_custom_headers_policy
Abstract
程序利用未经验证的用户输入避开预期的跨域策略限制。
Explanation
默认情况下,Flash 应用程序需要遵循 Same Origin Policy(同源策略),该策略可确保来自同一个域的两个 SWF 应用程序能够访问彼此的数据。Adobe Flash 允许开发人员通过编程或 crossdomain.xml 配置文件中的相应设置来更改该策略。不过,在确定可更改此设置的人时应小心谨慎,如果跨域策略过于宽松,恶意应用程序就能趁机采用不当方式与受害者应用程序进行通信,从而导致发生欺骗、数据被盗、转发及其他攻击。在以下情况下会发生策略限制绕过漏洞:

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

2. 数据用于加载或修改跨域策略设置。
示例 1:以下代码会将已加载的 SWF 文件中的一个参数值作为用于加载跨域策略文件的 URL。


...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var url:String = String(params["url"]);
flash.system.Security.loadPolicyFile(url);
...
示例 2:以下代码会使用已加载的 SWF 文件中的一个参数值来定义可信赖的域列表。


...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var domain:String = String(params["domain"]);
flash.system.Security.allowDomain(domain);
...
References
[1] Peleus Uhley Creating more secure SWF web applications
[2] Matt Wood and Prajakta Jagdale Auditing Adobe Flash through Static Analysis
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[14] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[24] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.actionscript.flash_misconfiguration_policy_restrictions_bypass
Abstract
程序允许 HTTP 和 HTTPS SWF 应用程序进行通信。
Explanation
从 Flash Player 7 开始,默认情况下通过 HTTP 加载的 SWF 应用程序不允许访问通过 HTTPS 加载的 SWF 应用程序的数据。Adobe Flash 允许开发者通过编程或 crossdomain.xml 配置文件中的相应设置来更改此项限制。不过,定义这些设置时应小心谨慎,因为通过 HTTP 加载的 SWF 应用程序容易受到中间人攻击,所以不应信赖此程序。

示例:以下代码会调用 allowInsecureDomain(),它会取消相关限制,从而允许通过 HTTP 加载的 SWF 应用程序访问通过 HTTPS 加载的 SWF 应用程序中的数据。


flash.system.Security.allowInsecureDomain("*");
References
[1] Peleus Uhley Creating more secure SWF web applications
[2] Matt Wood and Prajakta Jagdale Auditing Adobe Flash through Static Analysis
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[13] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[14] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[15] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.4, Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.4, Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.4, Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.4, Requirement 6.5.8
[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 5.4 - Authentication and Access Control, Control Objective 6.2 - Sensitive Data Protection
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control, Control Objective 6.2 - Sensitive Data Protection
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective 6.2 - Sensitive Data Protection, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.4.1 - Web Software Communications
[25] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 862
[26] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.semantic.actionscript.flash_misconfiguration_unauthorized_data_access
Abstract
调试信息可帮助攻击者了解系统并计划攻击形式。
Explanation
如果您使用 Blaze DS 来记录所有意外事件,services-config.xml 描述符文件会指定一个“Logging”XML 元素来描述日志记录的不同方面。它类似于以下内容:

示例:

<logging>
<target class="flex.messaging.log.ConsoleTarget" level="Debug">
<properties>
<prefix>[BlazeDS]</prefix>
<includeDate>false</includeDate>
<includeTime>false</includeTime>
<includeLevel>false</includeLevel>
<includeCategory>false</includeCategory>
</properties>
<filters>
<pattern>Endpoint.*</pattern>
<pattern>Service.*</pattern>
<pattern>Configuration</pattern>
</filters>
</target>
</logging>


target 标签可采用一个名为 level 的可选属性,用来指示日志级别。如果调试级别设置为太详细的级别,您的应用程序可能会将敏感数据写入日志文件。
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[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 complete
[6] Standards Mapping - Common Weakness Enumeration CWE ID 11
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420, CCI-003272
[8] Standards Mapping - FIPS200 CM
[9] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-11 Error Handling (P2)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-11 Error Handling
[12] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[13] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[14] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[15] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[18] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[19] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.1.3 Build (L2 L3)
[20] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3120 CAT II, APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3120 CAT II, APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3120 CAT II, APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3120 CAT II, APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3120 CAT II, APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3120 CAT II, APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3120 CAT II, APP3620 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[53] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.config.java.flex_misconfiguration_debug_information
Abstract
允许攻击者控制函数的 format string 会导致 buffer overflow。
Explanation
Format string 漏洞会在以下情况下发生:

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



2. 数据作为 format string 参数传送到某个函数,如 sprintf()FormatMessageW()syslog()
示例 1:以下代码使用 snprintf() 将一个命令行参数复制到缓冲区中。


int main(int argc, char **argv){
char buf[128];
...
snprintf(buf,128,argv[1]);
}


该代码允许攻击者查看堆栈的内容,并使用包含一连串的格式化指令的命令行参数对堆栈进行写入。攻击者能够通过提供更多的格式化指令(如 %x)来读取堆栈中的内容,然后函数会作为即将格式化的参数使用。(在本例中,函数没有采用任何即将格式化的参数。)通过使用 %n 格式化指令,攻击者能够对堆栈进行写入,进而使 snprintf() 记下迄今为止输出的字节数,并将其传送给指定的参数(而不是直接从参数中读取数值,这是程序员最初设计的行为)。对于这种攻击,更为的复杂的形式是使用四条交错的写入来完全控制堆栈中某个指针的值。

示例 2:有些实现方式通过提供格式化指令来控制内存中的读写位置,这样可以简化较高级的攻击。以下代码就是这种指令的一个例子,它为 glibc 而写:


printf("%d %d %1$d %1$d\n", 5, 9);


该代码产生了如下输出:


5 9 5 5


此外,还可以使用 half-writes (%hn) 来准确地控制内存中的任意 DWORDS,这会大大地降低执行攻击的难度,否则此攻击将需要进行四次交错写入,如Example 1 中所述。

示例 3:简单的 format string 漏洞通常由表面上看似没有什么危险的快捷方式所导致。某些快捷方式的使用已经深入人心,以致于程序员可能都不会意识到他们所使用的函数需要一个 format string 参数。

例如,syslog() 函数有时候可以这样使用:


...
syslog(LOG_ERR, cmdBuf);
...


由于 syslog() 的第二个参数是格式字符串,因此 cmdBuf 中的任何格式化指令都会按照Example 1 中所述进行解释。

以下代码显示了 syslog() 的正确使用方式:


...
syslog(LOG_ERR, "%s", cmdBuf);
...
References
[1] T. Newsham Format String Attacks Guardent, Inc.
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark complete
[9] Standards Mapping - Common Weakness Enumeration CWE ID 134
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754, CCI-002824
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1), SI-16 Memory Protection (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation, SI-16 Memory Protection
[16] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.4.2 Memory/String/Unmanaged Code Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[19] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[20] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[21] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[31] 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
[32] 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
[33] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 134
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Format String (WASC-06)
[56] Standards Mapping - Web Application Security Consortium 24 + 2 Format String Attack
desc.dataflow.cpp.format_string
Abstract
攻击者可以控制 format string,发起类似于缓冲区溢出的攻击。
Explanation
Format string 漏洞会在以下情况下发生:

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



2. 数据作为 format string 参数传送到某个函数,如 sprintf()FormatMessageW()syslog()NSLogNSString.stringWithFormat示例 1:下面的代码将命令行参数作为 NSString.stringWithFormat: 中的 format string。


int main(int argc, char **argv){
char buf[128];
...
[NSString stringWithFormat:argv[1], argv[2] ];
}


该代码允许攻击者查看堆栈的内容,并使用包含一连串的格式化指令的命令行参数损坏堆栈。攻击者能够通过提供更多的格式化指令(如 %x)来读取堆栈中的内容,然后函数会作为即将格式化的参数使用。(在本例中,函数没有采用任何即将格式化的参数。)

Objective-C 支持旧版 C 语言的标准库,因此如果您的应用程序使用 C API,则可以使用以下示例。

示例 2:有些实现方式通过提供格式化指令来控制内存中的读写位置,这样可以简化较高级的攻击。以下代码就是这种指令的一个例子,它为 glibc 而写:


printf("%d %d %1$d %1$d\n", 5, 9);


该代码产生了如下输出:


5 9 5 5


此外,还可以使用 half-writes (%hn) 来准确地控制内存中的任意 DWORDS,这会大大地降低执行攻击的难度,否则此攻击将需要进行四次交错写入,如Example 1 中所述。

示例 3:简单的 format string 漏洞通常由表面上看似没有什么危险的快捷方式所导致。某些快捷方式的使用已经深入人心,以致于程序员可能都不会意识到他们所使用的函数需要一个 format string 参数。

例如,syslog() 函数有时候可以这样使用:


...
syslog(LOG_ERR, cmdBuf);
...


由于 syslog() 的第二个参数是格式字符串,因此 cmdBuf 中的任何格式化指令都会按照Example 1 中所述进行解释。

以下代码显示了 syslog() 的正确使用方式:


...
syslog(LOG_ERR, "%s", cmdBuf);
...
示例 4:Apple 核心类提供了利用 format string 漏洞的有趣途径。

例如,String.stringByAppendingFormat() 函数有时候可以这样使用:


...
NSString test = @"Sample Text.";
test = [test stringByAppendingFormat:[MyClass
formatInput:inputControl.text]];
...


stringByAppendingFormat 会解析传递给它的 NSString 中包含的任意 format string 字符。

以下代码显示了 stringByAppendingFormat() 的正确使用方式:


...
NSString test = @"Sample Text.";
test = [test stringByAppendingFormat:@"%@", [MyClass
formatInput:inputControl.text]];
...
References
[1] T. Newsham Format String Attacks Guardent, Inc.
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark complete
[9] Standards Mapping - Common Weakness Enumeration CWE ID 134
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754, CCI-002824
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1), SI-16 Memory Protection (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation, SI-16 Memory Protection
[16] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.4.2 Memory/String/Unmanaged Code Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[19] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[20] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[21] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[31] 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
[32] 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
[33] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 134
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Format String (WASC-06)
[56] Standards Mapping - Web Application Security Consortium 24 + 2 Format String Attack
desc.dataflow.objc.format_string
Abstract
该程序使用了一个结构不良的 format string,其中包含的转换说明符的数量与函数具有的参数数量不一致。不正确的 format string 会导致该程序从分配的内存边界之外读取数据,这可以让攻击者访问敏感信息、引入错误行为,或造成程序崩溃。
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 会导致程序访问分配的内存边界之外的值。

示例:以下代码会从堆栈中读取任意值,因为格式说明符的数量与传递给该函数的参数数量不一致。

void wrongNumberArgs(char *s, float f, int d) {
char buf[1024];
sprintf(buf, "Wrong number of %.512s");
}
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.0
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[8] Standards Mapping - Common Weakness Enumeration CWE ID 126
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [1] CWE ID 119, [5] CWE ID 125
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [5] CWE ID 119, [4] CWE ID 125
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [3] CWE ID 125, [17] CWE ID 119
[12] Standards Mapping - Common Weakness Enumeration Top 25 2022 [5] CWE ID 125, [19] CWE ID 119
[13] Standards Mapping - Common Weakness Enumeration Top 25 2023 [7] CWE ID 125, [17] CWE ID 119
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002824
[15] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[16] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-16 Memory Protection (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-16 Memory Protection
[19] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[20] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[21] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 119
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002590 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002590 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002590 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002590 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002590 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002590 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002590 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002590 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002590 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002590 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002590 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002590 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002590 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002590 CAT I
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Format String (WASC-06)
[56] Standards Mapping - Web Application Security Consortium 24 + 2 Format String Attack
desc.internal.cpp.format_string_argument_number_mismatch
Abstract
该程序使用了一个结构不良的 format string,其中包含的转换说明符与传递给该函数的参数类型不一致。不正确的 format string 会导致该程序转换值时出错,还可能会在分配的内存边界之外读写数据,这会引入错误的行为或造成程序崩溃。
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 会导致程序错误地进行值的转换,或访问分配的内存边界之外的值。

示例:以下代码使用 %d 格式说明符将一个浮点转换为 f


void ArgTypeMismatch(float f, int d, char *s, wchar *ws) {
char buf[1024];
sprintf(buf, "Wrong type of %d", 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 2.0
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[8] Standards Mapping - Common Weakness Enumeration CWE ID 125, CWE ID 787
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [1] CWE ID 119, [5] CWE ID 125, [12] CWE ID 787
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [5] CWE ID 119, [4] CWE ID 125, [2] CWE ID 787
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [1] CWE ID 787, [3] CWE ID 125, [17] CWE ID 119
[12] Standards Mapping - Common Weakness Enumeration Top 25 2022 [1] CWE ID 787, [5] CWE ID 125, [19] CWE ID 119
[13] Standards Mapping - Common Weakness Enumeration Top 25 2023 [1] CWE ID 787, [7] CWE ID 125, [17] CWE ID 119
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002824
[15] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[16] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 10.3
[17] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 5-0-3
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-16 Memory Protection (P1)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-16 Memory Protection
[20] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[21] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[22] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 119
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002590 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002590 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002590 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002590 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002590 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002590 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002590 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002590 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002590 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002590 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002590 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002590 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002590 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002590 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 Format String (WASC-06)
[57] Standards Mapping - Web Application Security Consortium 24 + 2 Format String Attack
desc.internal.cpp.format_string_argument_type_mismatch
Abstract
HTTP 响应头文件中包含未验证的数据会引发 cache-poisoning、cross-site scripting、cross-user defacement、page hijacking、cookie manipulation 或 open redirect。
Explanation
以下情况中会出现 Header Manipulation 漏洞:

1. 数据通过一个不可信赖的数据源进入 Web 应用程序,最常见的是 HTTP 请求。

2. 数据包含在一个 HTTP 响应头文件里,未经验证就发送给了 Web 用户。

如同许多软件安全漏洞一样,Header Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,这些漏洞是显而易见的:一个攻击者将恶意数据传送到易受攻击的应用程序,且该应用程序将数据包含在 HTTP 响应头文件中。

其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功地实施 HTTP Response Splitting 盗取,应用程序必须允许将那些包含 CR(回车,由 %0d 或 \r 指定)和 LF(换行,由 %0a 或 \n 指定)的字符输入到头文件中。攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文,还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 头文件感染恶意字符。如果您的应用程序服务器能够防止设置带有换行符的头文件,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此必须在设置带有用户输入的 HTTP 头文件时采取措施。

示例:下列代码片段会从 HTTP 请求中读取网络日志项的作者名字 author,并将其置于一个 HTTP 响应的 cookie 头文件中。


...
author = request->get_form_field( 'author' ).
response->set_cookie( name = 'author' value = author ).
...


假设在请求中提交了一个字符串,该字符串由标准的字母数字字符组成,如“Jane Smith”,那么包含该 Cookie 的 HTTP 响应可能表现为以下形式:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


然而,因为 cookie 值来源于未经校验的用户输入,所以仅当提交给 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如“Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...”,那么 HTTP 响应就会被分割成以下形式的两个响应:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


显然,第二个响应已完全由攻击者控制,攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应,从而发起多种形式的攻击,包括:cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement:攻击者可以向一个易受攻击的服务器发出一个请求,导致服务器创建两个响应,其中第二个响应可能会被曲解为对其他请求的响应,而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现:攻击者诱骗用户,让他们自己提交恶意请求;或在远程情况下,攻击者与用户共享同一个连接到服务器(如共享代理服务器)的 TCP 连接。最理想的情况是,攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击,进而对应用程序的安全性失去信心。最糟糕的情况是,攻击者可能提供经特殊技术处理的内容,这些内容旨在模仿应用程序的执行方式,但会重定向用户的私人信息(如帐号和密码),将这些信息发送给攻击者。

缓存中毒: 如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来,该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存(如在代理服务器中常见的缓存)中,那么使用该缓存的所有用户都会不断收到恶意内容,直到清除该缓存项为止。同样,如果响应缓存在单个用户的浏览器中,那么在清除该缓存项以前,该用户会不断收到恶意内容。然而,影响仅局限于本地浏览器的用户。

Cross-Site Scripting:一旦攻击者控制了应用程序传送的响应,就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式,这种攻击在响应中包含了恶意的 JavaScript 或其他代码,并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户,最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者,而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking:除了利用一个易受攻击的应用程序向用户传输恶意内容,还可以利用相同的根漏洞,将服务器生成的供用户使用的敏感内容重定向,转而供攻击者使用。攻击者通过提交一个会导致两个响应的请求,即服务器做出的预期响应和攻击者创建的响应,致使某个中间节点(如共享的代理服务器)误导服务器所生成的响应,将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应,第一个被解析为针对攻击者请求做出的响应,第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时,攻击者的请求已经在此处等候,并被解析为针对受害者这一请求的响应。这时,攻击者将第二个请求发送给服务器,代理服务器利用针对受害者(用户)的、由该服务器产生的这一请求对服务器做出响应,因此,针对受害者的这一响应中会包含所有头文件或正文中的敏感信息。

Cookie Manipulation:当与类似跨站请求伪造的攻击相结合时,攻击者就可以篡改、添加、甚至覆盖合法用户的 cookie。

Open Redirect:如果允许未验证的输入来控制重定向机制所使用的 URL,可能会有利于攻击者发动钓鱼攻击。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] 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
[35] 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
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.abap.header_manipulation
Abstract
HTTP 响应标头中包含未经验证的数据会招致 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect 攻击。
Explanation
Header Manipulation 漏洞会在以下情况下发生:

1.数据通过不可信数据源进入 Web 应用程序,最常见的是通过 HTTP 请求。


2.数据包含在未经验证就发送给 Web 用户的 HTTP 响应标头中。

如同许多软件安全漏洞一样,Header Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,这些漏洞是显而易见的:攻击者将恶意数据传送到易受攻击的应用程序,然后该应用程序将这些数据包含在 HTTP 响应标头中。

其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功实施 HTTP Response Splitting 漏洞,该应用程序必须允许将包含 CR(回车符,也可以由 %0d 或 \r 指定)和 LF(换行符,也可以由 %0a 或 \n 指定)字符的输入包含在标头中。攻击者不仅可以利用这些字符控制应用程序要发送的响应的剩余标头和正文,还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 标头感染恶意字符。例如,如果尝试使用被禁用的字符设置标头,最新版本的 Apache Tomcat 会抛出 IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的标头,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此在设置带有用户输入的 HTTP 标头时仍需小心谨慎。

示例 1:以下代码设置的 HTTP 标头的名称和值可能受到攻击者控制:


@HttpGet
global static void doGet() {
...
Map<String, String> params = ApexPages.currentPage().getParameters();

RestResponse res = RestContext.response;
res.addHeader(params.get('name'), params.get('value'));
...
}


假设某个名称/值对由 authorJane Smith 组成,则包含此标头的 HTTP 响应可能会采用以下形式:


HTTP/1.1 200 OK
...
author:Jane Smith
...


但是,由于标头值是由未经验证的用户输入组成的,因此攻击者可能会提交恶意的名称/值对,例如 HTTP/1.1 200 OK\r\n...foobar,然后 HTTP 响应将被分割成以下形式的两个响应:


HTTP/1.1 200 OK
...

HTTP/1.1 200 OK
...
foo:bar


显然,第二个响应已完全由攻击者控制,攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应,从而发起多种形式的攻击,包括:cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement:攻击者可以向一个易受攻击的服务器发出一个请求,导致服务器创建两个响应,其中第二个响应可能会被曲解为对其他请求的响应,而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现:攻击者诱骗用户,让他们自己提交恶意请求;或在远程情况下,攻击者与用户共享同一个连接到服务器(如共享代理服务器)的 TCP 连接。最理想的情况是,攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击,进而对应用程序的安全性失去信心。最糟糕的情况是,攻击者可能提供经特殊技术处理的内容,这些内容旨在模仿应用程序的执行方式,但会重定向用户的私人信息(如帐号和密码),将这些信息发送给攻击者。

Cache Poisoning:如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来,该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存(如在代理服务器中常见的缓存)中,那么使用该缓存的所有用户都会不断收到恶意内容,直到清除该缓存项为止。同样,如果响应缓存在单个用户的浏览器中,那么在清除该缓存项以前,该用户会不断收到恶意内容。然而,影响将仅局限于本地浏览器的用户。

Cross-Site Scripting:一旦攻击者控制了应用程序传送的响应,就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式,这种攻击在响应中包含了恶意的 JavaScript 或其他代码,并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户,最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者,而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking:除了利用一个易受攻击的应用程序向用户传输恶意内容,还可以利用相同的根漏洞,将服务器生成的供用户使用的敏感内容重定向,转而供攻击者使用。攻击者通过提交一个会产生两个响应的请求,即服务器做出的预期响应和攻击者创建的响应,致使某个中间节点(如共享的代理服务器)误导服务器所生成的响应,将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应,第一个被解析为针对攻击者请求做出的响应,第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时,攻击者的请求已经在此处等候,并被解析为针对受害者这一请求的响应。这时,攻击者将第二个请求发送给服务器,代理服务器利用针对受害者(用户)的、由该服务器产生的这一请求对服务器做出响应。因此,针对受害者的这一响应中会包含所有标头或正文中的敏感信息。

Cookie Manipulation:当与 Cross-Site Request Forgery 等类似攻击相结合时,攻击者可能会篡改、添加甚至覆盖合法用户的 Cookie。

Open Redirect:如果允许未验证的输入控制重定向机制所使用的 URL,可能会有利于攻击者发动钓鱼攻击。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] 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
[35] 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
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.apex.header_manipulation
Abstract
HTTP 响应头文件中包含未验证的数据会引发 cache-poisoning、cross-site scripting、cross-user defacement、page hijacking、cookie manipulation 或 open redirect。
Explanation
以下情况中会出现 Header Manipulation 漏洞:

1. 数据通过一个不可信赖的数据源进入 Web 应用程序,最常见的是 HTTP 请求。

2. 数据包含在一个 HTTP 响应头文件里,未经验证就发送给了 Web 用户。

如同许多软件安全漏洞一样,Header Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,这些漏洞是显而易见的:一个攻击者将恶意数据传送到易受攻击的应用程序,且该应用程序将数据包含在 HTTP 响应头文件中。

其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功地实施 HTTP Response Splitting 盗取,应用程序必须允许将那些包含 CR(回车,由 %0d 或 \r 指定)和 LF(换行,由 %0a 或 \n 指定)的字符输入到头文件中。攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文,还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器和框架可以防止 HTTP 头文件感染恶意字符。例如,Microsoft 的 .NET 框架的最新版本会在 CR、LF 和 NULL 字符被传送给 HttpResponse.AddHeader() 方法时将其转换为 %0d、%0a 和 %00。如果您正在使用的最新的 .NET 框架不允许使用新行字符设置头文件,则应用程序便不会容易受到 HTTP Response Splitting 攻击。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此必须在设置带有用户输入的 HTTP 头文件时采取措施。

示例:以下代码片段会从 HTTP 请求中读取网络日志项的作者名字 author,并将其置于一个 HTTP 响应的 Cookie 头文件中。


protected System.Web.UI.WebControls.TextBox Author;
...
string author = Author.Text;
Cookie cookie = new Cookie("author", author);
...


假设在请求中提交了一个字符串,该字符串由标准的字母数字字符组成,如“Jane Smith”,那么包含该 Cookie 的 HTTP 响应可能表现为以下形式:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


然而,因为 cookie 值来源于未经校验的用户输入,所以仅当提交给 Author.Text 的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如“Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...”,那么 HTTP 响应就会被分割成以下形式的两个响应:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


显然,第二个响应已完全由攻击者控制,攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应,从而发起多种形式的攻击,包括:cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement:攻击者可以向一个易受攻击的服务器发出一个请求,导致服务器创建两个响应,其中第二个响应可能会被曲解为对其他请求的响应,而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现:攻击者诱骗用户,让他们自己提交恶意请求;或在远程情况下,攻击者与用户共享同一个连接到服务器(如共享代理服务器)的 TCP 连接。最理想的情况是,攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击,进而对应用程序的安全性失去信心。最糟糕的情况是,攻击者可能提供经特殊技术处理的内容,这些内容旨在模仿应用程序的执行方式,但会重定向用户的私人信息(如帐号和密码),将这些信息发送给攻击者。

缓存中毒:如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来,该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存(如在代理服务器中常见的缓存)中,那么使用该缓存的所有用户都会不断收到恶意内容,直到清除该缓存项为止。同样,如果响应缓存在单个用户的浏览器中,那么在清除该缓存项以前,该用户会不断收到恶意内容。然而,影响仅局限于本地浏览器的用户。

Cross-Site Scripting:一旦攻击者控制了应用程序传送的响应,就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式,这种攻击在响应中包含了恶意的 JavaScript 或其他代码,并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户,最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者,而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking:除了利用一个易受攻击的应用程序向用户传输恶意内容,还可以利用相同的根漏洞,将服务器生成的供用户使用的敏感内容重定向,转而供攻击者使用。攻击者通过提交一个会导致两个响应的请求,即服务器做出的预期响应和攻击者创建的响应,致使某个中间节点(如共享的代理服务器)误导服务器所生成的响应,将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应,第一个被解析为针对攻击者请求做出的响应,第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时,攻击者的请求已经在此处等候,并被解析为针对受害者这一请求的响应。这时,攻击者将第二个请求发送给服务器,代理服务器利用针对受害者(用户)的、由该服务器产生的这一请求对服务器做出响应,因此,针对受害者的这一响应中会包含所有头文件或正文中的敏感信息。

Cookie Manipulation:当与类似跨站请求伪造的攻击相结合时,攻击者就可以篡改、添加、甚至覆盖合法用户的 cookie。

Open Redirect:如果允许未验证的输入来控制重定向机制所使用的 URL,可能会有利于攻击者发动钓鱼攻击。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] 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
[35] 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
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.dotnet.header_manipulation
Abstract
HTTP 响应头文件中包含未经验证的数据会引发 cache-poisoning、cross-site scripting、cross-user defacement 或 page hijacking 等攻击。
Explanation
以下情况中会出现 Header Manipulation 漏洞:

1. 数据通过一个不可信赖的数据源进入 Web 应用程序,最常见的是 HTTP 请求。

2. 数据包含在一个 HTTP 响应头文件里,未验证是否存在恶意字符就传送给了 Web 用户。

如同许多软件安全漏洞一样,Header Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,这些漏洞是显而易见的:一个攻击者将恶意数据传送到易受攻击的应用程序,且该应用程序将数据包含在 HTTP 响应头文件中。

其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功地实施 HTTP Response Splitting 盗取,应用程序必须允许将那些包含 CR(回车,由 %0d 或 \r 指定)和 LF(换行,由 %0a 或 \n 指定)的字符输入到头文件中。攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文,还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 头文件感染恶意字符。如果您的应用程序服务器能够防止设置带有换行符的头文件,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此必须在设置带有用户输入的 HTTP 头文件时采取措施。

示例:下列代码片段会从 HTML 表单中读取网络日志项的作者名字 author,并在一个 HTTP 响应的 cookie 头文件中设置。


...
EXEC CICS
WEB READ
FORMFIELD(NAME)
VALUE(AUTHOR)
...
END-EXEC.

EXEC CICS
WEB WRITE
HTTPHEADER(COOKIE)
VALUE(AUTHOR)
...
END-EXEC.
...


假设在请求中提交了一个字符串,该字符串由标准的字母数字字符组成,如“Jane Smith”,那么包含该 Cookie 的 HTTP 响应可能表现为以下形式:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


然而,因为 cookie 值来源于未经校验的用户输入,所以仅当提交给 AUTHOR 的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n......",那么 HTTP 响应就会被分割成以下形式的两个响应:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


显然,第二个响应已完全由攻击者控制,攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应,从而发起多种形式的攻击,包括:cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement:攻击者可以向一个易受攻击的服务器发出一个请求,导致服务器创建两个响应,其中第二个响应可能会被曲解为对其他请求的响应,而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现:攻击者诱骗用户,让他们自己提交恶意请求;或在远程情况下,攻击者与用户共享同一个连接到服务器(如共享代理服务器)的 TCP 连接。最理想的情况是,攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击,进而对应用程序的安全性失去信心。最糟糕的情况是,攻击者可能提供经特殊技术处理的内容,这些内容旨在模仿应用程序的执行方式,但会重定向用户的私人信息(如帐号和密码),将这些信息发送给攻击者。

Cache Poisoning: 如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来,该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存(如在代理服务器中常见的缓存)中,那么使用该缓存的所有用户都会不断收到恶意内容,直到清除该缓存项为止。同样,如果响应缓存在单个用户的浏览器中,那么在清除该缓存项以前,该用户会不断收到恶意内容。然而,影响仅局限于本地浏览器的用户。

Cross-Site Scripting:一旦攻击者控制了应用程序传送的响应,就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式,这种攻击在响应中包含了恶意的 JavaScript 或其他代码,并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户,最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者,而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking:除了利用一个易受攻击的应用程序向用户传输恶意内容,还可以利用相同的根漏洞,将服务器生成的供用户使用的敏感内容重定向,转而供攻击者使用。攻击者通过提交一个会导致两个响应的请求,即服务器做出的预期响应和攻击者创建的响应,致使某个中间节点(如共享的代理服务器)误导服务器所生成的响应,将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应,第一个被解析为针对攻击者请求做出的响应,第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时,攻击者的请求已经在此处等候,并被解析为针对受害者这一请求的响应。这时,攻击者将第二个请求发送给服务器,代理服务器利用针对受害者(用户)的、由该服务器产生的这一请求对服务器做出响应,因此,针对受害者的这一响应中会包含所有头文件或正文中的敏感信息。

Cookie Manipulation:当与类似跨站请求伪造的攻击相结合时,攻击者就可以篡改、添加、甚至覆盖合法用户的 cookie。

Open Redirect:如果允许未验证的输入来控制重定向机制所使用的 URL,可能会有利于攻击者发动钓鱼攻击。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] 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
[35] 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
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.cobol.header_manipulation
Abstract
HTTP 响应头文件中包含未验证的数据会引发 cache-poisoning、cross-site scripting、cross-user defacement、page hijacking、cookie manipulation 或 open redirect。
Explanation
以下情况中会出现 Header Manipulation 漏洞:

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

2. 数据包含在一个 HTTP 响应头文件里,未经验证就发送给了 Web 用户。

如同许多软件安全漏洞一样,Header Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,这些漏洞是显而易见的:一个攻击者将恶意数据传送到易受攻击的应用程序,且该应用程序将数据包含在 HTTP 响应头文件中。

其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功地实施 HTTP Response Splitting 盗取,应用程序必须允许将那些包含 CR(回车,由 %0d 或 \r 指定)和 LF(换行,由 %0a 或 \n 指定)的字符输入到头文件中。攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文,还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 头文件感染恶意字符。例如,如果尝试使用被禁用的字符设置头文件,最新版本的 Apache Tomcat 会抛出 IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此必须在设置带有用户输入的 HTTP 头文件时采取措施。

示例:下面的代码片段将从 Web 表单中读取某个网络日志项作者的名字,author,并且把它设置到一个 HTTP 响应的 cookie 头文件中。


<cfcookie name = "author"
value = "#Form.author#"
expires = "NOW">


假设在请求中提交了一个字符串,该字符串由标准的字母数字字符组成,如“Jane Smith”,那么包含该 Cookie 的 HTTP 响应可能表现为以下形式:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


然而,因为 cookie 值来源于未经校验的用户输入,所以仅当提交给 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n......",那么 HTTP 响应就会被分割成以下形式的两个响应:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1/1 200 OK
...


显然,第二个响应已完全由攻击者控制,攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应,从而发起多种形式的攻击,包括:cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement:攻击者可以向一个易受攻击的服务器发出一个请求,导致服务器创建两个响应,其中第二个响应可能会被曲解为对其他请求的响应,而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现:攻击者诱骗用户,让他们自己提交恶意请求;或在远程情况下,攻击者与用户共享同一个连接到服务器(如共享代理服务器)的 TCP 连接。最理想的情况是,攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击,进而对应用程序的安全性失去信心。最糟糕的情况是,攻击者可能提供经特殊技术处理的内容,这些内容旨在模仿应用程序的执行方式,但会重定向用户的私人信息(如帐号和密码),将这些信息发送给攻击者。

Cache Poisoning: 如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来,该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存(如在代理服务器中常见的缓存)中,那么使用该缓存的所有用户都会不断收到恶意内容,直到清除该缓存项为止。同样,如果响应缓存在单个用户的浏览器中,那么在清除该缓存项以前,该用户会不断收到恶意内容。然而,影响仅局限于本地浏览器的用户。

Cross-Site Scripting:一旦攻击者控制了应用程序传送的响应,就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式,这种攻击在响应中包含了恶意的 JavaScript 或其他代码,并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户,最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者,而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking:除了利用一个易受攻击的应用程序向用户传输恶意内容,还可以利用相同的根漏洞,将服务器生成的供用户使用的敏感内容重定向,转而供攻击者使用。攻击者通过提交一个会导致两个响应的请求,即服务器做出的预期响应和攻击者创建的响应,致使某个中间节点(如共享的代理服务器)误导服务器所生成的响应,将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应,第一个被解析为针对攻击者请求做出的响应,第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时,攻击者的请求已经在此处等候,并被解析为针对受害者这一请求的响应。这时,攻击者将第二个请求发送给服务器,代理服务器利用针对受害者(用户)的、由该服务器产生的这一请求对服务器做出响应,因此,针对受害者的这一响应中会包含所有头文件或正文中的敏感信息。

Cookie Manipulation:当与类似跨站请求伪造的攻击相结合时,攻击者就可以篡改、添加、甚至覆盖合法用户的 cookie。

Open Redirect:如果允许未验证的输入来控制重定向机制所使用的 URL,可能会有利于攻击者发动钓鱼攻击。
References
[1] Amit Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] Diabolic Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] 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
[35] 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
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.cfml.header_manipulation
Abstract
HTTP 响应标头中包含未经验证的数据会招致 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect 攻击。
Explanation
Header Manipulation 漏洞会在以下情况下发生:

1.数据通过不可信来源进入 Web 应用程序,最常见的是 HTTP 请求。

2.数据包含在未经验证就发送给 Web 用户的 HTTP 响应标头中。

如同许多软件安全漏洞一样,Header Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,这些漏洞是显而易见的:攻击者将恶意数据传送到易受攻击的应用程序,然后该应用程序将这些数据包含在 HTTP 响应标头中。

其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功实施 HTTP Response Splitting 漏洞,该应用程序必须允许将包含 CR(回车符,也可以由 %0d 或 \r 指定)和 LF(换行符,也可以由 %0a 或 \n 指定)字符的输入包含在标头中。攻击者不仅可以利用这些字符控制应用程序要发送的响应的剩余标头和正文,还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 标头中注入恶意字符。例如,如果尝试使用被禁用的字符设置标头,最新版本的 Apache Tomcat 会抛出 IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的标头,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此在设置带有用户输入的 HTTP 标头时仍需小心谨慎。

示例:以下代码段会从 HTTP 请求中读取 'content-type',并将其置于一个新的 HTTP 请求的标头中。


final server = await HttpServer.bind('localhost', 18081);
server.listen((request) async {
final headers = request.headers;
final contentType = headers.value('content-type');
final client = HttpClient();
final clientRequest = await client.getUrl(Uri.parse('https://example.com'));
clientRequest.headers.add('Content-Type', contentType as Object);
});


由于 'Content-Type' 标头的值由未经验证的用户输入构成,恶意操作者可能会操纵该标头来利用漏洞、执行代码注入攻击、暴露敏感数据、启用恶意文件执行或触发拒绝服务情况,从而使应用程序的安全性和稳定性面临重大风险。
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 113
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[9] Standards Mapping - FIPS200 SI
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[20] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[21] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[22] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 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 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] 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
[33] 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
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[55] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[56] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.dart.header_manipulation
Abstract
HTTP 响应标头中包含未经验证的数据会招致 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect 攻击。
Explanation
Header Manipulation 漏洞会在以下情况下发生:

1.数据通过不可信来源进入 Web 应用程序,最常见的是 HTTP 请求。

2.数据包含在未经验证就发送给 Web 用户的 HTTP 响应标头中。

如同许多软件安全漏洞一样,Header Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,这些漏洞是显而易见的:攻击者将恶意数据传送到易受攻击的应用程序,然后该应用程序将这些数据包含在 HTTP 响应标头中。


示例:以下代码片段会从 HTTP 请求中读取网络日志项的作者名字 author,并将其置于一个 HTTP 响应的 Cookie 标头中。


...
author := request.FormValue("AUTHOR_PARAM")
cookie := http.Cookie{
Name: "author",
Value: author,
Domain: "www.example.com",
}
http.SetCookie(w, &cookie)
...


攻击者可以构建任意 HTTP 响应,从而发起多种形式的攻击,包括:cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement:攻击者可以向一个易受攻击的服务器发出一个请求,导致服务器创建两个响应,其中第二个响应可能会被曲解为对其他请求的响应,而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现:攻击者诱骗用户,让他们自己提交恶意请求;或在远程情况下,攻击者与用户共享同一个连接到服务器(如共享代理服务器)的 TCP 连接。最理想的情况是,攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击,进而对应用程序的安全性失去信心。最糟糕的情况是,攻击者可能提供经特殊技术处理的内容,这些内容旨在模仿应用程序的执行方式,但会重定向用户的私人信息(如帐号和密码),将这些信息发送给攻击者。

Cache Poisoning:如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来,该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存(如在代理服务器中常见的缓存)中,那么使用该缓存的所有用户都会不断收到恶意内容,直到清除该缓存项为止。同样,如果响应缓存在单个用户的浏览器中,那么在清除该缓存项以前,该用户会不断收到恶意内容。然而,影响仅局限于本地浏览器的用户。

Cross-Site Scripting:一旦攻击者控制了应用程序传送的响应,就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式,这种攻击在响应中包含了恶意的 JavaScript 或其他代码,并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户,最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者,而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking:除了利用一个易受攻击的应用程序向用户传输恶意内容,还可以利用相同的根漏洞,将服务器生成的供用户使用的敏感内容重定向,转而供攻击者使用。攻击者通过提交一个会产生两个响应的请求,即服务器做出的预期响应和攻击者创建的响应,致使某个中间节点(如共享的代理服务器)误导服务器所生成的响应,将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应,第一个被解析为针对攻击者请求做出的响应,第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时,攻击者的请求已经在此处等候,并被解析为针对受害者这一请求的响应。这时,攻击者将第二个请求发送给服务器,代理服务器利用针对受害者(用户)的、由该服务器产生的这一请求对服务器做出响应。因此,针对受害者的这一响应中会包含所有标头或正文中的敏感信息。

Cookie Manipulation:当与类似 Cross-Site Request Forgery 的攻击相结合时,攻击者就可以篡改、添加甚至覆盖合法用户的 Cookie。

Open Redirect:如果允许未验证的输入控制重定向机制所使用的 URL,可能会有利于攻击者发动钓鱼攻击。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Common Weakness Enumeration CWE ID 113
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[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 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[15] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[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 Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[21] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[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, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.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 - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.golang.header_manipulation
Abstract
HTTP 响应头文件中包含未验证的数据会引发 cache-poisoning、cross-site scripting、cross-user defacement、page hijacking、cookie manipulation 或 open redirect。
Explanation
以下情况中会出现 Header Manipulation 漏洞:

1. 数据通过一个不可信赖的数据源进入 Web 应用程序,最常见的是 HTTP 请求。

2. 数据包含在一个 HTTP 响应头文件里,未经验证就发送给了 Web 用户。

如同许多软件安全漏洞一样,Header Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,这些漏洞是显而易见的:一个攻击者将恶意数据传送到易受攻击的应用程序,且该应用程序将数据包含在 HTTP 响应头文件中。

其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功地实施 HTTP Response Splitting 盗取,应用程序必须允许将那些包含 CR(回车,由 %0d 或 \r 指定)和 LF(换行,由 %0a 或 \n 指定)的字符输入到头文件中。攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文,还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 头文件感染恶意字符。例如,如果尝试使用被禁用的字符设置头文件,最新版本的 Apache Tomcat 会抛出 IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此必须在设置带有用户输入的 HTTP 头文件时采取措施。

示例:下列代码片段会从 HTTP 请求中读取网络日志项的作者名字 author,并将其置于一个 HTTP 响应的 cookie 头文件中。


String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);


假设在请求中提交了一个字符串,该字符串由标准的字母数字字符组成,如“Jane Smith”,那么包含该 Cookie 的 HTTP 响应可能表现为以下形式:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


然而,因为 cookie 值来源于未经校验的用户输入,所以仅当提交给 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如“Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...”,那么 HTTP 响应就会被分割成以下形式的两个响应:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


显然,第二个响应已完全由攻击者控制,攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应,从而发起多种形式的攻击,包括:cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement:攻击者可以向一个易受攻击的服务器发出一个请求,导致服务器创建两个响应,其中第二个响应可能会被曲解为对其他请求的响应,而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现:攻击者诱骗用户,让他们自己提交恶意请求;或在远程情况下,攻击者与用户共享同一个连接到服务器(如共享代理服务器)的 TCP 连接。最理想的情况是,攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击,进而对应用程序的安全性失去信心。最糟糕的情况是,攻击者可能提供经特殊技术处理的内容,这些内容旨在模仿应用程序的执行方式,但会重定向用户的私人信息(如帐号和密码),将这些信息发送给攻击者。

缓存中毒: 如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来,该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存(如在代理服务器中常见的缓存)中,那么使用该缓存的所有用户都会不断收到恶意内容,直到清除该缓存项为止。同样,如果响应缓存在单个用户的浏览器中,那么在清除该缓存项以前,该用户会不断收到恶意内容。然而,影响仅局限于本地浏览器的用户。

Cross-Site Scripting:一旦攻击者控制了应用程序传送的响应,就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式,这种攻击在响应中包含了恶意的 JavaScript 或其他代码,并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户,最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者,而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking:除了利用一个易受攻击的应用程序向用户传输恶意内容,还可以利用相同的根漏洞,将服务器生成的供用户使用的敏感内容重定向,转而供攻击者使用。攻击者通过提交一个会导致两个响应的请求,即服务器做出的预期响应和攻击者创建的响应,致使某个中间节点(如共享的代理服务器)误导服务器所生成的响应,将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应,第一个被解析为针对攻击者请求做出的响应,第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时,攻击者的请求已经在此处等候,并被解析为针对受害者这一请求的响应。这时,攻击者将第二个请求发送给服务器,代理服务器利用针对受害者(用户)的、由该服务器产生的这一请求对服务器做出响应,因此,针对受害者的这一响应中会包含所有头文件或正文中的敏感信息。

Cookie Manipulation:当与类似跨站请求伪造的攻击相结合时,攻击者就可以篡改、添加、甚至覆盖合法用户的 cookie。

Open Redirect:如果允许未验证的输入来控制重定向机制所使用的 URL,可能会有利于攻击者发动钓鱼攻击。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] 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
[35] 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
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.java.header_manipulation
Abstract
HTTP 响应头文件中包含未验证的数据会引发 cache-poisoning、cross-site scripting、cross-user defacement、page hijacking、cookie manipulation 或 open redirect。
Explanation
以下情况中会出现 Header Manipulation 漏洞:

1. 数据通过一个不可信赖的数据源进入 Web 应用程序,最常见的是 HTTP 请求。

2. 数据包含在一个 HTTP 响应头文件里,未经验证就发送给了 Web 用户。

如同许多软件安全漏洞一样,Header Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,这些漏洞是显而易见的:一个攻击者将恶意数据传送到易受攻击的应用程序,且该应用程序将数据包含在 HTTP 响应头文件中。

其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功地实施 HTTP Response Splitting 盗取,应用程序必须允许将那些包含 CR(回车,由 %0d 或 \r 指定)和 LF(换行,由 %0a 或 \n 指定)的字符输入到头文件中。攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文,还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 头文件感染恶意字符。如果您的应用程序服务器能够防止设置带有换行符的头文件,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此必须在设置带有用户输入的 HTTP 头文件时采取措施。

示例:下列代码片段会从 HTTP 请求中读取网络日志项的作者名字 author,并将其置于一个 HTTP 响应的 cookie 头文件中。


author = form.author.value;
...
document.cookie = "author=" + author + ";expires="+cookieExpiration;
...


假设在请求中提交了一个字符串,该字符串由标准的字母数字字符组成,如“Jane Smith”,那么包含该 Cookie 的 HTTP 响应可能表现为以下形式:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


然而,因为 cookie 值来源于未经校验的用户输入,所以仅当提交给 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n......",那么 HTTP 响应就会被分割成以下形式的两个响应:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


显然,第二个响应已完全由攻击者控制,攻击者可以用任何所需标头和正文内容构建该响应。如果攻击者可以构造任意 HTTP 响应,则会导致多种形式的攻击,包括:Web 和浏览器 Cache-Poisoning、Cross-Site Scripting 和 Page Hijacking。


Cache Poisoning: 如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来,该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存(如在代理服务器中常见的缓存)中,那么使用该缓存的所有用户都会不断收到恶意内容,直到清除该缓存项为止。同样,如果响应缓存在单个用户的浏览器中,那么在清除该缓存项以前,该用户会不断收到恶意内容。然而,影响仅局限于本地浏览器的用户。

Cross-Site Scripting:一旦攻击者控制了应用程序传送的响应,就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式,这种攻击在响应中包含了恶意的 JavaScript 或其他代码,并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户,最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者,而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking:除了利用一个易受攻击的应用程序向用户传输恶意内容,还可以利用相同的根漏洞,将服务器生成的供用户使用的敏感内容重定向,转而供攻击者使用。攻击者通过提交一个会导致两个响应的请求,即服务器做出的预期响应和攻击者创建的响应,致使某个中间节点(如共享的代理服务器)误导服务器所生成的响应,将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应,第一个被解析为针对攻击者请求做出的响应,第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时,攻击者的请求已经在此处等候,并被解析为针对受害者这一请求的响应。这时,攻击者将第二个请求发送给服务器,代理服务器利用针对受害者(用户)的、由该服务器产生的这一请求对服务器做出响应,因此,针对受害者的这一响应中会包含所有头文件或正文中的敏感信息。

Cookie Manipulation:当与类似跨站请求伪造的攻击相结合时,攻击者就可以篡改、添加、甚至覆盖合法用户的 cookie。

Open Redirect:如果允许未验证的输入来控制重定向机制所使用的 URL,可能会有利于攻击者发动钓鱼攻击。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] 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
[35] 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
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.javascript.header_manipulation
Abstract
HTTP 响应头文件中包含未验证的数据会引发 cache-poisoning、cross-site scripting、cross-user defacement、page hijacking、cookie manipulation 或 open redirect。
Explanation
以下情况中会出现 Header Manipulation 漏洞:

1. 数据通过一个不可信赖的数据源进入 Web 应用程序,最常见的是 HTTP 请求。


2. 数据包含在一个 HTTP 响应头文件里,未经验证就发送给了 Web 用户。

如同许多软件安全漏洞一样,Header Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,这些漏洞是显而易见的:一个攻击者将恶意数据传送到易受攻击的应用程序,且该应用程序将数据包含在 HTTP 响应头文件中。

其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功地实施 HTTP Response Splitting 盗取,应用程序必须允许将那些包含 CR(回车,由 %0d 或 \r 指定)和 LF(换行,由 %0a 或 \n 指定)的字符输入到头文件中。攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文,还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 头文件感染恶意字符。例如,如果尝试使用被禁用的字符设置头文件,最新版本的 Apache Tomcat 会抛出 IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此必须在设置带有用户输入的 HTTP 头文件时采取措施。

示例:以下代码段假设 namevalue 可能会被攻击者控制。这段代码设置了一个名称和值可能被攻击者控制的 HTTP 标头。


...
NSURLSessionConfiguration * config = [[NSURLSessionConfiguration alloc] init];
NSMutableDictionary *dict = @{};
[dict setObject:value forKey:name];
[config setHTTPAdditionalHeaders:dict];
...


假设一个名称/值对由 authorJane Smith 组成,则包含此标头的 HTTP 响应可能会以这样的形式出现:


HTTP/1.1 200 OK
...
author:Jane Smith
...


但是,由于该标头的值由未经验证的用户输入组成,因此攻击者可以提交恶意的名称/值对,例如 HTTP/1.1 200 OK\r\n...foobar,于是该 HTTP 响应将会拆分为如下形式的两个响应:


HTTP/1.1 200 OK
...

HTTP/1.1 200 OK
...
foo:bar


显然,第二个响应已完全由攻击者控制,攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应,从而发起多种形式的攻击,包括:cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement:攻击者可以向一个易受攻击的服务器发出一个请求,导致服务器创建两个响应,其中第二个响应可能会被曲解为对其他请求的响应,而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现:攻击者诱骗用户,让他们自己提交恶意请求;或在远程情况下,攻击者与用户共享同一个连接到服务器(如共享代理服务器)的 TCP 连接。最理想的情况是,攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击,进而对应用程序的安全性失去信心。最糟糕的情况是,攻击者可能提供经特殊技术处理的内容,这些内容旨在模仿应用程序的执行方式,但会重定向用户的私人信息(如帐号和密码),将这些信息发送给攻击者。

缓存中毒:如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来,该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存(如在代理服务器中常见的缓存)中,那么使用该缓存的所有用户都会不断收到恶意内容,直到清除该缓存项为止。同样,如果响应缓存在单个用户的浏览器中,那么在清除该缓存项以前,该用户会不断收到恶意内容。然而,影响仅局限于本地浏览器的用户。

Cross-Site Scripting:一旦攻击者控制了应用程序传送的响应,就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式,这种攻击在响应中包含了恶意的 JavaScript 或其他代码,并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户,最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者,而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking:除了利用一个易受攻击的应用程序向用户传输恶意内容,还可以利用相同的根漏洞,将服务器生成的供用户使用的敏感内容重定向,转而供攻击者使用。攻击者通过提交一个会导致两个响应的请求,即服务器做出的预期响应和攻击者创建的响应,致使某个中间节点(如共享的代理服务器)误导服务器所生成的响应,将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应,第一个被解析为针对攻击者请求做出的响应,第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时,攻击者的请求已经在此处等候,并被解析为针对受害者这一请求的响应。这时,攻击者将第二个请求发送给服务器,代理服务器利用针对受害者(用户)的、由该服务器产生的这一请求对服务器做出响应,因此,针对受害者的这一响应中会包含所有头文件或正文中的敏感信息。

Cookie Manipulation:当与类似跨站请求伪造的攻击相结合时,攻击者就可以篡改、添加、甚至覆盖合法用户的 cookie。

Open Redirect:如果允许未验证的输入来控制重定向机制所使用的 URL,可能会有利于攻击者发动钓鱼攻击。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] 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
[35] 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
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.objc.header_manipulation
Abstract
HTTP 响应头文件中包含未验证的数据会引发 cache-poisoning、cross-site scripting、cross-user defacement、page hijacking、cookie manipulation 或 open redirect。
Explanation
以下情况中会出现 Header Manipulation 漏洞:

1. 数据通过一个不可信赖的数据源进入 Web 应用程序,最常见的是 HTTP 请求。

2. 数据包含在一个 HTTP 响应头文件里,未经验证就发送给了 Web 用户。

如同许多软件安全漏洞一样,Header Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,这些漏洞是显而易见的:一个攻击者将恶意数据传送到易受攻击的应用程序,且该应用程序将数据包含在 HTTP 响应头文件中。

其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功地实施 HTTP Response Splitting 盗取,应用程序必须允许将那些包含 CR(回车,由 %0d 或 \r 指定)和 LF(换行,由 %0a 或 \n 指定)的字符输入到头文件中。攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文,还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 头文件感染恶意字符。例如,当新行传递到 header() 函数时,最新版本的 PHP 将生成一个警告并停止创建头文件。如果您的 PHP 版本能够阻止设置带有换行符的头文件,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此必须在设置带有用户输入的 HTTP 头文件时采取措施。

示例: 下段代码会从 HTTP 请求读取位置,并在 HTTP 响应的位置字段的头文件中对其进行设置。


<?php
$location = $_GET['some_location'];
...
header("location: $location");
?>


假设在请求中提交了一个由标准字母数字字符组成的字符串,如“index.html”,则包含该 Cookie 的 HTTP 响应可能表现为以下形式:


HTTP/1.1 200 OK
...
location: index.html
...


然而,因为该位置的值由未经验证的用户输入组成,所以仅当提交给 some_location 的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如“index.html\r\nHTTP/1.1 200 OK\r\n...”,那么 HTTP 响应就会被分割成以下形式的两个响应:


HTTP/1.1 200 OK
...
location: index.html

HTTP/1.1 200 OK
...


显然,第二个响应已完全由攻击者控制,攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应,从而发起多种形式的攻击,包括:cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement:攻击者可以向一个易受攻击的服务器发出一个请求,导致服务器创建两个响应,其中第二个响应可能会被曲解为对其他请求的响应,而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现:攻击者诱骗用户,让他们自己提交恶意请求;或在远程情况下,攻击者与用户共享同一个连接到服务器(如共享代理服务器)的 TCP 连接。最理想的情况是,攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击,进而对应用程序的安全性失去信心。最糟糕的情况是,攻击者可能提供经特殊技术处理的内容,这些内容旨在模仿应用程序的执行方式,但会重定向用户的私人信息(如帐号和密码),将这些信息发送给攻击者。

Cache Poisoning: 如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来,该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存(如在代理服务器中常见的缓存)中,那么使用该缓存的所有用户都会不断收到恶意内容,直到清除该缓存项为止。同样,如果响应缓存在单个用户的浏览器中,那么在清除该缓存项以前,该用户会不断收到恶意内容。然而,影响仅局限于本地浏览器的用户。

Cross-Site Scripting:一旦攻击者控制了应用程序传送的响应,就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式,这种攻击在响应中包含了恶意的 JavaScript 或其他代码,并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户,最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者,而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking:除了利用一个易受攻击的应用程序向用户传输恶意内容,还可以利用相同的根漏洞,将服务器生成的供用户使用的敏感内容重定向,转而供攻击者使用。攻击者通过提交一个会导致两个响应的请求,即服务器做出的预期响应和攻击者创建的响应,致使某个中间节点(如共享的代理服务器)误导服务器所生成的响应,将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应,第一个被解析为针对攻击者请求做出的响应,第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时,攻击者的请求已经在此处等候,并被解析为针对受害者这一请求的响应。这时,攻击者将第二个请求发送给服务器,代理服务器利用针对受害者(用户)的、由该服务器产生的这一请求对服务器做出响应,因此,针对受害者的这一响应中会包含所有头文件或正文中的敏感信息。

Cookie Manipulation:当与类似跨站请求伪造的攻击相结合时,攻击者就可以篡改、添加、甚至覆盖合法用户的 cookie。

Open Redirect:如果允许未验证的输入来控制重定向机制所使用的 URL,可能会有利于攻击者发动钓鱼攻击。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] 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
[35] 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
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.php.header_manipulation
Abstract
HTTP 响应头文件中包含未验证的数据会引发 cache-poisoning、cross-site scripting、cross-user defacement、page hijacking、cookie manipulation 或 open redirect。
Explanation
以下情况中会出现 Header Manipulation 漏洞:

1. 数据通过一个不可信赖的数据源进入 Web 应用程序,最常见的是 HTTP 请求。

2. 数据包含在一个 HTTP 响应头文件里,未经验证就发送给了 Web 用户。

如同许多软件安全漏洞一样,Header Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,这些漏洞是显而易见的:一个攻击者将恶意数据传送到易受攻击的应用程序,且该应用程序将数据包含在 HTTP 响应头文件中。

其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功地实施 HTTP Response Splitting 盗取,应用程序必须允许将那些包含 CR(回车,由 %0d 或 \r 指定)和 LF(换行,由 %0a 或 \n 指定)的字符输入到头文件中。攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文,还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 头文件感染恶意字符。如果您的应用程序服务器能够防止设置带有换行符的头文件,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此必须在设置带有用户输入的 HTTP 头文件时采取措施。

示例:以下代码片段会从 HTTP 请求中读取网络日志项的作者名字 author,并将其置于一个 HTTP 响应的 Cookie 头文件中。


...
-- Assume QUERY_STRING looks like AUTHOR_PARAM=Name
author := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 14);
OWA_UTIL.mime_header('text/html', false);
OWA_COOKE.send('author', author);
OWA_UTIL.http_header_close;
...


假设在请求中提交了一个字符串,该字符串由标准的字母数字字符组成,如“Jane Smith”,那么包含该 Cookie 的 HTTP 响应可能表现为以下形式:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


然而,因为 cookie 值来源于未经校验的用户输入,所以仅当提交给 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如“Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...”,那么 HTTP 响应就会被分割成以下形式的两个响应:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


显然,第二个响应已完全由攻击者控制,攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应,从而发起多种形式的攻击,包括:cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement:攻击者可以向一个易受攻击的服务器发出一个请求,导致服务器创建两个响应,其中第二个响应可能会被曲解为对其他请求的响应,而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现:攻击者诱骗用户,让他们自己提交恶意请求;或在远程情况下,攻击者与用户共享同一个连接到服务器(如共享代理服务器)的 TCP 连接。最理想的情况是,攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击,进而对应用程序的安全性失去信心。最糟糕的情况是,攻击者可能提供经特殊技术处理的内容,这些内容旨在模仿应用程序的执行方式,但会重定向用户的私人信息(如帐号和密码),将这些信息发送给攻击者。

缓存中毒:如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来,该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存(如在代理服务器中常见的缓存)中,那么使用该缓存的所有用户都会不断收到恶意内容,直到清除该缓存项为止。同样,如果响应缓存在单个用户的浏览器中,那么在清除该缓存项以前,该用户会不断收到恶意内容。然而,影响仅局限于本地浏览器的用户。

Cross-Site Scripting:一旦攻击者控制了应用程序传送的响应,就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式,这种攻击在响应中包含了恶意的 JavaScript 或其他代码,并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户,最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者,而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking:除了利用一个易受攻击的应用程序向用户传输恶意内容,还可以利用相同的根漏洞,将服务器生成的供用户使用的敏感内容重定向,转而供攻击者使用。攻击者通过提交一个会导致两个响应的请求,即服务器做出的预期响应和攻击者创建的响应,致使某个中间节点(如共享的代理服务器)误导服务器所生成的响应,将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应,第一个被解析为针对攻击者请求做出的响应,第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时,攻击者的请求已经在此处等候,并被解析为针对受害者这一请求的响应。这时,攻击者将第二个请求发送给服务器,代理服务器利用针对受害者(用户)的、由该服务器产生的这一请求对服务器做出响应,因此,针对受害者的这一响应中会包含所有头文件或正文中的敏感信息。

Cookie Manipulation:当与类似跨站请求伪造的攻击相结合时,攻击者就可以篡改、添加、甚至覆盖合法用户的 cookie。

Open Redirect:如果允许未验证的输入来控制重定向机制所使用的 URL,可能会有利于攻击者发动钓鱼攻击。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] 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
[35] 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
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.sql.header_manipulation
Abstract
HTTP 响应头文件中包含未验证的数据会引发 cache-poisoning、cross-site scripting、cross-user defacement、page hijacking、cookie manipulation 或 open redirect。
Explanation
以下情况中会出现 Header Manipulation 漏洞:

1. 数据通过一个不可信赖的数据源进入 Web 应用程序,最常见的是 HTTP 请求。

2. 数据包含在一个 HTTP 响应头文件里,未经验证就发送给了 Web 用户。

如同许多软件安全漏洞一样,Header Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,这些漏洞是显而易见的:一个攻击者将恶意数据传送到易受攻击的应用程序,且该应用程序将数据包含在 HTTP 响应头文件中。

其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功地实施 HTTP Response Splitting 盗取,应用程序必须允许将那些包含 CR(回车,由 %0d 或 \r 指定)和 LF(换行,由 %0a 或 \n 指定)的字符输入到头文件中。攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文,还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 头文件感染恶意字符。如果您的应用程序服务器能够防止设置带有换行符的头文件,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此必须在设置带有用户输入的 HTTP 头文件时采取措施。

示例:下段代码会从 HTTP 请求读取位置,并将其设置到 HTTP 响应的位置字段的头文件中。


location = req.field('some_location')
...
response.addHeader("location",location)


假设在请求中提交了一个由标准字母数字字符组成的字符串,如“index.html”,则包含该 Cookie 的 HTTP 响应可能表现为以下形式:


HTTP/1.1 200 OK
...
location: index.html
...


然而,因为该位置的值由未经验证的用户输入组成,所以仅当提交给 some_location 的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如“index.html\r\nHTTP/1.1 200 OK\r\n...”,那么 HTTP 响应就会被分割成以下形式的两个响应:


HTTP/1.1 200 OK
...
location: index.html

HTTP/1.1 200 OK
...


显然,第二个响应已完全由攻击者控制,攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应,从而发起多种形式的攻击,包括:cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement:攻击者可以向一个易受攻击的服务器发出一个请求,导致服务器创建两个响应,其中第二个响应可能会被曲解为对其他请求的响应,而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现:攻击者诱骗用户,让他们自己提交恶意请求;或在远程情况下,攻击者与用户共享同一个连接到服务器(如共享代理服务器)的 TCP 连接。最理想的情况是,攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击,进而对应用程序的安全性失去信心。最糟糕的情况是,攻击者可能提供经特殊技术处理的内容,这些内容旨在模仿应用程序的执行方式,但会重定向用户的私人信息(如帐号和密码),将这些信息发送给攻击者。

Cache Poisoning: 如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来,该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存(如在代理服务器中常见的缓存)中,那么使用该缓存的所有用户都会不断收到恶意内容,直到清除该缓存项为止。同样,如果响应缓存在单个用户的浏览器中,那么在清除该缓存项以前,该用户会不断收到恶意内容。然而,影响仅局限于本地浏览器的用户。

Cross-Site Scripting:一旦攻击者控制了应用程序传送的响应,就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式,这种攻击在响应中包含了恶意的 JavaScript 或其他代码,并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户,最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者,而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking:除了利用一个易受攻击的应用程序向用户传输恶意内容,还可以利用相同的根漏洞,将服务器生成的供用户使用的敏感内容重定向,转而供攻击者使用。攻击者通过提交一个会导致两个响应的请求,即服务器做出的预期响应和攻击者创建的响应,致使某个中间节点(如共享的代理服务器)误导服务器所生成的响应,将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应,第一个被解析为针对攻击者请求做出的响应,第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时,攻击者的请求已经在此处等候,并被解析为针对受害者这一请求的响应。这时,攻击者将第二个请求发送给服务器,代理服务器利用针对受害者(用户)的、由该服务器产生的这一请求对服务器做出响应,因此,针对受害者的这一响应中会包含所有头文件或正文中的敏感信息。

Cookie Manipulation:当与类似跨站请求伪造的攻击相结合时,攻击者就可以篡改、添加、甚至覆盖合法用户的 cookie。

Open Redirect:如果允许未验证的输入来控制重定向机制所使用的 URL,可能会有利于攻击者发动钓鱼攻击。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] 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
[35] 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
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.python.header_manipulation
Abstract
HTTP 响应头文件中包含未验证的数据会引发 cache-poisoning、cross-site scripting、cross-user defacement、page hijacking、cookie manipulation 或 open redirect。
Explanation
以下情况中会出现 Header Manipulation 漏洞:

1. 数据通过一个不可信赖的数据源进入 Web 应用程序,最常见的是 HTTP 请求。

2. 数据包含在一个 HTTP 响应头文件里,未经验证就发送给了 Web 用户。

如同许多软件安全漏洞一样,Header Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,这些漏洞是显而易见的:一个攻击者将恶意数据传送到易受攻击的应用程序,且该应用程序将数据包含在 HTTP 响应头文件中。

其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功地实施 HTTP Response Splitting 盗取,应用程序必须允许将那些包含 CR(回车,由 %0d 或 \r 指定)和 LF(换行,由 %0a 或 \n 指定)的字符输入到头文件中。攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文,还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 头文件感染恶意字符。例如,如果尝试使用被禁用的字符设置头文件,最新版本的 Apache Tomcat 会抛出 IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此必须在设置带有用户输入的 HTTP 头文件时采取措施。

示例:以下代码段会从 HTTP 请求中读取网络日志项的作者 author 的名字,并在发往站点另一部分的 Get 请求中使用它。


author = req.params[AUTHOR_PARAM]
http = Net::HTTP.new(URI("http://www.mysite.com"))
http.post('/index.php', "author=#{author}")


假设在请求中提交了一个由标准字母数字字符组成的字符串,例如“Jane Smith”,HTTP 响应可能表现为以下形式:


POST /index.php HTTP/1.1
Host: www.mysite.com
author=Jane Smith
...


然而,因为 URL 值是由未经验证的用户输入形成的,所以仅当提交给 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,例如“Wiley Hacker\r\nPOST /index.php HTTP/1.1\r\n...”,那么 HTTP 响应就会被分割成以下形式的两个响应:


POST /index.php HTTP/1.1
Host: www.mysite.com
author=Wiley Hacker

POST /index.php HTTP/1.1
...


显然,第二个响应已完全由攻击者控制,攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应,从而发起多种形式的攻击,包括:cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement:攻击者可以向一个易受攻击的服务器发出一个请求,导致服务器创建两个响应,其中第二个响应可能会被曲解为对其他请求的响应,而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现:攻击者诱骗用户,让他们自己提交恶意请求;或在远程情况下,攻击者与用户共享同一个连接到服务器(如共享代理服务器)的 TCP 连接。最理想的情况是,攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击,进而对应用程序的安全性失去信心。最糟糕的情况是,攻击者可能提供经特殊技术处理的内容,这些内容旨在模仿应用程序的执行方式,但会重定向用户的私人信息(如帐号和密码),将这些信息发送给攻击者。

缓存中毒: 如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来,该响应的破坏力会更大。如果响应被缓存在共享的 Web 缓存(如在代理服务器中常见的缓存)中,那么使用该缓存的所有用户都会不断收到恶意内容,直到清除该缓存项为止。同样,如果响应缓存在单个用户的浏览器中,那么在清除该缓存项以前,该用户会不断收到恶意内容。然而,影响仅局限于本地浏览器的用户。

Cross-Site Scripting:一旦攻击者控制了应用程序传送的响应,就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式,这种攻击在响应中包含了恶意的 JavaScript 或其他代码,并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户,最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者,而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking:除了利用一个易受攻击的应用程序向用户传输恶意内容,还可以利用相同的根漏洞,将服务器生成的供用户使用的敏感内容重定向,转而供攻击者使用。攻击者通过提交一个会导致两个响应的请求,即服务器做出的预期响应和攻击者创建的响应,致使某个中间节点(如共享的代理服务器)误导服务器所生成的响应,将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应,第一个被解析为针对攻击者请求做出的响应,第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时,攻击者的请求已经在此处等候,并被解析为针对受害者这一请求的响应。这时,攻击者将第二个请求发送给服务器,代理服务器利用针对受害者(用户)的、由该服务器产生的这一请求对服务器做出响应,因此,针对受害者的这一响应中会包含所有头文件或正文中的敏感信息。

Cookie Manipulation:当与类似跨站请求伪造的攻击相结合时,攻击者就可以篡改、添加、甚至覆盖合法用户的 cookie。

Open Redirect:如果允许未验证的输入来控制重定向机制所使用的 URL,可能会有利于攻击者发动钓鱼攻击。
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 113
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[9] Standards Mapping - FIPS200 SI
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[20] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[21] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[22] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 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 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] 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
[33] 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
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[55] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[56] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.ruby.header_manipulation
Abstract
HTTP 响应标头中包含未经验证的数据会招致 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect 攻击。
Explanation
Header Manipulation 漏洞会在以下情况下发生:

1. 数据通过不可信来源进入 Web 应用程序,最常见的是 HTTP 请求。

2. 数据包含在未经验证就发送给 Web 用户的 HTTP 响应标头中。

如同许多软件安全漏洞一样,Header Manipulation 只是通向终端的一个途径,它本身并不是终端。 从本质上看,这些漏洞是显而易见的:攻击者将恶意数据传送到易受攻击的应用程序,然后该应用程序将这些数据包含在 HTTP 响应标头中。

其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。 为了成功实施 HTTP Response Splitting 漏洞,该应用程序必须允许将包含 CR(回车符,也可以由 %0d 或 \r 指定)和 LF(换行符,也可以由 %0a 或 \n 指定)字符的输入包含在标头中。 攻击者不仅可以利用这些字符控制应用程序要发送的响应的剩余标头和正文,还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 标头感染恶意字符。 例如,如果尝试使用被禁用的字符设置标头,Play Framework 会抛出异常。 如果您的应用程序服务器能够防止设置带有换行符的标头,则其具备对 HTTP Response Splitting 的防御能力。 然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此在设置带有用户输入的 HTTP 标头时仍需小心谨慎。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] 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
[35] 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
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.scala.header_manipulation
Abstract
HTTP 响应头文件中包含未验证的数据会引发 cache-poisoning、cross-site scripting、cross-user defacement、page hijacking、cookie manipulation 或 open redirect。
Explanation
以下情况中会出现 Header Manipulation 漏洞:

1. 数据通过一个不可信赖的数据源进入 Web 应用程序,最常见的是 HTTP 请求。


2. 数据包含在一个 HTTP 响应头文件里,未经验证就发送给了 Web 用户。

如同许多软件安全漏洞一样,Header Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,这些漏洞是显而易见的:一个攻击者将恶意数据传送到易受攻击的应用程序,且该应用程序将数据包含在 HTTP 响应头文件中。

其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功地实施 HTTP Response Splitting 盗取,应用程序必须允许将那些包含 CR(回车,由 %0d 或 \r 指定)和 LF(换行,由 %0a 或 \n 指定)的字符输入到头文件中。攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文,还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 头文件感染恶意字符。例如,如果尝试使用被禁用的字符设置头文件,最新版本的 Apache Tomcat 会抛出 IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此必须在设置带有用户输入的 HTTP 头文件时采取措施。

示例:以下代码段假设 namevalue 可能会被攻击者控制。这段代码设置了一个名称和值可能被攻击者控制的 HTTP 标头。


...
var headers = []
headers[name] = value
let config = NSURLSessionConfiguration.backgroundSessionConfigurationWithIdentifier("com.acme")
config.HTTPAdditionalHeaders = headers
...


假设一个名称/值对由 authorJane Smith 组成,则包含此标头的 HTTP 响应可能会以这样的形式出现:


HTTP/1.1 200 OK
...
author:Jane Smith
...


但是,由于该标头的值由未经验证的用户输入组成,因此攻击者可以提交恶意的名称/值对,例如 HTTP/1.1 200 OK\r\n...foobar,于是该 HTTP 响应将会拆分为如下形式的两个响应:


HTTP/1.1 200 OK
...

HTTP/1.1 200 OK
...
foo:bar


显然,第二个响应已完全由攻击者控制,攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应,从而发起多种形式的攻击,包括:cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement:攻击者可以向一个易受攻击的服务器发出一个请求,导致服务器创建两个响应,其中第二个响应可能会被曲解为对其他请求的响应,而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现:攻击者诱骗用户,让他们自己提交恶意请求;或在远程情况下,攻击者与用户共享同一个连接到服务器(如共享代理服务器)的 TCP 连接。最理想的情况是,攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击,进而对应用程序的安全性失去信心。最糟糕的情况是,攻击者可能提供经特殊技术处理的内容,这些内容旨在模仿应用程序的执行方式,但会重定向用户的私人信息(如帐号和密码),将这些信息发送给攻击者。

缓存中毒:如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来,该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存(如在代理服务器中常见的缓存)中,那么使用该缓存的所有用户都会不断收到恶意内容,直到清除该缓存项为止。同样,如果响应缓存在单个用户的浏览器中,那么在清除该缓存项以前,该用户会不断收到恶意内容。然而,影响仅局限于本地浏览器的用户。

Cross-Site Scripting:一旦攻击者控制了应用程序传送的响应,就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式,这种攻击在响应中包含了恶意的 JavaScript 或其他代码,并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户,最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者,而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking:除了利用一个易受攻击的应用程序向用户传输恶意内容,还可以利用相同的根漏洞,将服务器生成的供用户使用的敏感内容重定向,转而供攻击者使用。攻击者通过提交一个会导致两个响应的请求,即服务器做出的预期响应和攻击者创建的响应,致使某个中间节点(如共享的代理服务器)误导服务器所生成的响应,将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应,第一个被解析为针对攻击者请求做出的响应,第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时,攻击者的请求已经在此处等候,并被解析为针对受害者这一请求的响应。这时,攻击者将第二个请求发送给服务器,代理服务器利用针对受害者(用户)的、由该服务器产生的这一请求对服务器做出响应,因此,针对受害者的这一响应中会包含所有头文件或正文中的敏感信息。

Cookie Manipulation:当与类似跨站请求伪造的攻击相结合时,攻击者就可以篡改、添加、甚至覆盖合法用户的 cookie。

Open Redirect:如果允许未验证的输入来控制重定向机制所使用的 URL,可能会有利于攻击者发动钓鱼攻击。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] 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
[35] 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
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.swift.header_manipulation
Abstract
HTTP 响应头文件中包含未验证的数据会引发 cache-poisoning、cross-site scripting、cross-user defacement、page hijacking、cookie manipulation 或 open redirect。
Explanation
以下情况中会出现 Header Manipulation 漏洞:

1. 数据通过一个不可信赖的数据源进入 Web 应用程序,最常见的是 HTTP 请求。

2. 数据包含在一个 HTTP 响应头文件里,未经验证就发送给了 Web 用户。

如同许多软件安全漏洞一样,Header Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,这些漏洞是显而易见的:一个攻击者将恶意数据传送到易受攻击的应用程序,且该应用程序将数据包含在 HTTP 响应头文件中。

其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功地实施 HTTP Response Splitting 盗取,应用程序必须允许将那些包含 CR(回车,由 %0d 或 \r 指定)和 LF(换行,由 %0a 或 \n 指定)的字符输入到头文件中。攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文,还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 头文件感染恶意字符,然而支持经典 ASP 的服务器通常不具备该保护机制。

示例:以下代码片段会从 HTTP 请求中读取网络日志项的作者名字 author,并将其置于一个 HTTP 响应的 Cookie 头文件中。


...
author = Request.Form(AUTHOR_PARAM)
Response.Cookies("author") = author
Response.Cookies("author").Expires = cookieExpiration
...


假设在请求中提交了一个字符串,该字符串由标准的字母数字字符组成,如“Jane Smith”,那么包含该 Cookie 的 HTTP 响应可能表现为以下形式:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


然而,因为 cookie 值来源于未经校验的用户输入,所以仅当提交给 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如“Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...”,那么 HTTP 响应就会被分割成以下形式的两个响应:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


显然,第二个响应已完全由攻击者控制,攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应,从而发起多种形式的攻击,包括:cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement:攻击者可以向一个易受攻击的服务器发出一个请求,导致服务器创建两个响应,其中第二个响应可能会被曲解为对其他请求的响应,而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现:攻击者诱骗用户,让他们自己提交恶意请求;或在远程情况下,攻击者与用户共享同一个连接到服务器(如共享代理服务器)的 TCP 连接。最理想的情况是,攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击,进而对应用程序的安全性失去信心。最糟糕的情况是,攻击者可能提供经特殊技术处理的内容,这些内容旨在模仿应用程序的执行方式,但会重定向用户的私人信息(如帐号和密码),将这些信息发送给攻击者。

缓存中毒:如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来,该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存(如在代理服务器中常见的缓存)中,那么使用该缓存的所有用户都会不断收到恶意内容,直到清除该缓存项为止。同样,如果响应缓存在单个用户的浏览器中,那么在清除该缓存项以前,该用户会不断收到恶意内容。然而,影响仅局限于本地浏览器的用户。

Cross-Site Scripting:一旦攻击者控制了应用程序传送的响应,就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式,这种攻击在响应中包含了恶意的 JavaScript 或其他代码,并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户,最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者,而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking:除了利用一个易受攻击的应用程序向用户传输恶意内容,还可以利用相同的根漏洞,将服务器生成的供用户使用的敏感内容重定向,转而供攻击者使用。攻击者通过提交一个会导致两个响应的请求,即服务器做出的预期响应和攻击者创建的响应,致使某个中间节点(如共享的代理服务器)误导服务器所生成的响应,将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应,第一个被解析为针对攻击者请求做出的响应,第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时,攻击者的请求已经在此处等候,并被解析为针对受害者这一请求的响应。这时,攻击者将第二个请求发送给服务器,代理服务器利用针对受害者(用户)的、由该服务器产生的这一请求对服务器做出响应,因此,针对受害者的这一响应中会包含所有头文件或正文中的敏感信息。

Cookie Manipulation:当与类似跨站请求伪造的攻击相结合时,攻击者就可以篡改、添加、甚至覆盖合法用户的 cookie。

Open Redirect:如果允许未验证的输入来控制重定向机制所使用的 URL,可能会有利于攻击者发动钓鱼攻击。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] 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
[35] 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
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.vb.header_manipulation
Abstract
在 Cookies 中包含未验证的数据会引发 HTTP 响应头文件操作攻击,并可能导致 cache-poisoning、cross-site scripting、cross-user defacement、page hijacking、cookie manipulation 或 open redirect。
Explanation
以下情况中会出现 Cookie Manipulation 漏洞:

1. 数据通过一个不可信赖的数据源进入 Web 应用程序,最常见的是 HTTP 请求。

2. 数据包含在一个 HTTP Cookie 中,该 Cookie 未经验证就发送给了 Web 用户。

如同许多软件安全漏洞一样,Cookie Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,这些漏洞是显而易见的:攻击者可将恶意数据传送到易受攻击的应用程序,且该应用程序将这些数据包含在 HTTP Cookie 中。

Cookie Manipulation:当与类似跨站请求伪造的攻击相结合时,攻击者就可以篡改、添加、甚至覆盖合法用户的 cookie。

作为 HTTP 响应头文件,Cookie Manipulation 攻击也可导致其他类型的攻击,例如:

HTTP Response Splitting:
其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功地实施 HTTP Response Splitting 盗取,应用程序必须允许将那些包含 CR(回车,由 %0d 或 \r 指定)和 LF(换行,由 %0a 或 \n 指定)的字符输入到头文件中。攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文,还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 头文件感染恶意字符。例如,如果尝试使用被禁用的字符设置头文件,最新版本的 Apache Tomcat 会抛出 IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此必须在设置带有用户输入的 HTTP 头文件时采取措施。

示例:下列代码片段会从 HTTP 请求中读取网络日志项的作者名字 author,并将其置于一个 HTTP 响应的 cookie 头文件中。


...
author = request->get_form_field( 'author' ).
response->set_cookie( name = 'author' value = author ).
...


假设在请求中提交了一个字符串,该字符串由标准的字母数字字符组成,如“Jane Smith”,那么包含该 Cookie 的 HTTP 响应可能表现为以下形式:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


然而,因为 cookie 值来源于未经校验的用户输入,所以仅当提交给 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如“Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...”,那么 HTTP 响应就会被分割成以下形式的两个响应:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


显然,第二个响应已完全由攻击者控制,攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应,从而发起多种形式的攻击,包括:cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement:攻击者可以向一个易受攻击的服务器发出一个请求,导致服务器创建两个响应,其中第二个响应可能会被曲解为对其他请求的响应,而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现:攻击者诱骗用户,让他们自己提交恶意请求;或在远程情况下,攻击者与用户共享同一个连接到服务器(如共享代理服务器)的 TCP 连接。最理想的情况是,攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击,进而对应用程序的安全性失去信心。最糟糕的情况是,攻击者可能提供经特殊技术处理的内容,这些内容旨在模仿应用程序的执行方式,但会重定向用户的私人信息(如帐号和密码),将这些信息发送给攻击者。

缓存中毒: 如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来,该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存(如在代理服务器中常见的缓存)中,那么使用该缓存的所有用户都会不断收到恶意内容,直到清除该缓存项为止。同样,如果响应缓存在单个用户的浏览器中,那么在清除该缓存项以前,该用户会不断收到恶意内容。然而,影响仅局限于本地浏览器的用户。

Cross-Site Scripting:一旦攻击者控制了应用程序传送的响应,就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式,这种攻击在响应中包含了恶意的 JavaScript 或其他代码,并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户,最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者,而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking:除了利用一个易受攻击的应用程序向用户传输恶意内容,还可以利用相同的根漏洞,将服务器生成的供用户使用的敏感内容重定向,转而供攻击者使用。攻击者通过提交一个会导致两个响应的请求,即服务器做出的预期响应和攻击者创建的响应,致使某个中间节点(如共享的代理服务器)误导服务器所生成的响应,将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应,第一个被解析为针对攻击者请求做出的响应,第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时,攻击者的请求已经在此处等候,并被解析为针对受害者这一请求的响应。这时,攻击者将第二个请求发送给服务器,代理服务器利用针对受害者(用户)的、由该服务器产生的这一请求对服务器做出响应,因此,针对受害者的这一响应中会包含所有头文件或正文中的敏感信息。

Open Redirect:如果允许未验证的输入来控制重定向机制所使用的 URL,可能会有利于攻击者发动钓鱼攻击。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] 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
[35] 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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.abap.header_manipulation_cookies
Abstract
在 Cookie 中包含未经验证的数据会引发 HTTP Response Header Manipulation 攻击,并可能导致 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect。
Explanation
Cookie Manipulation 漏洞会在以下情况下发生:

1.数据通过不可信数据源进入 Web 应用程序,最常见的是通过 HTTP 请求。



2.数据包含在未经验证就发送给 Web 用户的 HTTP Cookie 中。



如同许多软件安全漏洞一样,Cookie Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,这些漏洞是显而易见的:攻击者可将恶意数据传送到易受攻击的应用程序,然后该应用程序将这些数据包含在 HTTP Cookie 中。

Cookie Manipulation:当与 Cross-Site Request Forgery 等类似攻击相结合时,攻击者可能会篡改、添加甚至覆盖合法用户的 Cookie。

作为 HTTP 响应标头,Cookie Manipulation 攻击也可导致其他类型的攻击,例如:

HTTP Response Splitting:
其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功实施 HTTP Response Splitting 漏洞,该应用程序必须允许将包含 CR(回车符,也可以由 %0d 或 \r 指定)和 LF(换行符,也可以由 %0a 或 \n 指定)字符的输入包含在标头中。攻击者不仅可以利用这些字符控制应用程序要发送的响应的剩余标头和正文,还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 标头中注入恶意字符。例如,如果尝试使用被禁用的字符设置标头,最新版本的 Apache Tomcat 会抛出 IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的标头,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此在设置带有用户输入的 HTTP 标头时仍需小心谨慎。

示例 1:以下代码片段会从 HTTP 请求中读取网络日志项的作者名字 author,并将其置于一个 HTTP 响应的 Cookie 标头中。


...
Cookie cookie = new Cookie('author', author, '/', -1, false);
ApexPages.currentPage().setCookies(new Cookie[] {cookie});
...


假设在请求中提交了一个字符串,该字符串由标准的字母数字字符组成,如“Jane Smith”,那么包含该 Cookie 的 HTTP 响应可能表现为以下形式:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


然而,因为 Cookie 值来源于未经校验的用户输入,所以仅当提交给 author 的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如“Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...”,那么 HTTP 响应将被分割成以下形式的两个响应:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


显然,第二个响应已完全由攻击者控制,攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应,从而发起多种形式的攻击,包括:cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement:攻击者可以向一个易受攻击的服务器发出一个请求,该请求将导致服务器创建两个响应,其中第二个响应可能会被曲解为对其他请求的响应,而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现:攻击者诱骗用户,让他们自己提交恶意请求;或在远程情况下,攻击者与用户共享同一个连接到服务器(如共享代理服务器)的 TCP 连接。最理想的情况是,攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击,进而对应用程序的安全性失去信心。最糟糕的情况是,攻击者可能提供经特殊技术处理的内容,这些内容旨在模仿应用程序的执行方式,但会重定向用户的私人信息(如帐号和密码),将这些信息发送给攻击者。

Cache Poisoning:如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来,该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存(如在代理服务器中常见的缓存)中,那么使用该缓存的所有用户都会不断收到恶意内容,直到清除该缓存项为止。同样,如果响应缓存在单个用户的浏览器中,那么在清除该缓存项以前,该用户会不断收到恶意内容。然而,影响将仅局限于本地浏览器的用户。

Cross-Site Scripting:一旦攻击者控制了应用程序传送的响应,就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式,这种攻击在响应中包含了恶意的 JavaScript 或其他代码,并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户,最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者,而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking:除了利用一个易受攻击的应用程序向用户传输恶意内容,还可以利用相同的根漏洞,将服务器生成的供用户使用的敏感内容重定向,转而供攻击者使用。攻击者通过提交一个会产生两个响应的请求,即服务器做出的预期响应和攻击者创建的响应,致使某个中间节点(如共享的代理服务器)误导服务器所生成的响应,将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应,第一个被解析为针对攻击者请求做出的响应,第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时,攻击者的请求已经在此处等候,并被解析为针对受害者这一请求的响应。这时,攻击者将第二个请求发送给服务器,代理服务器利用针对受害者(用户)的、由该服务器产生的这一请求对服务器做出响应。因此,针对受害者的这一响应中会包含所有标头或正文中的敏感信息。

Open Redirect:如果允许未验证的输入控制重定向机制所使用的 URL,可能会有利于攻击者发动钓鱼攻击。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] 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
[35] 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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.apex.header_manipulation_cookies
Abstract
在 Cookies 中包含未验证的数据会引发 HTTP 响应头文件操作攻击,并可能导致 cache-poisoning、cross-site scripting、cross-user defacement、page hijacking、cookie manipulation 或 open redirect。
Explanation
以下情况中会出现 Cookie Manipulation 漏洞:

1. 数据通过一个不可信赖的数据源进入 Web 应用程序,最常见的是 HTTP 请求。

2. 数据包含在一个 HTTP Cookie 中,该 Cookie 未经验证就发送给了 Web 用户。

如同许多软件安全漏洞一样,Cookie Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,这些漏洞是显而易见的:攻击者可将恶意数据传送到易受攻击的应用程序,然后该应用程序将这些数据包含在 HTTP Cookie 中。

Cookie Manipulation:当与类似跨站请求伪造的攻击相结合时,攻击者就可以篡改、添加、甚至覆盖合法用户的 cookie。

作为 HTTP 响应头文件,Cookie Manipulation 攻击也可导致其他类型的攻击,例如:

HTTP Response Splitting:
其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功地实施 HTTP Response Splitting 盗取,应用程序必须允许将那些包含 CR(回车,由 %0d 或 \r 指定)和 LF(换行,由 %0a 或 \n 指定)的字符输入到头文件中。攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文,还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 头文件感染恶意字符。例如,如果尝试使用被禁用的字符设置头文件,最新版本的 Apache Tomcat 会抛出 IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此必须在设置带有用户输入的 HTTP 头文件时采取措施。

示例:以下代码片段会从 HTTP 请求中读取网络日志项的作者名字 author,并将其置于一个 HTTP 响应的 Cookie 头文件中。


protected System.Web.UI.WebControls.TextBox Author;
...
string author = Author.Text;
Cookie cookie = new Cookie("author", author);
...


假设在请求中提交了一个字符串,该字符串由标准的字母数字字符组成,如“Jane Smith”,那么包含该 Cookie 的 HTTP 响应可能表现为以下形式:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


然而,因为 cookie 值来源于未经校验的用户输入,所以仅当提交给 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如“Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...”,那么 HTTP 响应就会被分割成以下形式的两个响应:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


显然,第二个响应已完全由攻击者控制,攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应,从而发起多种形式的攻击,包括:cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement:攻击者可以向一个易受攻击的服务器发出一个请求,导致服务器创建两个响应,其中第二个响应可能会被曲解为对其他请求的响应,而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现:攻击者诱骗用户,让他们自己提交恶意请求;或在远程情况下,攻击者与用户共享同一个连接到服务器(如共享代理服务器)的 TCP 连接。最理想的情况是,攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击,进而对应用程序的安全性失去信心。最糟糕的情况是,攻击者可能提供经特殊技术处理的内容,这些内容旨在模仿应用程序的执行方式,但会重定向用户的私人信息(如帐号和密码),将这些信息发送给攻击者。

缓存中毒:如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来,该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存(如在代理服务器中常见的缓存)中,那么使用该缓存的所有用户都会不断收到恶意内容,直到清除该缓存项为止。同样,如果响应缓存在单个用户的浏览器中,那么在清除该缓存项以前,该用户会不断收到恶意内容。然而,影响仅局限于本地浏览器的用户。

Cross-Site Scripting:一旦攻击者控制了应用程序传送的响应,就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式,这种攻击在响应中包含了恶意的 JavaScript 或其他代码,并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户,最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者,而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking:除了利用一个易受攻击的应用程序向用户传输恶意内容,还可以利用相同的根漏洞,将服务器生成的供用户使用的敏感内容重定向,转而供攻击者使用。攻击者通过提交一个会导致两个响应的请求,即服务器做出的预期响应和攻击者创建的响应,致使某个中间节点(如共享的代理服务器)误导服务器所生成的响应,将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应,第一个被解析为针对攻击者请求做出的响应,第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时,攻击者的请求已经在此处等候,并被解析为针对受害者这一请求的响应。这时,攻击者将第二个请求发送给服务器,代理服务器利用针对受害者(用户)的、由该服务器产生的这一请求对服务器做出响应,因此,针对受害者的这一响应中会包含所有头文件或正文中的敏感信息。

Open Redirect:如果允许未验证的输入来控制重定向机制所使用的 URL,可能会有利于攻击者发动钓鱼攻击。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] 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
[35] 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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.dotnet.header_manipulation_cookies
Abstract
在 Cookies 中包含未验证的数据会引发 HTTP 响应头文件操作攻击,并可能导致 cache-poisoning、cross-site scripting、cross-user defacement、page hijacking、cookie manipulation 或 open redirect。
Explanation
以下情况中会出现 Cookie Manipulation 漏洞:

1. 数据通过一个不可信赖的数据源进入 Web 应用程序,最常见的是 HTTP 请求。

2. 数据包含在一个 HTTP Cookie 中,该 Cookie 未经验证就发送给了 Web 用户。

如同许多软件安全漏洞一样,Cookie Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,这些漏洞是显而易见的:攻击者可将恶意数据传送到易受攻击的应用程序,且该应用程序将这些数据包含在 HTTP Cookie 中。

Cookie Manipulation:当与类似跨站请求伪造的攻击相结合时,攻击者就可以篡改、添加、甚至覆盖合法用户的 cookie。

作为 HTTP 响应头文件,Cookie Manipulation 攻击也可导致其他类型的攻击,例如:

HTTP Response Splitting:
其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功地实施 HTTP Response Splitting 盗取,应用程序必须允许将那些包含 CR(回车,由 %0d 或 \r 指定)和 LF(换行,由 %0a 或 \n 指定)的字符输入到头文件中。攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文,还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 头文件感染恶意字符。例如,如果尝试使用被禁用的字符设置头文件,最新版本的 Apache Tomcat 会抛出 IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此必须在设置带有用户输入的 HTTP 头文件时采取措施。

示例:下列代码片段会从 HTTP 请求中读取网络日志项的作者名字 author,并将其置于一个 HTTP 响应的 cookie 头文件中。


<cfcookie name = "author"
value = "#Form.author#"
expires = "NOW">


假设在请求中提交了一个字符串,该字符串由标准的字母数字字符组成,如“Jane Smith”,那么包含该 Cookie 的 HTTP 响应可能表现为以下形式:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


然而,因为 cookie 值来源于未经校验的用户输入,所以仅当提交给 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n......",那么 HTTP 响应就会被分割成以下形式的两个响应:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


显然,第二个响应已完全由攻击者控制,攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应,从而发起多种形式的攻击,包括:cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement:攻击者可以向一个易受攻击的服务器发出一个请求,导致服务器创建两个响应,其中第二个响应可能会被曲解为对其他请求的响应,而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现:攻击者诱骗用户,让他们自己提交恶意请求;或在远程情况下,攻击者与用户共享同一个连接到服务器(如共享代理服务器)的 TCP 连接。最理想的情况是,攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击,进而对应用程序的安全性失去信心。最糟糕的情况是,攻击者可能提供经特殊技术处理的内容,这些内容旨在模仿应用程序的执行方式,但会重定向用户的私人信息(如帐号和密码),将这些信息发送给攻击者。

Cache Poisoning: 如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来,该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存(如在代理服务器中常见的缓存)中,那么使用该缓存的所有用户都会不断收到恶意内容,直到清除该缓存项为止。同样,如果响应缓存在单个用户的浏览器中,那么在清除该缓存项以前,该用户会不断收到恶意内容。然而,影响仅局限于本地浏览器的用户。

Cross-Site Scripting:一旦攻击者控制了应用程序传送的响应,就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式,这种攻击在响应中包含了恶意的 JavaScript 或其他代码,并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户,最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者,而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking:除了利用一个易受攻击的应用程序向用户传输恶意内容,还可以利用相同的根漏洞,将服务器生成的供用户使用的敏感内容重定向,转而供攻击者使用。攻击者通过提交一个会导致两个响应的请求,即服务器做出的预期响应和攻击者创建的响应,致使某个中间节点(如共享的代理服务器)误导服务器所生成的响应,将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应,第一个被解析为针对攻击者请求做出的响应,第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时,攻击者的请求已经在此处等候,并被解析为针对受害者这一请求的响应。这时,攻击者将第二个请求发送给服务器,代理服务器利用针对受害者(用户)的、由该服务器产生的这一请求对服务器做出响应,因此,针对受害者的这一响应中会包含所有头文件或正文中的敏感信息。

Open Redirect:如果允许未验证的输入来控制重定向机制所使用的 URL,可能会有利于攻击者发动钓鱼攻击。
References
[1] Amit Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] Diabolic Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] 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
[35] 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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.cfml.header_manipulation_cookies
Abstract
在 Cookie 中包含未经验证的数据会引发 HTTP Response Header Manipulation 攻击,并可能导致 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect。
Explanation
Cookie Manipulation 漏洞会在以下情况下发生:

1.数据通过不可信来源进入 Web 应用程序,最常见的是 HTTP 请求。

2.数据包含在未经验证就发送给 Web 用户的 HTTP Cookie 中。

如同许多软件安全漏洞一样,Cookie Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,这些漏洞是显而易见的:攻击者可将恶意数据传送到易受攻击的应用程序,然后该应用程序将这些数据包含在 HTTP Cookie 中。

Cookie Manipulation:当与类似 Cross-Site Request Forgery 的攻击相结合时,攻击者就可以篡改、添加甚至覆盖合法用户的 Cookie。

作为 HTTP 响应标头,Cookie Manipulation 攻击也可导致其他类型的攻击,例如:

HTTP Response Splitting:
其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功实施 HTTP Response Splitting 漏洞,该应用程序必须允许将包含 CR(回车符,也可以由 %0d 或 \r 指定)和 LF(换行符,也可以由 %0a 或 \n 指定)字符的输入包含在标头中。攻击者不仅可以利用这些字符控制应用程序要发送的响应的剩余标头和正文,还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 标头感染恶意字符。例如,如果尝试使用被禁用的字符设置标头,最新版本的 Apache Tomcat 会抛出 IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的标头,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此在设置带有用户输入的 HTTP 标头时仍需小心谨慎。

示例:以下代码片段会从 HTTP 请求中读取网络日志项的作者名字 author,并将其置于一个 HTTP 响应的 Cookie 标头中。


...
author := request.FormValue("AUTHOR_PARAM")
cookie := http.Cookie{
Name: "author",
Value: author,
Domain: "www.example.com",
}
http.SetCookie(w, &cookie)
...


假设在请求中提交了一个字符串,该字符串由标准的字母数字字符组成,如“Jane Smith”,那么包含该 Cookie 的 HTTP 响应可能表现为以下形式:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


然而,因为 Cookie 值来源于未经校验的用户输入,所以仅当提交给 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...",那么 HTTP 响应就会被分割成以下形式的两个响应:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


显然,第二个响应已完全由攻击者控制,攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应,从而发起多种形式的攻击,包括:cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement:攻击者可以向一个易受攻击的服务器发出一个请求,导致服务器创建两个响应,其中第二个响应可能会被曲解为对其他请求的响应,而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现:攻击者诱骗用户,让他们自己提交恶意请求;或在远程情况下,攻击者与用户共享同一个连接到服务器(如共享代理服务器)的 TCP 连接。最理想的情况是,攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击,进而对应用程序的安全性失去信心。最糟糕的情况是,攻击者可能提供经特殊技术处理的内容,这些内容旨在模仿应用程序的执行方式,但会重定向用户的私人信息(如帐号和密码),将这些信息发送给攻击者。

Cache Poisoning:如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来,该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存(如在代理服务器中常见的缓存)中,那么使用该缓存的所有用户都会不断收到恶意内容,直到清除该缓存项为止。同样,如果响应缓存在单个用户的浏览器中,那么在清除该缓存项以前,该用户会不断收到恶意内容。然而,影响仅局限于本地浏览器的用户。

Cross-Site Scripting:攻击者控制了应用程序传送的响应后,就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式,这种攻击在响应中包含了恶意的 JavaScript 或其他代码,并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户,最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者,而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking:除了利用一个易受攻击的应用程序向用户传输恶意内容,攻击者还可以利用相同的根漏洞,将服务器生成的供用户使用的敏感内容重定向,转而供攻击者使用。攻击者通过提交一个会产生两个响应的请求,即服务器做出的预期响应和攻击者创建的响应,致使某个中间节点(如共享的代理服务器)误导服务器所生成的响应,将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应,第一个被解析为针对攻击者请求做出的响应,第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时,攻击者的请求已经在此处等候,并被解析为针对受害者这一请求的响应。这时,攻击者将第二个请求发送给服务器,代理服务器利用针对受害者(用户)的、由该服务器产生的这一请求对服务器做出响应。因此,针对受害者的这一响应中会包含所有标头或正文中的敏感信息。

Open Redirect:如果允许未验证的输入控制重定向机制所使用的 URL,可能会有利于攻击者发动钓鱼攻击。
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 113
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[9] Standards Mapping - FIPS200 SI
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[20] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[21] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[22] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 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 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] 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
[33] 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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[55] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[56] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.golang.header_manipulation_cookies
Abstract
在 Cookies 中包含未验证的数据会引发 HTTP 响应头文件操作攻击,并可能导致 cache-poisoning、cross-site scripting、cross-user defacement、page hijacking、cookie manipulation 或 open redirect。
Explanation
以下情况中会出现 Cookie Manipulation 漏洞:

1. 数据通过一个不可信赖的数据源进入 Web 应用程序,最常见的是 HTTP 请求。

2. 数据包含在一个 HTTP Cookie 中,该 Cookie 未经验证就发送给了 Web 用户。

如同许多软件安全漏洞一样,Cookie Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,这些漏洞是显而易见的:攻击者可将恶意数据传送到易受攻击的应用程序,且该应用程序将这些数据包含在 HTTP Cookie 中。

Cookie Manipulation:当与类似跨站请求伪造的攻击相结合时,攻击者就可以篡改、添加、甚至覆盖合法用户的 cookie。

作为 HTTP 响应头文件,Cookie Manipulation 攻击也可导致其他类型的攻击,例如:

HTTP Response Splitting:
其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功地实施 HTTP Response Splitting 盗取,应用程序必须允许将那些包含 CR(回车,由 %0d 或 \r 指定)和 LF(换行,由 %0a 或 \n 指定)的字符输入到头文件中。攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文,还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 头文件感染恶意字符。例如,如果尝试使用被禁用的字符设置头文件,最新版本的 Apache Tomcat 会抛出 IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此必须在设置带有用户输入的 HTTP 头文件时采取措施。

例 1:下列代码片段会从 HTTP 请求中读取网络日志项的作者名字 author,并将其置于一个 HTTP 响应的 cookie 头文件中。


String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);


假设在请求中提交了一个字符串,该字符串由标准的字母数字字符组成,如“Jane Smith”,那么包含该 Cookie 的 HTTP 响应可能表现为以下形式:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


然而,因为 cookie 值来源于未经校验的用户输入,所以仅当提交给 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如“Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...”,那么 HTTP 响应就会被分割成以下形式的两个响应:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


显然,第二个响应已完全由攻击者控制,攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应,从而发起多种形式的攻击,包括:cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

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

示例 2:以下代码会调整Example 1 以适应 Android 平台。


...
CookieManager webCookieManager = CookieManager.getInstance();
String author = this.getIntent().getExtras().getString(AUTHOR_PARAM);
String setCookie = "author=" + author + "; max-age=" + cookieExpiration;
webCookieManager.setCookie(url, setCookie);

...
Cross-User Defacement:攻击者可以向一个易受攻击的服务器发出一个请求,导致服务器创建两个响应,其中第二个响应可能会被曲解为对其他请求的响应,而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现:攻击者诱骗用户,让他们自己提交恶意请求;或在远程情况下,攻击者与用户共享同一个连接到服务器(如共享代理服务器)的 TCP 连接。最理想的情况是,攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击,进而对应用程序的安全性失去信心。最糟糕的情况是,攻击者可能提供经特殊技术处理的内容,这些内容旨在模仿应用程序的执行方式,但会重定向用户的私人信息(如帐号和密码),将这些信息发送给攻击者。

缓存中毒: 如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来,该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存(如在代理服务器中常见的缓存)中,那么使用该缓存的所有用户都会不断收到恶意内容,直到清除该缓存项为止。同样,如果响应缓存在单个用户的浏览器中,那么在清除该缓存项以前,该用户会不断收到恶意内容。然而,影响仅局限于本地浏览器的用户。

Cross-Site Scripting:一旦攻击者控制了应用程序传送的响应,就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式,这种攻击在响应中包含了恶意的 JavaScript 或其他代码,并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户,最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者,而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking:除了利用一个易受攻击的应用程序向用户传输恶意内容,还可以利用相同的根漏洞,将服务器生成的供用户使用的敏感内容重定向,转而供攻击者使用。攻击者通过提交一个会导致两个响应的请求,即服务器做出的预期响应和攻击者创建的响应,致使某个中间节点(如共享的代理服务器)误导服务器所生成的响应,将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应,第一个被解析为针对攻击者请求做出的响应,第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时,攻击者的请求已经在此处等候,并被解析为针对受害者这一请求的响应。这时,攻击者将第二个请求发送给服务器,代理服务器利用针对受害者(用户)的、由该服务器产生的这一请求对服务器做出响应,因此,针对受害者的这一响应中会包含所有头文件或正文中的敏感信息。

打开重定向:如果允许未验证的输入来控制重定向机制所使用的 URL,可能会有利于攻击者发动钓鱼攻击。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] 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
[35] 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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.java.header_manipulation_cookies
Abstract
在 Cookies 中包含未验证的数据会引发 HTTP 响应头文件操作攻击,并可能导致 cache-poisoning、cross-site scripting、cross-user defacement、page hijacking、cookie manipulation 或 open redirect。
Explanation
以下情况中会出现 Cookie Manipulation 漏洞:

1. 数据通过一个不可信赖的数据源进入 Web 应用程序,最常见的是 HTTP 请求。

2. 数据包含在一个 HTTP Cookie 中,该 Cookie 未经验证就发送给了 Web 用户。

如同许多软件安全漏洞一样,Cookie Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,这些漏洞是显而易见的:攻击者可将恶意数据传送到易受攻击的应用程序,然后该应用程序将这些数据包含在 HTTP Cookie 中。

Cookie Manipulation:当与类似跨站请求伪造的攻击相结合时,攻击者就可以篡改、添加、甚至覆盖合法用户的 cookie。

作为 HTTP 响应头文件,Cookie Manipulation 攻击也可导致其他类型的攻击,例如:

HTTP Response Splitting:
其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功地实施 HTTP Response Splitting 盗取,应用程序必须允许将那些包含 CR(回车,由 %0d 或 \r 指定)和 LF(换行,由 %0a 或 \n 指定)的字符输入到头文件中。攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文,还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 头文件感染恶意字符。例如,如果尝试使用被禁用的字符设置头文件,最新版本的 Apache Tomcat 会抛出 IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此必须在设置带有用户输入的 HTTP 头文件时采取措施。

示例:下列代码片段会从 HTTP 请求中读取网络日志项的作者名字 author,并将其置于一个 HTTP 响应的 cookie 头文件中。


author = form.author.value;
...
document.cookie = "author=" + author + ";expires="+cookieExpiration;
...


假设在请求中提交了一个字符串,该字符串由标准的字母数字字符组成,如“Jane Smith”,那么包含该 Cookie 的 HTTP 响应可能表现为以下形式:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


然而,因为 cookie 值来源于未经校验的用户输入,所以仅当提交给 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n......",那么 HTTP 响应就会被分割成以下形式的两个响应:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


显然,第二个响应已完全由攻击者控制,攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应,从而发起多种形式的攻击,包括:cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement:攻击者可以向一个易受攻击的服务器发出一个请求,该请求将导致服务器创建两个响应,其中第二个响应可能会被曲解为对其他请求的响应,而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现:攻击者诱骗用户,让他们自己提交恶意请求;或在远程情况下,攻击者与用户共享同一个连接到服务器(如共享代理服务器)的 TCP 连接。最理想的情况是,攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击,进而对应用程序的安全性失去信心。最糟糕的情况是,攻击者可能提供经特殊技术处理的内容,这些内容旨在模仿应用程序的执行方式,但会重定向用户的私人信息(如帐号和密码),将这些信息发送给攻击者。

Cache Poisoning: 如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来,该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存(如在代理服务器中常见的缓存)中,那么使用该缓存的所有用户都会不断收到恶意内容,直到清除该缓存项为止。同样,如果响应缓存在单个用户的浏览器中,那么在清除该缓存项以前,该用户会不断收到恶意内容。然而,影响仅局限于本地浏览器的用户。

Cross-Site Scripting:一旦攻击者控制了应用程序传送的响应,就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式,这种攻击在响应中包含了恶意的 JavaScript 或其他代码,并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户,最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者,而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking:除了利用一个易受攻击的应用程序向用户传输恶意内容,还可以利用相同的根漏洞,将服务器生成的供用户使用的敏感内容重定向,转而供攻击者使用。攻击者通过提交一个会导致两个响应的请求,即服务器做出的预期响应和攻击者创建的响应,致使某个中间节点(如共享的代理服务器)误导服务器所生成的响应,将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应,第一个被解析为针对攻击者请求做出的响应,第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时,攻击者的请求已经在此处等候,并被解析为针对受害者这一请求的响应。这时,攻击者将第二个请求发送给服务器,代理服务器利用针对受害者(用户)的、由该服务器产生的这一请求对服务器做出响应,因此,针对受害者的这一响应中会包含所有头文件或正文中的敏感信息。

Open Redirect:如果允许未验证的输入来控制重定向机制所使用的 URL,可能会有利于攻击者发动钓鱼攻击。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] 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
[35] 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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.javascript.header_manipulation_cookies
Abstract
在 Cookies 中包含未验证的数据会引发 HTTP 响应头文件操作攻击,并可能导致 cache-poisoning、cross-site scripting、cross-user defacement、page hijacking、cookie manipulation 或 open redirect。
Explanation
以下情况中会出现 Cookie Manipulation 漏洞:

1. 数据通过一个不可信赖的数据源进入 Web 应用程序,最常见的是 HTTP 请求。

2. 数据包含在一个 HTTP Cookie 中,该 Cookie 未经验证就发送给了 Web 用户。

如同许多软件安全漏洞一样,Cookie Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,这些漏洞是显而易见的:攻击者可将恶意数据传送到易受攻击的应用程序,且该应用程序将这些数据包含在 HTTP Cookie 中。

Cookie Manipulation:当与类似跨站请求伪造的攻击相结合时,攻击者就可以篡改、添加、甚至覆盖合法用户的 cookie。

作为 HTTP 响应头文件,Cookie Manipulation 攻击也可导致其他类型的攻击,例如:

HTTP Response Splitting:
其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功地实施 HTTP Response Splitting 盗取,应用程序必须允许将那些包含 CR(回车,由 %0d 或 \r 指定)和 LF(换行,由 %0a 或 \n 指定)的字符输入到头文件中。攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文,还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 头文件感染恶意字符。例如,如果尝试使用被禁用的字符设置头文件,最新版本的 Apache Tomcat 会抛出 IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此必须在设置带有用户输入的 HTTP 头文件时采取措施。

示例:下列代码片段会从 HTTP 请求中读取网络日志项的作者名字 author,并将其置于一个 HTTP 响应的 cookie 头文件中。


<?php
$author = $_GET['AUTHOR_PARAM'];
...
header("author: $author");
?>


假设在请求中提交了一个字符串,该字符串由标准的字母数字字符组成,如“Jane Smith”,那么包含该 Cookie 的 HTTP 响应可能表现为以下形式:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


然而,因为 cookie 值来源于未经校验的用户输入,所以仅当提交给 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n......",那么 HTTP 响应就会被分割成以下形式的两个响应:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


显然,第二个响应已完全由攻击者控制,攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应,从而发起多种形式的攻击,包括:cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement:攻击者可以向一个易受攻击的服务器发出一个请求,导致服务器创建两个响应,其中第二个响应可能会被曲解为对其他请求的响应,而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现:攻击者诱骗用户,让他们自己提交恶意请求;或在远程情况下,攻击者与用户共享同一个连接到服务器(如共享代理服务器)的 TCP 连接。最理想的情况是,攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击,进而对应用程序的安全性失去信心。最糟糕的情况是,攻击者可能提供经特殊技术处理的内容,这些内容旨在模仿应用程序的执行方式,但会重定向用户的私人信息(如帐号和密码),将这些信息发送给攻击者。

Cache Poisoning: 如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来,该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存(如在代理服务器中常见的缓存)中,那么使用该缓存的所有用户都会不断收到恶意内容,直到清除该缓存项为止。同样,如果响应缓存在单个用户的浏览器中,那么在清除该缓存项以前,该用户会不断收到恶意内容。然而,影响仅局限于本地浏览器的用户。

Cross-Site Scripting:一旦攻击者控制了应用程序传送的响应,就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式,这种攻击在响应中包含了恶意的 JavaScript 或其他代码,并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户,最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者,而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking:除了利用一个易受攻击的应用程序向用户传输恶意内容,还可以利用相同的根漏洞,将服务器生成的供用户使用的敏感内容重定向,转而供攻击者使用。攻击者通过提交一个会导致两个响应的请求,即服务器做出的预期响应和攻击者创建的响应,致使某个中间节点(如共享的代理服务器)误导服务器所生成的响应,将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应,第一个被解析为针对攻击者请求做出的响应,第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时,攻击者的请求已经在此处等候,并被解析为针对受害者这一请求的响应。这时,攻击者将第二个请求发送给服务器,代理服务器利用针对受害者(用户)的、由该服务器产生的这一请求对服务器做出响应,因此,针对受害者的这一响应中会包含所有头文件或正文中的敏感信息。

Open Redirect:如果允许未验证的输入来控制重定向机制所使用的 URL,可能会有利于攻击者发动钓鱼攻击。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] 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
[35] 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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.php.header_manipulation_cookies
Abstract
HTTP 响应头文件中包含未验证的数据会引发 cache-poisoning、cross-site scripting、cross-user defacement、page hijacking、cookie manipulation 或 open redirect。
Explanation
以下情况中会出现 Header Manipulation 漏洞:

1. 数据通过一个不可信赖的数据源进入 Web 应用程序,最常见的是 HTTP 请求。

2. 数据包含在一个 HTTP 响应头文件里,未经验证就发送给了 Web 用户。

如同许多软件安全漏洞一样,Header Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,这些漏洞是显而易见的:一个攻击者将恶意数据传送到易受攻击的应用程序,且该应用程序将数据包含在 HTTP 响应头文件中。

其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功地实施 HTTP Response Splitting 盗取,应用程序必须允许将那些包含 CR(回车,由 %0d 或 \r 指定)和 LF(换行,由 %0a 或 \n 指定)的字符输入到头文件中。攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文,还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 头文件感染恶意字符。如果您的应用程序服务器能够防止设置带有换行符的头文件,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此必须在设置带有用户输入的 HTTP 头文件时采取措施。

示例:下段代码会从 HTTP 请求读取位置,并将其设置到 HTTP 响应的位置字段的头文件中。


location = req.field('some_location')
...
response.addHeader("location",location)


假设在请求中提交了一个由标准字母数字字符组成的字符串,如“index.html”,则包含该 Cookie 的 HTTP 响应可能表现为以下形式:


HTTP/1.1 200 OK
...
location: index.html
...


然而,因为该位置的值由未经验证的用户输入组成,所以仅当提交给 some_location 的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如“index.html\r\nHTTP/1.1 200 OK\r\n...”,那么 HTTP 响应就会被分割成以下形式的两个响应:


HTTP/1.1 200 OK
...
location: index.html

HTTP/1.1 200 OK
...


显然,第二个响应已完全由攻击者控制,攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应,从而发起多种形式的攻击,包括:cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement:攻击者可以向一个易受攻击的服务器发出一个请求,导致服务器创建两个响应,其中第二个响应可能会被曲解为对其他请求的响应,而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现:攻击者诱骗用户,让他们自己提交恶意请求;或在远程情况下,攻击者与用户共享同一个连接到服务器(如共享代理服务器)的 TCP 连接。最理想的情况是,攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击,进而对应用程序的安全性失去信心。最糟糕的情况是,攻击者可能提供经特殊技术处理的内容,这些内容旨在模仿应用程序的执行方式,但会重定向用户的私人信息(如帐号和密码),将这些信息发送给攻击者。

Cache Poisoning: 如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来,该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存(如在代理服务器中常见的缓存)中,那么使用该缓存的所有用户都会不断收到恶意内容,直到清除该缓存项为止。同样,如果响应缓存在单个用户的浏览器中,那么在清除该缓存项以前,该用户会不断收到恶意内容。然而,影响仅局限于本地浏览器的用户。

Cross-Site Scripting:一旦攻击者控制了应用程序传送的响应,就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式,这种攻击在响应中包含了恶意的 JavaScript 或其他代码,并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户,最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者,而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking:除了利用一个易受攻击的应用程序向用户传输恶意内容,还可以利用相同的根漏洞,将服务器生成的供用户使用的敏感内容重定向,转而供攻击者使用。攻击者通过提交一个会导致两个响应的请求,即服务器做出的预期响应和攻击者创建的响应,致使某个中间节点(如共享的代理服务器)误导服务器所生成的响应,将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应,第一个被解析为针对攻击者请求做出的响应,第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时,攻击者的请求已经在此处等候,并被解析为针对受害者这一请求的响应。这时,攻击者将第二个请求发送给服务器,代理服务器利用针对受害者(用户)的、由该服务器产生的这一请求对服务器做出响应,因此,针对受害者的这一响应中会包含所有头文件或正文中的敏感信息。

Cookie Manipulation:当与类似跨站请求伪造的攻击相结合时,攻击者就可以篡改、添加、甚至覆盖合法用户的 cookie。

Open Redirect:如果允许未验证的输入来控制重定向机制所使用的 URL,可能会有利于攻击者发动钓鱼攻击。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] 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
[35] 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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.python.header_manipulation
Abstract
在 Cookie 中包含未经验证的数据会引发 HTTP Response Header Manipulation 攻击,并可能导致 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect。
Explanation
Cookie Manipulation 漏洞会在以下情况下发生:

1. 数据通过不可信来源进入 Web 应用程序,最常见的是 HTTP 请求。

2. 数据包含在未经验证就发送给 Web 用户的 HTTP Cookie 中。

如同许多软件安全漏洞一样,Cookie Manipulation 只是通向终端的一个途径,它本身并不是终端。 从本质上看,这些漏洞是显而易见的:攻击者可将恶意数据传送到易受攻击的应用程序,然后该应用程序将这些数据包含在 HTTP Cookie 中。

Cookie Manipulation: 当与 Cross-Site Request Forgery 等攻击相结合时,攻击者就可以篡改、添加到、甚至覆盖合法用户的 Cookie。

作为 HTTP 响应标头,Cookie Manipulation 攻击也可导致其他类型的攻击,例如:

HTTP Response Splitting:
其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。 为了成功实施 HTTP Response Splitting 漏洞,该应用程序必须允许将包含 CR(回车符,也可以由 %0d 或 \r 指定)和 LF(换行符,也可以由 %0a 或 \n 指定)字符的输入包含在标头中。 攻击者不仅可以利用这些字符控制应用程序要发送的响应的剩余标头和正文,还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 标头感染恶意字符。 例如,如果尝试使用被禁用的字符设置标头,最新版本的 Apache Tomcat 会抛出 IllegalArgumentException。 如果您的应用程序服务器能够防止设置带有换行符的标头,则其具备对 HTTP Response Splitting 的防御能力。 然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此在设置带有用户输入的 HTTP 标头时仍需小心谨慎。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] 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
[35] 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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.scala.header_manipulation_cookies
Abstract
在 Cookies 中包含未验证的数据会引发 HTTP 响应头文件操作攻击,并可能导致 cache-poisoning、cross-site scripting、cross-user defacement、page hijacking、cookie manipulation 或 open redirect。
Explanation
以下情况中会出现 Cookie Manipulation 漏洞:

1. 数据通过一个不可信赖的数据源进入 Web 应用程序,最常见的是 HTTP 请求。

2. 数据包含在一个 HTTP Cookie 中,该 Cookie 未经验证就发送给了 Web 用户。

如同许多软件安全漏洞一样,Cookie Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,这些漏洞是显而易见的:攻击者可将恶意数据传送到易受攻击的应用程序,然后该应用程序将这些数据包含在 HTTP Cookie 中。

Cookie Manipulation:当与类似跨站请求伪造的攻击相结合时,攻击者就可以篡改、添加、甚至覆盖合法用户的 cookie。

作为 HTTP 响应头文件,Cookie Manipulation 攻击也可导致其他类型的攻击,例如:

HTTP Response Splitting:
其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功地实施 HTTP Response Splitting 盗取,应用程序必须允许将那些包含 CR(回车,由 %0d 或 \r 指定)和 LF(换行,由 %0a 或 \n 指定)的字符输入到头文件中。攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文,还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 头文件感染恶意字符。例如,如果尝试使用被禁用的字符设置头文件,最新版本的 Apache Tomcat 会抛出 IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此必须在设置带有用户输入的 HTTP 头文件时采取措施。

示例:以下代码片段会从 HTTP 请求中读取网络日志项的作者名字 author,并将其置于一个 HTTP 响应的 Cookie 头文件中。


...
author = Request.Form(AUTHOR_PARAM)
Response.Cookies("author") = author
Response.Cookies("author").Expires = cookieExpiration
...


假设在请求中提交了一个字符串,该字符串由标准的字母数字字符组成,如“Jane Smith”,那么包含该 Cookie 的 HTTP 响应可能表现为以下形式:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


然而,因为 cookie 值来源于未经校验的用户输入,所以仅当提交给 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如“Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...”,那么 HTTP 响应就会被分割成以下形式的两个响应:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


显然,第二个响应已完全由攻击者控制,攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应,从而发起多种形式的攻击,包括:cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement:攻击者可以向一个易受攻击的服务器发出一个请求,导致服务器创建两个响应,其中第二个响应可能会被曲解为对其他请求的响应,而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现:攻击者诱骗用户,让他们自己提交恶意请求;或在远程情况下,攻击者与用户共享同一个连接到服务器(如共享代理服务器)的 TCP 连接。最理想的情况是,攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击,进而对应用程序的安全性失去信心。最糟糕的情况是,攻击者可能提供经特殊技术处理的内容,这些内容旨在模仿应用程序的执行方式,但会重定向用户的私人信息(如帐号和密码),将这些信息发送给攻击者。

缓存中毒:如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来,该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存(如在代理服务器中常见的缓存)中,那么使用该缓存的所有用户都会不断收到恶意内容,直到清除该缓存项为止。同样,如果响应缓存在单个用户的浏览器中,那么在清除该缓存项以前,该用户会不断收到恶意内容。然而,影响仅局限于本地浏览器的用户。

Cross-Site Scripting:一旦攻击者控制了应用程序传送的响应,就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式,这种攻击在响应中包含了恶意的 JavaScript 或其他代码,并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户,最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者,而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking:除了利用一个易受攻击的应用程序向用户传输恶意内容,还可以利用相同的根漏洞,将服务器生成的供用户使用的敏感内容重定向,转而供攻击者使用。攻击者通过提交一个会导致两个响应的请求,即服务器做出的预期响应和攻击者创建的响应,致使某个中间节点(如共享的代理服务器)误导服务器所生成的响应,将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应,第一个被解析为针对攻击者请求做出的响应,第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时,攻击者的请求已经在此处等候,并被解析为针对受害者这一请求的响应。这时,攻击者将第二个请求发送给服务器,代理服务器利用针对受害者(用户)的、由该服务器产生的这一请求对服务器做出响应,因此,针对受害者的这一响应中会包含所有头文件或正文中的敏感信息。

Open Redirect:如果允许未验证的输入来控制重定向机制所使用的 URL,可能会有利于攻击者发动钓鱼攻击。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] 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
[35] 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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.vb.header_manipulation_cookies
Abstract
在 SMTP 标头中包含未经验证的数据使得攻击者可以添加任意标头(如 CCBCC),从而利用这些标头向其本身泄露邮件内容或将邮件服务器用作垃圾邮件自动程序。
Explanation
SMTP Header Manipulation 漏洞会在以下情况下发生:

1.数据通过不可信数据源进入应用程序,最常见的是 Web 应用程序中的 HTTP 请求。

2.数据包含在未经验证就发送给邮件服务器的 SMTP 标头中。

如同许多软件安全漏洞一样,SMTP Header Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,该漏洞是显而易见的:攻击者可将恶意数据传送到易受攻击的应用程序,然后该应用程序将这些数据包含在 SMTP 标头中。

一种最常见的 SMTP Header Manipulation 攻击是分发垃圾邮件。如果应用程序包含一个易受攻击的“联系我们”表单,该表单允许设置电子邮件的主题和正文,攻击者就能够设置任意内容,并将包含电子邮件地址列表的 CC 标头匿名注入垃圾邮件,因为电子邮件是从受害者服务器发送的。

示例:以下代码段将读取“联系我们”表单的主题和正文:


func handler(w http.ResponseWriter, r *http.Request) {
subject := r.FormValue("subject")
body := r.FormValue("body")
auth := smtp.PlainAuth("identity", "user@example.com", "password", "mail.example.com")
to := []string{"recipient@example.net"}
msg := []byte("To: " + recipient1 + "\r\n" + subject + "\r\n" + body + "\r\n")
err := smtp.SendMail("mail.example.com:25", auth, "sender@example.org", to, msg)
if err != nil {
log.Fatal(err)
}
}


假设在请求中提交了一个由标准字母和数字字符组成的字符串,如“Page not working”,那么 SMTP 头可能表现为以下形式:


...
subject: [Contact us query] Page not working
...


然而,因为标头值是使用未经验证的用户输入构造的,所以仅当提交给 subject 的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交恶意字符串,例如“Congratulations!! You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ...”,则 SMTP 标头将采用以下形式:


...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...


这使得攻击者可以在其他攻击中制作垃圾邮件或发送匿名电子邮件。
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.1
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark complete
[8] Standards Mapping - Common Weakness Enumeration CWE ID 93
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[15] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[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 Mobile 2014 M1 Weak Server Side Controls
[21] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[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, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.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 - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.golang.header_manipulation_smtp
Abstract
在 SMTP 头中包括未经验证的数据使得攻击者可以添加任意标题(如 CCBCC),从而利用这些标题向其本身泄露邮件内容或将邮件服务器用作垃圾邮件自动程序。
Explanation
在以下情况下会发生 SMTP Header Manipulation 漏洞:

1. 数据通过一个不可信赖的数据源进入应用程序,最常见的是 Web 应用程序中的 HTTP 请求。

2. 数据包含在一个 SMTP 头中,该 SMTP 头未经验证就发送给了邮件服务器。

如同许多软件安全漏洞一样,SMTP Header Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,这些漏洞是显而易见的:攻击者可将恶意数据传送到易受攻击的应用程序,且该应用程序将这些数据包含在 SMTP 头中。

一种最常见的 SMTP Header Manipulation 攻击是分发垃圾邮件。如果应用程序包含一个易受攻击的“联系我们”表单,该表单允许设置电子邮件的主题和正文,攻击者就能够设置任意内容,并将包含电子邮件地址列表的 CC 标题匿名注入垃圾邮件,因为电子邮件会从受害者服务器进行发送。

示例:以下代码段读取“联系我们”表单的主题和正文:


String subject = request.getParameter("subject");
String body = request.getParameter("body");
MimeMessage message = new MimeMessage(session);
message.setFrom(new InternetAddress("webform@acme.com"));
message.setRecipients(Message.RecipientType.TO, InternetAddress.parse("support@acme.com"));
message.setSubject("[Contact us query] " + subject);
message.setText(body);
Transport.send(message);


假设在请求中提交了一个由标准字母和数字字符组成的字符串,如“Page not working”,那么 SMTP 头可能表现为以下形式:


...
subject: [Contact us query] Page not working
...


然而,因为该头的值是利用未经验证的用户输入构造的,所以仅当提交给 subject 的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交恶意字符串,例如“Congratulations!!You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ...”,则 SMTP 头将表现为以下形式:


...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...


这将有效地允许攻击者制造垃圾邮件,或者发送匿名电子邮件等攻击。
References
[1] OWASP Testing for IMAP/SMTP Injection (OTG-INPVAL-011)
[2] Vicente Aguilera Díaz MX Injection: Capturing and Exploiting Hidden Mail Servers
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.1
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - CIS Kubernetes Benchmark complete
[10] Standards Mapping - Common Weakness Enumeration CWE ID 93
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[12] Standards Mapping - FIPS200 SI
[13] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[17] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A03 Injection
[22] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[23] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 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 3.2 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] 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
[36] 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
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.java.header_manipulation_smtp
Abstract
在 SMTP 头中包括未经验证的数据使得攻击者可以添加任意标题(如 CCBCC),从而利用这些标题向其本身泄露邮件内容或将邮件服务器用作垃圾邮件自动程序。
Explanation
在以下情况下会发生 SMTP Header Manipulation 漏洞:

1. 数据通过一个不可信赖的数据源进入应用程序,最常见的是 Web 应用程序中的 HTTP 请求。

2. 数据包含在一个 SMTP 头中,该 SMTP 头未经验证就发送给了邮件服务器。

如同许多软件安全漏洞一样,SMTP Header Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,这些漏洞是显而易见的:攻击者可将恶意数据传送到易受攻击的应用程序,且该应用程序将这些数据包含在 SMTP 头中。

一种最常见的 SMTP Header Manipulation 攻击用于分发垃圾邮件。如果应用程序包含一个允许设置电子邮件主题和正文的易受攻击的“联系我们”表单,攻击者将能够设置任意内容,并注入包含匿名(因为电子邮件是从受害者服务器发送的)指向垃圾邮件的电子邮件地址列表的 CC 标题。

示例:以下代码段读取“联系我们”表单的主题和正文:


$subject = $_GET['subject'];
$body = $_GET['body'];
mail("support@acme.com", "[Contact us query] " . $subject, $body);


假设在请求中提交了一个由标准字母和数字字符组成的字符串,如“Page not working”,那么 SMTP 头可能表现为以下形式:


...
subject: [Contact us query] Page not working
...


然而,因为该头的值是利用未经验证的用户输入构造的,所以仅当提交给 subject 的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交恶意字符串,例如“Congratulations!!You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ...”,则 SMTP 头将表现为以下形式:


...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...


这将有效地允许攻击者制造垃圾邮件,或者发送匿名电子邮件等攻击。
References
[1] OWASP Testing for IMAP/SMTP Injection (OTG-INPVAL-011)
[2] Vicente Aguilera Díaz MX Injection: Capturing and Exploiting Hidden Mail Servers
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.1
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - CIS Kubernetes Benchmark complete
[10] Standards Mapping - Common Weakness Enumeration CWE ID 93
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[12] Standards Mapping - FIPS200 SI
[13] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[17] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A03 Injection
[22] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[23] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 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 3.2 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] 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
[36] 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
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.php.header_manipulation_smtp
Abstract
在 SMTP 头中包括未经验证的数据使得攻击者可以添加任意标题(如 CCBCC),从而利用这些标题向其本身泄露邮件内容或将邮件服务器用作垃圾邮件自动程序。
Explanation
在以下情况下会发生 SMTP Header Manipulation 漏洞:

1. 数据通过一个不可信赖的数据源进入应用程序,最常见的是 Web 应用程序中的 HTTP 请求。

2. 数据包含在一个 SMTP 头中,该 SMTP 头未经验证就发送给了邮件服务器。

如同许多软件安全漏洞一样,SMTP Header Manipulation 只是通向终端的一个途径,它本身并不是终端。从本质上看,这些漏洞是显而易见的:攻击者可将恶意数据传送到易受攻击的应用程序,且该应用程序将这些数据包含在 SMTP 头中。

一种最常见的 SMTP Header Manipulation 攻击用于分发垃圾邮件。如果应用程序包含一个允许设置电子邮件主题和正文的易受攻击的“联系我们”表单,攻击者将能够设置任意内容,并注入包含匿名(因为电子邮件是从受害者服务器发送的)指向垃圾邮件的电子邮件地址列表的 CC 标题。

示例:以下代码段读取“联系我们”表单的主题和正文:


body = request.GET['body']
subject = request.GET['subject']
session = smtplib.SMTP(smtp_server, smtp_tls_port)
session.ehlo()
session.starttls()
session.login(username, password)
headers = "\r\n".join(["from: webform@acme.com",
"subject: [Contact us query] " + subject,
"to: support@acme.com",
"mime-version: 1.0",
"content-type: text/html"])
content = headers + "\r\n\r\n" + body
session.sendmail("webform@acme.com", "support@acme.com", content)


假设在请求中提交了一个由标准字母和数字字符组成的字符串,如“Page not working”,那么 SMTP 头可能表现为以下形式:


...
subject: [Contact us query] Page not working
...


然而,因为该头的值是利用未经验证的用户输入构造的,所以仅当提交给 subject 的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交恶意字符串,例如“Congratulations!!You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ...”,则 SMTP 头将表现为以下形式:


...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...


这将有效地允许攻击者制造垃圾邮件,或者发送匿名电子邮件等攻击。
References
[1] OWASP Testing for IMAP/SMTP Injection (OTG-INPVAL-011)
[2] Vicente Aguilera Díaz MX Injection: Capturing and Exploiting Hidden Mail Servers
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.1
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - CIS Kubernetes Benchmark complete
[10] Standards Mapping - Common Weakness Enumeration CWE ID 93
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[12] Standards Mapping - FIPS200 SI
[13] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[17] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A03 Injection
[22] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[23] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 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 3.2 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] 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
[36] 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
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.python.header_manipulation_smtp
Abstract
如果在 URL 中加入未验证的输入,可能会让攻击者重写请求参数的值。攻击者可能会重写现有的参数值、注入新的参数或利用直接得到的变量。
Explanation
HTTP Parameter Pollution (HPP) 攻击包含将编码的查询字符串分隔符注入其他现有的参数中。如果 Web 应用程序没有正确地检查用户输入,恶意用户可能会破坏应用程序的逻辑,进行客户端侧或服务器侧攻击。如果再向 Web 应用程序提交参数,并且如果这些参数与现有参数的名称相同,则 Web 应用程序可能会有下列一种反应:

它可能只从第一个参数中提取数据
它可能从最后一个参数中提取数据
它可能从所有参数中提取数据并把它们连接起来


例如:
- ASP.NET/IIS 使用所有情况下出现的参数
- Apache Tomcat 仅使用第一次出现的参数并忽略其他参数
- mod_perl/Apache 将值转换为值数组

示例 1:根据应用程序服务器和应用程序自身的逻辑,下列请求可能造成与身份验证系统的混淆,使攻击者能模拟别的用户。
http://www.server.com/login.aspx?name=alice&name=hacker

示例 2:下列代码使用来自于 HTTP 请求的输入来呈现两个超链接。

...
String lang = Request.Form["lang"];
WebClient client = new WebClient();
client.BaseAddress = url;
NameValueCollection myQueryStringCollection = new NameValueCollection();
myQueryStringCollection.Add("q", lang);
client.QueryString = myQueryStringCollection;
Stream data = client.OpenRead(url);
...


URL: http://www.host.com/election.aspx?poll_id=4567
链接 1:<a href="http://www.host.com/vote.aspx?poll_id=4567&lang=en">英语<a>
链接 2:<a href="http://www.host.com/vote.aspx?poll_id=4567&lang=es">西班牙语<a>

程序员尚未考虑下面这种可能性:攻击者可能会提供一个 lang(例如 en&poll_id=1),然后攻击者可以随意更改该 poll_id
References
[1] HTTP Parameter Pollution Luca Carettoni, Independent Researcher & Stefano Di Paola, MindedSecurity
[2] HTTP Parameter Pollution Vulnerabilities in Web Applications Marco `embyte’ Balduzzi
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 235
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[31] 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
[32] 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
[33] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.dotnet.http_parameter_pollution
Abstract
如果在 URL 中加入未验证的输入,可能会让攻击者重写请求参数的值。攻击者可能会重写现有的参数值、注入新的参数或利用直接得到的变量。
Explanation
HTTP Parameter Pollution (HPP) 攻击包含将编码的查询字符串分隔符注入其他现有的参数中。如果 Web 应用程序没有正确地检查用户输入,恶意用户可能会破坏应用程序的逻辑,进行客户端侧或服务器侧攻击。如果再向 Web 应用程序提交参数,并且如果这些参数与现有参数的名称相同,则 Web 应用程序可能会有下列一种反应:

它可能只从第一个参数中提取数据
它可能从最后一个参数中提取数据
它可能从所有参数中提取数据并把它们连接起来


例如:
- ASP.NET/IIS 使用所有情况下出现的参数
- Apache Tomcat 仅使用第一次出现的参数并忽略其他参数
- mod_perl/Apache 将值转换为值数组

例 1:根据应用程序服务器和应用程序自身的逻辑,下列请求可能造成与身份验证系统的混淆,使攻击者能模拟别的用户。
http://www.example.com/login.php?name=alice&name=hacker

例 2:下列代码使用来自于 HTTP 请求的输入来呈现两个超链接。

...
String lang = request.getParameter("lang");
GetMethod get = new GetMethod("http://www.example.com");
get.setQueryString("lang=" + lang + "&poll_id=" + poll_id);
get.execute();
...


URL:http://www.example.com?poll_id=4567
链接 1:<a href="001">英语<a>
链接 2:<a href="002">西班牙语<a>

程序员尚未考虑下面这种可能性:攻击者可能会提供一个 lang(例如 en&poll_id=1),然后攻击者将可以随意更改该 poll_id
References
[1] HTTP Parameter Pollution Luca Carettoni, Independent Researcher & Stefano Di Paola, MindedSecurity
[2] HTTP Parameter Pollution Vulnerabilities in Web Applications Marco `embyte’ Balduzzi
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 235
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[31] 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
[32] 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
[33] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.http_parameter_pollution
Abstract
如果在 URL 中加入未验证的输入,可能会让攻击者重写请求参数的值。攻击者可能会重写现有的参数值、注入新的参数或利用直接得到的变量。
Explanation
HTTP Parameter Pollution (HPP) 攻击包含将编码的查询字符串分隔符注入其他现有的参数中。如果 Web 应用程序没有正确地检查用户输入,恶意用户可能会破坏应用程序的逻辑,进行客户端侧或服务器侧攻击。如果再向 Web 应用程序提交参数,并且如果这些参数与现有参数的名称相同,则 Web 应用程序可能会有下列一种反应:

它可能只从第一个参数中提取数据
它可能从最后一个参数中提取数据
它可能从所有参数中提取数据并把它们连接起来


例如:
- ASP.NET/IIS 使用所有情况下出现的参数
- Apache Tomcat 仅使用第一次出现的参数并忽略其他参数
- mod_perl/Apache 将值转换为值数组

例 1:根据应用程序服务器和应用程序自身的逻辑,下列请求可能造成与身份验证系统的混淆,使攻击者能模拟别的用户。
http://www.server.com/login.php?name=alice&name=hacker

例 2:下列代码使用来自于 HTTP 请求的输入来呈现两个超链接。


<%
...
$id = $_GET["id"];
header("Location: http://www.host.com/election.php?poll_id=" . $id);
...
%>


URL: http://www.host.com/election.php?poll_id=4567
链接 1: <a href="vote.php?poll_id=4567&candidate=white">White 先生的投票<a>
链接 2: <a href="vote.php?poll_id=4567&candidate=green">Green 女士的投票<a>

程序员没有考虑到攻击者可能提供 poll_id(例如“4567&candidate=green”)的可能性,届时得到的页面中将包含以下注入链接,因此,Green 女士将始终投票选择捡出第一个参数的应用程序服务器。
<a href="vote.php?poll_id=4567&candidate=green&candidate=white">White 先生的投票<a>
<a href="vote.php?poll_id=4567&candidate=green&candidate=green">Green 女士的投票<a>
References
[1] HTTP Parameter Pollution Luca Carettoni, Independent Researcher & Stefano Di Paola, MindedSecurity
[2] HTTP Parameter Pollution Vulnerabilities in Web Applications Marco `embyte’ Balduzzi
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 235
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[31] 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
[32] 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
[33] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.php.http_parameter_pollution
Abstract
如果在 URL 中加入未验证的输入,可能会让攻击者重写请求参数的值。攻击者可能会重写现有的参数值、注入新的参数或利用直接得到的变量。
Explanation
HTTP Parameter Pollution (HPP) 攻击包含将编码的查询字符串分隔符注入其他现有的参数中。如果 Web 应用程序没有正确地检查用户输入,恶意用户可能会破坏应用程序的逻辑,进行客户端侧或服务器侧攻击。如果再向 Web 应用程序提交参数,并且如果这些参数与现有参数的名称相同,则 Web 应用程序可能会有下列一种反应:

它可能只从第一个参数中提取数据。
它可能从最后一个参数中提取数据。
它可能从所有参数中提取数据并把它们连接起来。


例如:
- ASP.NET/IIS 使用所有情况下出现的参数
- Apache Tomcat 仅使用第一次出现的参数并忽略其他参数
- mod_perl/Apache 将值转换为值数组

例 1:根据应用程序服务器和应用程序自身的逻辑,下列请求可能造成与身份验证系统的混淆,使攻击者能模拟别的用户。
http://www.server.com/login.php?name=alice&name=hacker

因为这表明,攻击者已经指定了 name=alice,但他们添加了额外的 name=alice&,如果在提取第一个匹配项的服务器上使用它,那么它可能会模仿 alice 以便获取有关她的帐户的详细信息。
References
[1] HTTP Parameter Pollution Luca Carettoni, Independent Researcher & Stefano Di Paola, MindedSecurity
[2] HTTP Parameter Pollution Vulnerabilities in Web Applications Marco `embyte’ Balduzzi
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 235
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[31] 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
[32] 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
[33] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.ruby.http_parameter_pollution
Abstract
该应用程序允许安装第三方键盘扩展。
Explanation
键盘扩展可以读取用户输入的每一个按键。第三方键盘通常用于简化文本输入或添加额外的表情符号,他们可以记录用户输入的内容,甚至将其发送到远程服务器进行处理。恶意键盘还可以作为键盘记录器来分发,以读取用户输入的每一个键,从而窃取凭据或信用卡号等敏感数据。
References
[1] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[2] UIApplicationDelegate Apple
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 522, CWE ID 829
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [18] CWE ID 522
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [21] CWE ID 522
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[13] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.3 Service Authentication Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 5.3.9 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 12.3.6 File Execution Requirements (L2 L3), 14.2.4 Dependency (L2 L3)
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-3
desc.structural.objc.input_interception_keyboard_extensions_allowed
Abstract
该应用程序允许安装第三方键盘扩展。
Explanation
键盘扩展可以读取用户输入的每一个按键。第三方键盘通常用于简化文本输入或添加额外的表情符号,他们可以记录用户输入的内容,甚至将其发送到远程服务器进行处理。恶意键盘还可以作为键盘记录器来分发,以读取用户输入的每一个键,从而窃取凭据或信用卡号等敏感数据。
References
[1] UIApplicationDelegate Apple
[2] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 522, CWE ID 829
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [18] CWE ID 522
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [21] CWE ID 522
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[13] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.3 Service Authentication Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 5.3.9 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 12.3.6 File Execution Requirements (L2 L3), 14.2.4 Dependency (L2 L3)
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-3
desc.structural.swift.input_interception_keyboard_extensions_allowed
Abstract
程序使用 Android 备份服务将永久性应用程序数据保存到远程云存储。
Explanation
Android 备份服务允许应用程序将持久性数据保存到远程云存储,以便日后作为应用程序数据还原点。

Android 应用程序可通过此备份服务进行配置,即将 allowBackup 属性设置为 true(默认值),并在 <application> 标签上定义 backupAgent 属性。

但是,Android 不保证使用备份期间的数据安全性,因为云存储和传输因设备而异。
References
[1] JavaDoc for Android Android
[2] Android Developers API Guide: Data Backup Android
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Common Weakness Enumeration CWE ID 312, CWE ID 359, CWE ID 921
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002475
[13] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[18] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[19] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[21] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 6.1.1 Data Classification (L2 L3), 6.1.2 Data Classification (L2 L3), 6.1.3 Data Classification (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.2.2 Client-side Data Protection (L1 L2 L3), 8.1.6 General Data Protection (L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[22] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[23] Standards Mapping - OWASP Mobile 2023 M8 Security Misconfiguration
[24] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.6, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.3.1, Requirement 3.5.1, Requirement 4.2.2, Requirement 6.2.4, Requirement 8.3.1
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography, Control Objective B.2.5 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography, Control Objective B.2.5 - Terminal Software Design
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002340 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002340 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002340 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002340 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002340 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.config.java.insecure_storage_android_backup_storage
Abstract
程序将数据写入 Android 设备的外部存储。
Explanation
保存到外部存储上的文件可随意读取,并且能够被启用 USB 海量存储来传输计算机上的文件的用户修改。另外,即便卸载了将文件写入外部存储卡的应用程序,这些文件也不会被删除。这些缺陷会危及写入存储的敏感信息,或者使攻击者能够通过修改程序所依赖的外部文件将恶意数据注入程序。

示例 1:在以下代码中,Environment.getExternalStorageDirectory() 会返回对 Android 设备的外部存储的引用。

 private void WriteToFile(String what_to_write) {
try{
File root = Environment.getExternalStorageDirectory();
if(root.canWrite()) {
File dir = new File(root + "write_to_the_SDcard");
File datafile = new File(dir, number + ".extension");
FileWriter datawriter = new FileWriter(datafile);
BufferedWriter out = new BufferedWriter(datawriter);
out.write(what_to_write);
out.close();
}
}
}
References
[1] Data Storage
[2] Paul McNamara Latest 'lost' laptop holds treasure-trove of unencrypted ATT payroll data Network World
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Common Weakness Enumeration CWE ID 276, CWE ID 313, CWE ID 359, CWE ID 921
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [19] CWE ID 276, [20] CWE ID 200
[12] Standards Mapping - Common Weakness Enumeration Top 25 2022 [20] CWE ID 276
[13] Standards Mapping - Common Weakness Enumeration Top 25 2023 [25] CWE ID 276
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002475
[15] Standards Mapping - FIPS200 MP
[16] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[19] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 6.1.1 Data Classification (L2 L3), 6.1.2 Data Classification (L2 L3), 6.1.3 Data Classification (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3), 8.2.2 Client-side Data Protection (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[24] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[25] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[26] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[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 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[35] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002340 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002340 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002340 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002340 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002340 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002340 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002340 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002340 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002340 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002340 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002340 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002340 CAT II
[49] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.java.insecure_storage_android_external_storage
Abstract
应用程序使数据可供 Android 设备上的所有应用程序访问。
Explanation
使用 MODE_WORLD_READBLE 或 MODE_WORLD_WRITEABLE 存储在 Android 内部存储中的数据可供设备上的所有应用程序访问。这不仅无法防止数据损坏,而且如果是敏感信息的话,可能违反用户隐私和安全事宜。
References
[1] Designing for Security Android
[2] S. Fahl, M. Harbach, T. Muders, M. Smith, L. Baumgartner, B. Friesleben Why Eve and Mallory Love Android:An Analysis of Android SSL (In)Security
[3] OWASP Mobile Security Testing Guide OWASP
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 276, CWE ID 313, CWE ID 359, CWE ID 921
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [19] CWE ID 276, [20] CWE ID 200
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [20] CWE ID 276
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [25] CWE ID 276
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002475
[16] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[19] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[20] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 6.1.1 Data Classification (L2 L3), 6.1.2 Data Classification (L2 L3), 6.1.3 Data Classification (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3), 8.2.2 Client-side Data Protection (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[25] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[26] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[27] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.6, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.3.1, Requirement 3.5.1, Requirement 4.2.2, Requirement 6.2.4, Requirement 8.3.1
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002340 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002340 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002340 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002340 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002340 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002340 CAT II
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[62] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.structural.java.insecure_storage_android_world_readable_or_writeable
Abstract
该方法存储数据所采用的密钥链的可访问性级别允许将项目备份到 iCloud 和未加密的 iTunes 备份中。
Explanation
将数据存储到密钥链中时,需要设置可访问性级别以定义可在何时访问项目。可用的可访问性级别如下所示:

-kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:
重新启动后,将无法访问密钥链项目中的数据,直到用户将设备解除锁定一次。
第一次解除锁定后,数据将保持可访问状态,直到下次重新启动。推荐将此属性用于需要由后台应用程序访问的项目。具有此属性的项目不会迁移到新设备。因此,从不同设备的备份恢复后,这些项目将不存在。
在 iOS 4.0 和更高版本中可用。

-kSecAttrAccessibleAlways:
始终可访问密钥链项目中的数据,无论设备是否已锁定。
不建议用于应用程序。具有此属性的项目在使用加密备份时会迁移到新设备。
在 iOS 4.0 和更高版本中可用。

-kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:
只能在设备解除锁定时访问密钥链中的数据。仅在设备上设置了密码时可用。
建议只用于当应用程序处于前台时才需要访问的项目。具有此属性的项目不会迁移到新设备。将备份恢复到新设备后,这些项目将丢失。不能在没有密码的设备上的此类中存储任何项目。禁用设备密码将会删除此类中的所有项目。
在 iOS 8.0 和更高版本中可用。

-kSecAttrAccessibleAlwaysThisDeviceOnly:
始终可访问密钥链项目中的数据,无论设备是否已锁定。
不建议用于应用程序。具有此属性的项目不会迁移到新设备。因此,从不同设备的备份恢复后,这些项目将不存在。
在 iOS 4.0 和更高版本中可用。

-kSecAttrAccessibleWhenUnlocked:
只能在用户对设备解除锁定时访问密钥链项目中的数据。
建议只用于当应用程序处于前台时才需要访问的项目。具有此属性的项目在使用加密备份时会迁移到新设备。
这是在没有明确设置可访问性常量的情况下添加密钥链项目时的默认值。
在 iOS 4.0 和更高版本中可用。

-kSecAttrAccessibleWhenUnlockedThisDeviceOnly:
只能在用户对设备解除锁定时访问密钥链项目中的数据。
建议只用于当应用程序处于前台时才需要访问的项目。具有此属性的项目不会迁移到新设备。因此,从不同设备的备份恢复后,这些项目将不存在。
在 iOS 4.0 和更高版本中可用。

如果项目的可访问性级别中不包含 ThisDeviceOnly,那么该项目将备份到 iCloud,并且即便在使用可恢复到任意设备的未加密备份的情况下仍然会备份到 iTunes。这可能会导致隐私问题,具体取决于所存储数据的敏感和私密程度。

示例 1:在以下示例中,除了设备处于打开或解除锁定状态时,密钥链项目始终受保护,但将会备份到 iCloud 和未加密的 iTunes 备份中:


...
NSMutableDictionary *dict = [NSMutableDictionary dictionary];
NSData *token = [@"secret" dataUsingEncoding:NSUTF8StringEncoding];

// Configure KeyChain Item
[dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
[dict setObject:token forKey:(__bridge id)kSecValueData];
...
[dict setObject:(__bridge id)kSecAttrAccessibleWhenUnlocked forKey:(__bridge id) kSecAttrAccessible];

OSStatus error = SecItemAdd((__bridge CFDictionaryRef)dict, NULL);
...
References
[1] Keychain Services Apple
[2] Keychain Item Accessibility Constants Apple
[3] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[8] Standards Mapping - Common Weakness Enumeration CWE ID 312, CWE ID 359
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002475
[13] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[18] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[19] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[21] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 6.1.1 Data Classification (L2 L3), 6.1.2 Data Classification (L2 L3), 6.1.3 Data Classification (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3), 8.2.2 Client-side Data Protection (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[22] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[23] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[24] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.6, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.3.1, Requirement 3.5.1, Requirement 4.2.2, Requirement 6.2.4, Requirement 8.3.1
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective B.2.5 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective B.2.5 - Terminal Software Design
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002340 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002340 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002340 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002340 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002340 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.objc.insecure_storage_externally_available_keychain
Abstract
该方法存储数据所采用的密钥链的可访问性级别允许将项目备份到 iCloud 和未加密的 iTunes 备份中。
Explanation
将数据存储到密钥链中时,需要设置可访问性级别以定义可在何时访问项目。可用的可访问性级别如下所示:

-kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:
重新启动后,将无法访问密钥链项目中的数据,直到用户将设备解除锁定一次。
第一次解除锁定后,数据将保持可访问状态,直到下次重新启动。推荐将此属性用于需要由后台应用程序访问的项目。具有此属性的项目不会迁移到新设备。因此,从不同设备的备份恢复后,这些项目将不存在。
在 iOS 4.0 和更高版本中可用。

-kSecAttrAccessibleAlways:
始终可访问密钥链项目中的数据,无论设备是否已锁定。
不建议用于应用程序。具有此属性的项目在使用加密备份时会迁移到新设备。
在 iOS 4.0 和更高版本中可用。

-kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:
只能在设备解除锁定时访问密钥链中的数据。仅在设备上设置了密码时可用。
建议只用于当应用程序处于前台时才需要访问的项目。具有此属性的项目不会迁移到新设备。将备份恢复到新设备后,这些项目将丢失。不能在没有密码的设备上的此类中存储任何项目。禁用设备密码将会删除此类中的所有项目。
在 iOS 8.0 和更高版本中可用。

-kSecAttrAccessibleAlwaysThisDeviceOnly:
始终可访问密钥链项目中的数据,无论设备是否已锁定。
不建议用于应用程序。具有此属性的项目不会迁移到新设备。因此,从不同设备的备份恢复后,这些项目将不存在。
在 iOS 4.0 和更高版本中可用。

-kSecAttrAccessibleWhenUnlocked:
只能在用户对设备解除锁定时访问密钥链项目中的数据。
建议只用于当应用程序处于前台时才需要访问的项目。具有此属性的项目在使用加密备份时会迁移到新设备。
这是在没有明确设置可访问性常量的情况下添加密钥链项目时的默认值。
在 iOS 4.0 和更高版本中可用。

-kSecAttrAccessibleWhenUnlockedThisDeviceOnly:
只能在用户对设备解除锁定时访问密钥链项目中的数据。
建议只用于当应用程序处于前台时才需要访问的项目。具有此属性的项目不会迁移到新设备。因此,从不同设备的备份恢复后,这些项目将不存在。
在 iOS 4.0 和更高版本中可用。

如果项目的可访问性级别中不包含 ThisDeviceOnly,那么该项目将备份到 iCloud,并且即便在使用可恢复到任意设备的未加密备份的情况下仍然会备份到 iTunes。这可能会导致隐私问题,具体取决于所存储数据的敏感和私密程度。

示例 1:在以下示例中,除了设备处于打开或解除锁定状态时,密钥链项目始终受保护,但将会备份到 iCloud 和未加密的 iTunes 备份中:


...
// Configure KeyChain Item
let token = "secret"
var query = [String : AnyObject]()
query[kSecClass as String] = kSecClassGenericPassword
query[kSecValueData as String] = token as AnyObject?
...
query[kSecAttrAccessible as String] = kSecAttrAccessibleWhenUnlocked

SecItemAdd(query as CFDictionary, nil)
...
References
[1] Keychain Services Apple
[2] Keychain Item Accessibility Constants Apple
[3] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[8] Standards Mapping - Common Weakness Enumeration CWE ID 312, CWE ID 359
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002475
[13] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[18] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[19] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[21] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 6.1.1 Data Classification (L2 L3), 6.1.2 Data Classification (L2 L3), 6.1.3 Data Classification (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3), 8.2.2 Client-side Data Protection (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[22] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[23] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[24] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.6, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.3.1, Requirement 3.5.1, Requirement 4.2.2, Requirement 6.2.4, Requirement 8.3.1
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective B.2.5 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective B.2.5 - Terminal Software Design
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002340 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002340 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002340 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002340 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002340 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.swift.insecure_storage_externally_available_keychain
Abstract
所述方法将 HTTP(S) 响应缓存安装在不安全的共享存储中。
Explanation
HTTP(S) 响应中可能包含敏感数据,例如会话 Cookie 和 API 标记。 出于性能方面的考虑,URL 加载系统会对所有 HTTP(S) 响应进行缓存,将它们以未加密的形式存储在不安全的共享存储中。

示例 1: 以下代码将 HTTP(S) 响应缓存安装在共享存储空间:


protected void onCreate(Bundle savedInstanceState) {
...

try {
File httpCacheDir = new File(context.getExternalCacheDir(), "http");
long httpCacheSize = 10 * 1024 * 1024; // 10 MiB
HttpResponseCache.install(httpCacheDir, httpCacheSize);
} catch (IOException e) {
Log.i(TAG, "HTTP response cache installation failed:" + e);
}
}

protected void onStop() {
...

HttpResponseCache cache = HttpResponseCache.getInstalled();
if (cache != null) {
cache.flush();
}
}
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 311, CWE ID 312, CWE ID 313, CWE ID 522
[6] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[7] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [18] CWE ID 522
[8] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [21] CWE ID 522
[9] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[10] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001350, CCI-002475
[12] Standards Mapping - FIPS200 MP
[13] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.3 Service Authentication Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.1.1 Data Classification (L2 L3), 6.1.2 Data Classification (L2 L3), 6.1.3 Data Classification (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3), 8.2.2 Client-side Data Protection (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[24] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[25] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[26] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[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 7.1 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 311
[36] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 311
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.dataflow.java.insecure_storage_http_response_cache_leak
Abstract
该方法执行了 URL 请求,但未配置 URL 加载系统以阻止对 HTTP(S) 响应进行缓存。
Explanation
HTTP(S) 响应中可能包含敏感数据,例如会话 cookie 和 API 标记。出于性能方面的考虑,URL 加载系统会对所有 HTTP(S) 请求进行缓存,并将它们以未加密的形式保存在 {app ID}/Library/Caches/com.mycompany.myapp/Cache.db* 文件中。
References
[1] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[2] URLCache Apple
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 311, CWE ID 312, CWE ID 313, CWE ID 522
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [18] CWE ID 522
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [21] CWE ID 522
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001350, CCI-002475
[14] Standards Mapping - FIPS200 MP
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.3 Service Authentication Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.1.1 Data Classification (L2 L3), 6.1.2 Data Classification (L2 L3), 6.1.3 Data Classification (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3), 8.2.2 Client-side Data Protection (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3)
[25] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[26] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[27] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.1 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[37] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 311
[38] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 311
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.dataflow.objc.insecure_storage_http_response_cache_leak
Abstract
该方法执行了 URL 请求,但未配置 URL 加载系统以阻止对 HTTP(S) 响应进行缓存。
Explanation
HTTP(S) 响应中可能包含敏感数据,例如会话 cookie 和 API 标记。出于性能方面的考虑,URL 加载系统会对所有 HTTP(S) 请求进行缓存,并将它们以未加密的形式保存在 {app ID}/Library/Caches/com.mycompany.myapp/Cache.db* 文件中。
References
[1] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[2] URLCache Apple
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 311, CWE ID 312, CWE ID 313, CWE ID 522
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [18] CWE ID 522
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [21] CWE ID 522
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001350, CCI-002475
[14] Standards Mapping - FIPS200 MP
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.3 Service Authentication Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.1.1 Data Classification (L2 L3), 6.1.2 Data Classification (L2 L3), 6.1.3 Data Classification (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3), 8.2.2 Client-side Data Protection (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3)
[25] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[26] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[27] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.1 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[37] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 311
[38] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 311
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.dataflow.swift.insecure_storage_http_response_cache_leak
Abstract
该应用程序尝试将磁盘或内存缓存容量设置为 0 以禁用 HTTP(S) 缓存。然而,它并不能保证该设置得到强制执行。
Explanation
HTTP(S) 响应中可能包含敏感数据,例如会话 cookie 和 API 标记。出于性能方面的考虑,URL 加载系统会对所有 HTTP(S) 请求进行缓存,并将它们以未加密的形式保存在 {app ID}/Library/Caches/com.mycompany.myapp/Cache.db* 文件中。
开发者也许认为将 URLCache 类的 diskCapacitymemoryCapacity 属性设置为 0,就能成功禁用 HTTP(S) 响应缓存系统。但是,NSURLCache 文档指出,只有在设备的内存或磁盘空间不足的情况下,才会将磁盘和内存缓存缩减到配置的大小。这两项设置都是系统用来释放其资源以提高性能的,而非用于安全控制。
References
[1] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[2] URLCache Apple
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 311, CWE ID 312, CWE ID 313, CWE ID 522
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [18] CWE ID 522
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [21] CWE ID 522
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001350, CCI-002475
[14] Standards Mapping - FIPS200 MP
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.3 Service Authentication Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.1.1 Data Classification (L2 L3), 6.1.2 Data Classification (L2 L3), 6.1.3 Data Classification (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3), 8.2.2 Client-side Data Protection (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3)
[25] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[26] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[27] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.1 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[37] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 311
[38] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 311
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.objc.insecure_storage_insufficient_cache_leak_protection
Abstract
该应用程序尝试将磁盘或内存缓存容量设置为 0 以禁用 HTTP(S) 缓存。然而,它并不能保证该设置得到强制执行。
Explanation
HTTP(S) 响应中可能包含敏感数据,例如会话 cookie 和 API 标记。出于性能方面的考虑,URL 加载系统会对所有 HTTP(S) 请求进行缓存,并将它们以未加密的形式保存在 {app ID}/Library/Caches/com.mycompany.myapp/Cache.db* 文件中。
开发者也许认为将 URLCache 类的 diskCapacitymemoryCapacity 属性设置为 0,就能成功禁用 HTTP(S) 响应缓存系统。但是,NSURLCache 文档指出,只有在设备的内存或磁盘空间不足的情况下,才会将磁盘和内存缓存缩减到配置的大小。这两项设置都是系统用来释放其资源以提高性能的,而非用于安全控制。
References
[1] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[2] URLCache Apple
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 311, CWE ID 312, CWE ID 313, CWE ID 522
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [18] CWE ID 522
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [21] CWE ID 522
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001350, CCI-002475
[14] Standards Mapping - FIPS200 MP
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.3 Service Authentication Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.1.1 Data Classification (L2 L3), 6.1.2 Data Classification (L2 L3), 6.1.3 Data Classification (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3), 8.2.2 Client-side Data Protection (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3)
[25] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[26] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[27] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.1 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[37] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 311
[38] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 311
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.swift.insecure_storage_insufficient_cache_leak_protection