156 找到的項目
弱點
Abstract
允許使用者輸入直接修改檔案權限,可能會使攻擊者能夠存取原本應受保護的系統資源。
Explanation
當遇到下列狀況時會發生檔案權限操作錯誤:

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
當遇到下列狀況時會發生檔案權限操作錯誤:

1.攻擊者能夠指定在檔案系統上修改權限的作業中所使用的路徑。

2.攻擊者能夠指定檔案系統上的作業所指派的權限。

範例 1:以下程式碼使用來自系統屬性的輸入,設定預設權限遮罩。如果攻擊者能夠修改系統屬性,就能使用程式取得程式所操縱檔案的存取權。如果程式也存在 Path Manipulation 弱點,則攻擊者可能會使用這個弱點存取系統上的任意檔案。


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
當遇到下列狀況時會發生檔案權限操作錯誤:

1.攻擊者能夠指定在檔案系統上修改權限的作業中所使用的路徑。

2.攻擊者能夠指定檔案系統上的作業所指派的權限。

範例:以下程式碼旨在當使用者透過 FTP 上傳網頁時,設定適當的檔案權限。程式使用來自 HTTP 要求的輸入,以將檔案標示為外部使用者可檢視的狀態。


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


然而,如果攻擊者提供一個惡意的值給 publicReport,如「../../localuser/public_html/.htpasswd」,應用程式會指定攻擊者可讀取那個檔案。

範例 2:以下程式碼使用組態設定檔案的輸入設定預設權限遮罩。如果攻擊者能修改組態設定檔案,就能使用程式取得程式所操縱檔案的存取權。如果程式也存在 Path Manipulation 弱點,則攻擊者可能會使用這個弱點存取系統上的任意檔案。


...
$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
當遇到下列狀況時會發生檔案權限操作錯誤:

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
當遇到下列狀況時會發生檔案權限操作錯誤:

1. 攻擊者能夠指定在檔案系統上修改權限的作業中所使用的路徑。

2. 攻擊者能夠指定檔案系統上的作業所指派的權限。

範例:以下程式碼旨在當使用者透過 FTP 上傳網頁時,設定適當的檔案權限。程式使用來自 HTTP 要求的輸入,以將檔案標示為外部使用者可檢視的狀態。


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


然而,如果攻擊者提供一個惡意的值給 publicReport,如「../../localuser/public_html/.htpasswd」,應用程式會指定攻擊者可讀取那個檔案。

範例 2:以下程式碼使用組態設定檔案的輸入設定預設權限遮罩。如果攻擊者可以更改組態設定檔案,就可能使用程式取得程式所操縱檔案的存取權。如果程式也存在 Path Manipulation 弱點,則攻擊者可能會使用這個弱點存取系統上的任意檔案。


...
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
如果使用 Blaze DS 來記錄所有無法預期的事件,services-config.xml 描述符號檔案會指定「記錄」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 參數。

例如,syslog() 函數有時候以如下形式使用:


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


因為 syslog() 的第二個參數是個 Format String,所以任何包含在 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
攻擊者可能控制格式字串引數,讓攻擊更像是 Buffer overflow。
Explanation
Format String 弱點會在以下情況中出現:

1.資料從不可信賴的來源進入應用程式。



2.資料作為 Format String 引數傳送到函數,如 sprintf()FormatMessageW()syslog()NSLogNSString.stringWithFormat範例 1:以下程式碼在 NSString.stringWithFormat: 中使用指令行引數作為格式字串。


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 參數。

例如,syslog() 函數有時候以如下形式使用:


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


因為 syslog() 的第二個參數是個 Format String,所以任何包含在 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-error) 等等。有許多優秀的著作提供了關於堆疊 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-error) 等等。有許多優秀的著作提供了關於堆疊 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
包含其他網域的 script,這表示,這個網頁的安全性依賴另一個網域的安全性。
Explanation
包含另外一個網站中可執行的內容是有風險的。這樣會導致您網站的安全性與另一個網站息息相關。

範例: 請思考以下 script 標籤。

<script src="http://www.example.com/js/fancyWidget.js"></script>


如果這個標籤出現在 www.example.com 以外的網站上,則該網站依賴 www.example.com 提供正確且無惡意的程式碼。如果攻擊者能危害 www.example.com,他們就能修改 fancyWidget.js 的內容來破壞網站的安全性。例如,他們可以新增程式碼至 fancyWidget.js 來竊取使用者的機密資料。
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 494, CWE ID 829
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.14.2 Configuration Architectural Requirements (L2 L3), 5.3.9 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 10.3.2 Deployed Application Integrity Controls (L1 L2 L3), 12.3.3 File Execution Requirements (L1 L2 L3), 12.3.6 File Execution Requirements (L2 L3), 14.2.3 Dependency (L1 L2 L3), 14.2.4 Dependency (L2 L3)
[12] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[13] Standards Mapping - OWASP Mobile 2023 M7 Insufficient Binary Protections
[14] Standards Mapping - OWASP Mobile 2024 M7 Insufficient Binary Protections
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-PLATFORM-2
[16] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 094
[17] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[31] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Process Validation (WASC-40)
[32] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Process Validation
desc.content.html.hardcoded_domain
Abstract
在 HTTP 回應表頭中包含未經驗證的資料會導致 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect 攻擊。
Explanation
Header Manipulation 弱點會在以下情況中出現:

1. 資料透過不可信賴的來源進入 Web 應用程式,通常是 HTTP 要求。

2. HTTP 回應表頭包含的資料在未經驗證的情況下,便將其傳送給網頁使用者。

如同其他軟體的安全性弱點,Header Manipulation 是達到目的的一種手段,而不是一個目的。此弱點的基礎很簡單:攻擊者傳送惡意資料至有弱點的應用程式,應用程式再將該資料包含於 HTTP 回應表頭中。

最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊,應用程式必須允許輸入在表頭中包含 CR (Carriage Return,亦由 %0d 或 \r 指定) 與 LF (Line Feed,亦由 %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-site scripting 和網頁劫持。

跨用戶塗改:攻擊者將能夠發出單一要求到易受攻擊的伺服器,讓伺服器建立兩個回應,其中第二個回應可能會被錯誤解譯成針對不同要求的回應,該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成:攻擊者誘導使用者自己傳遞惡意要求,或是在遠端情況下,攻擊者和使用者共用相同的 TCP 連線連接到伺服器 (例如共用的代理伺服器)。最理想的情況是,攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊,造成使用者對應用程式的安全性失去信心。最差的狀況是,攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式執行方式,但會要求使用者重新導向要求私人資訊,例如帳戶號碼和密碼,接著會將這些資訊回傳給攻擊者。

Cache Poisoning:如果將惡意建構的回應快取到多個使用者使用的網頁快取或甚至單一使用者的瀏覽器快取,那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如代理伺服器中常見的網頁快取),那麼該快取的所有使用者將會繼續收到惡意內容,直到清除該快取項目為止。同樣的,如果回應貯存在單一使用者的瀏覽器中,那麼該使用者會繼續收到惡意的內容,直到清除快取項目為止,雖然只會影響本機瀏覽器實例的使用者。

Cross-Site Scripting:一旦攻擊者可以控制應用程式傳送的回應,他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式,此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼,且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言,最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持:除了利用易受攻擊的應用程式傳送惡意內容給使用者外,還可以利用具有相同本質的弱點,重新導向伺服器產生原本供使用者使用的敏感內容,轉而供攻擊者使用。藉由提交要求產生兩個回應,伺服器預期的回應和攻擊者產生的回應,攻擊者可能造成一個中間節點,例如一個共用的代理伺服器,來誤導伺服器針對使用者產生的回應傳遞給攻擊者。因為攻擊者所提出的要求產生兩個回應,第一個被解譯回應攻擊者的要求,而第二個被忘卻。當使用者透過相同 TCP 連線發出合法要求時,攻擊者的要求已處於等待狀態,並會被解讀成針對受害者要求的回應。接著,攻擊者會將第二個要求傳送到伺服器,且代理伺服器會將伺服器原本針對受害者要求產生的回應當作第二個要求的回應,如此一來,就會危及原本針對受害者的回應表頭或主體中的敏感資訊。

Cookie Manipulation:與跨網站偽造要求之類的攻擊結合時,攻擊者可能變更、新增至合法使用者的 Cookie,甚至覆寫合法使用者的 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.HTTP 回應標頭包含的資料在未經驗證的情況下便傳送給 Web 使用者。

如同許多軟體的安全性弱點,Header Manipulation 是達到目的的一種手段,而不是一個目的。此弱點的基礎很簡單:攻擊者將惡意資料傳送至容易受到攻擊的應用程式,應用程式再將該資料包含於 HTTP 回應標頭中。

最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊,應用程式必須允許輸入在標頭中包含 CR (Carriage Return,亦由 %0d 或 \r 指定) 與 LF (Line Feed,亦由 %0a 或 \n 指定) 字元。這些字元不僅讓攻擊者控制應用程式接下來要傳送之回應的剩餘標頭和正文,還允許它們全權建立其他回應。

現今許多新型的應用程式伺服器可防止將惡意字元插入 HTTP 標頭。例如,如果您嘗試使用禁用的字元設定標頭,最新版的 Apache Tomcat 會擲回 IllegalArgumentException。如果應用程式伺服器可防止使用換行字元來設定標頭,則您的應用程式面對 HTTP Response Splitting 的攻擊,具有一定的防禦能力。但是,僅篩選換行字元,應用程式可能仍對 Cookie Manipulation 或 Open Redirect 攻擊無招架能力,所以透過使用者輸入設定 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 連線的使用者所發出的。這種攻擊可以下列方式達成:攻擊者誘導使用者自己提交惡意要求;或是在遠端情況下,攻擊者和使用者共用相同的連線到伺服器 (例如共用的 Proxy 伺服器) 的 TCP 連線。最理想的情況是,攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊,造成使用者對應用程式的安全性失去信心。最差的狀況是,攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式的行為,但會將隱私資訊 (例如帳號和密碼) 重新導向回攻擊者。

Cache Poisoning:如果將惡意建構的回應快取到多個使用者使用的網頁快取或單一使用者的瀏覽器快取,那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如 Proxy 伺服器中常見的網頁快取),那麼該快取的所有使用者將會繼續收到惡意內容,直到清除該快取項目為止。同樣地,如果回應快取到單一使用者的瀏覽器中,那麼該使用者會繼續收到惡意內容,直到清除該快取項目為止,但是只有本機瀏覽器執行個體的使用者會受到影響。

Cross-Site Scripting:在攻擊者可以控制應用程式傳送的回應之後,他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式,此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼,且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言,最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持:除了利用易受攻擊的應用程式傳送惡意內容給使用者外,還可以利用具有相同本質的弱點,重新導向伺服器所產生且原本應供使用者使用的敏感內容,轉而供攻擊者使用。攻擊者藉由提交一個要求產生兩個回應,伺服器預期的回應和攻擊者產生的回應,致使中間節點 (例如共用的 Proxy 伺服器) 錯誤地將本應傳送給使用者的伺服器產生的回應傳送給攻擊者。因為攻擊者所提出的要求產生兩個回應,因此第一個被解譯為回應攻擊者的要求,而第二個則被忘卻。當使用者透過相同 TCP 連線發出合法要求時,攻擊者的要求已處於等待狀態,並會被解讀成針對受害者要求的回應。接著,攻擊者將第二個要求傳送到伺服器,Proxy 伺服器會使用伺服器針對受害者產生的要求回應伺服器,如此一來,就會危及原本針對受害者的回應標頭或本文中的敏感資訊。

Cookie Manipulation:與 Cross-Site Request Forgery 之類的攻擊結合時,攻擊者可能變更、新增合法使用者的 Cookie 或甚至覆寫合法使用者的 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 回應表頭包含的資料在未經驗證的情況下,便將其傳送給網頁使用者。

如同其他軟體的安全性弱點,Header Manipulation 是達到目的的一種手段,而不是一個目的。此弱點的基礎很簡單:攻擊者傳送惡意資料至有弱點的應用程式,應用程式再將該資料包含於 HTTP 回應表頭中。

最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊,應用程式必須允許輸入在表頭中包含 CR (Carriage Return,亦由 %0d 或 \r 指定) 與 LF (Line Feed,亦由 %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-site scripting 和網頁劫持。

跨用戶塗改:攻擊者將能夠發出單一要求到易受攻擊的伺服器,讓伺服器建立兩個回應,其中第二個回應可能會被錯誤解譯成針對不同要求的回應,該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成:攻擊者誘導使用者自己傳遞惡意要求,或是在遠端情況下,攻擊者和使用者共用相同的 TCP 連線連接到伺服器 (例如共用的代理伺服器)。最理想的情況是,攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊,造成使用者對應用程式的安全性失去信心。最差的狀況是,攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式執行方式,但會要求使用者重新導向要求私人資訊,例如帳戶號碼和密碼,接著會將這些資訊回傳給攻擊者。

快取破壞:如果將惡意建構的回應快取到多個使用者使用的網頁快取或甚至單一使用者的瀏覽器快取,那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如代理伺服器中常見的網頁快取),那麼該快取的所有使用者將會繼續收到惡意內容,直到清除該快取項目為止。同樣的,如果回應貯存在單一使用者的瀏覽器中,那麼該使用者會繼續收到惡意的內容,直到清除快取項目為止,雖然只會影響本機瀏覽器實例的使用者。

Cross-Site Scripting:一旦攻擊者可以控制應用程式傳送的回應,他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式,此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼,且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言,最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持:除了利用易受攻擊的應用程式傳送惡意內容給使用者外,還可以利用具有相同本質的弱點,重新導向伺服器產生原本供使用者使用的敏感內容,轉而供攻擊者使用。藉由提交要求產生兩個回應,伺服器預期的回應和攻擊者產生的回應,攻擊者可能造成一個中間節點,例如一個共用的代理伺服器,來誤導伺服器針對使用者產生的回應傳遞給攻擊者。因為攻擊者所提出的要求產生兩個回應,第一個被解譯回應攻擊者的要求,而第二個被忘卻。當使用者透過相同 TCP 連線發出合法要求時,攻擊者的要求已處於等待狀態,並會被解讀成針對受害者要求的回應。接著,攻擊者會將第二個要求傳送到伺服器,且代理伺服器會將伺服器原本針對受害者要求產生的回應當作第二個要求的回應,如此一來,就會危及原本針對受害者的回應表頭或主體中的敏感資訊。

Cookie Manipulation:與跨網站偽造要求之類的攻擊結合時,攻擊者可能變更、新增至合法使用者的 Cookie,甚至覆寫合法使用者的 Cookie。

開放式重新導向:允許未經驗證的輸入來控制重新導向中使用的 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 回應表頭是否存在惡意特徵的情況下,便將其傳送給某個網頁使用者。

如同其他軟體的安全性弱點,Header Manipulation 是達到目的的一種手段,而不是一個目的。此弱點的基礎很簡單:攻擊者傳送惡意資料至有弱點的應用程式,應用程式再將該資料包含於 HTTP 回應表頭中。

最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊,應用程式必須允許輸入在表頭中包含 CR (Carriage Return,亦由 %0d 或 \r 指定) 與 LF (Line Feed,亦由 %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-site scripting 和網頁劫持。

跨用戶塗改:攻擊者將能夠發出單一要求到易受攻擊的伺服器,讓伺服器建立兩個回應,其中第二個回應可能會被錯誤解譯成針對不同要求的回應,該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成:攻擊者誘導使用者自己傳遞惡意要求,或是在遠端情況下,攻擊者和使用者共用相同的 TCP 連線連接到伺服器 (例如共用的代理伺服器)。最理想的情況是,攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊,造成使用者對應用程式的安全性失去信心。最差的狀況是,攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式執行方式,但會要求使用者重新導向要求私人資訊,例如帳戶號碼和密碼,接著會將這些資訊回傳給攻擊者。

Cache Poisoning:如果將惡意建構的回應快取到多個使用者使用的網頁快取或甚至單一使用者的瀏覽器快取,那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如代理伺服器中常見的網頁快取),那麼該快取的所有使用者將會繼續收到惡意內容,直到清除該快取項目為止。同樣的,如果回應貯存在單一使用者的瀏覽器中,那麼該使用者會繼續收到惡意的內容,直到清除快取項目為止,雖然只會影響本機瀏覽器實例的使用者。

Cross-Site Scripting:一旦攻擊者可以控制應用程式傳送的回應,他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式,此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼,且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言,最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持:除了利用易受攻擊的應用程式傳送惡意內容給使用者外,還可以利用具有相同本質的弱點,重新導向伺服器產生原本供使用者使用的敏感內容,轉而供攻擊者使用。藉由提交要求產生兩個回應,伺服器預期的回應和攻擊者產生的回應,攻擊者可能造成一個中間節點,例如一個共用的代理伺服器,來誤導伺服器針對使用者產生的回應傳遞給攻擊者。因為攻擊者所提出的要求產生兩個回應,第一個被解譯回應攻擊者的要求,而第二個被忘卻。當使用者透過相同 TCP 連線發出合法要求時,攻擊者的要求已處於等待狀態,並會被解讀成針對受害者要求的回應。接著,攻擊者會將第二個要求傳送到伺服器,且代理伺服器會將伺服器原本針對受害者要求產生的回應當作第二個要求的回應,如此一來,就會危及原本針對受害者的回應表頭或主體中的敏感資訊。

Cookie Manipulation:與跨網站偽造要求之類的攻擊結合時,攻擊者可能變更、新增至合法使用者的 Cookie,甚至覆寫合法使用者的 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 應用程式,通常是網頁要求。

2. HTTP 回應表頭包含的資料在未經驗證的情況下,便將其傳送給網頁使用者。

如同其他軟體的安全性弱點,Header Manipulation 是達到目的的一種手段,而不是一個目的。此弱點的基礎很簡單:攻擊者傳送惡意資料至有弱點的應用程式,應用程式再將該資料包含於 HTTP 回應表頭中。

最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊,應用程式必須允許輸入在表頭中包含 CR (Carriage Return,亦由 %0d 或 \r 指定) 與 LF (Line Feed,亦由 %0a 或 \n 指定) 字元。這些字元不僅讓攻擊者控制應用程式接下來要傳送的回應表頭和回應主題,還允許他們全權建立其他回應。

現今許多先進的應用程式伺服器可防止將惡意字元插入 HTTP 表頭。舉例來說,如果您嘗試使用禁用的字元設定表頭,最新版的 Apache Tomcat 會拋出 IllegalArgumentException。如果應用程式伺服器可防止使用新行的字元來設定表頭,則您的應用程式對於 HTTP Response Splitting 的攻擊,具有一定的防禦能力。但是,僅篩選新行的字元,應用程式可能仍對 Cookie Manipulation 或 Open Redirects 攻擊無招架能力,所以透過使用者輸入設定 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-site scripting 和網頁劫持。

跨用戶塗改:攻擊者將能夠發出單一要求到易受攻擊的伺服器,讓伺服器建立兩個回應,其中第二個回應可能會被錯誤解譯成針對不同要求的回應,該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成:攻擊者誘導使用者自己傳遞惡意要求,或是在遠端情況下,攻擊者和使用者共用相同的 TCP 連線連接到伺服器 (例如共用的代理伺服器)。最理想的情況是,攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊,造成使用者對應用程式的安全性失去信心。最差的狀況是,攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式執行方式,但會要求使用者重新導向要求私人資訊,例如帳戶號碼和密碼,接著會將這些資訊回傳給攻擊者。

Cache Poisoning:如果將惡意建構的回應快取到多個使用者使用的網頁快取或甚至單一使用者的瀏覽器快取,那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如代理伺服器中常見的網頁快取),那麼該快取的所有使用者將會繼續收到惡意內容,直到清除該快取項目為止。同樣的,如果回應貯存在單一使用者的瀏覽器中,那麼該使用者會繼續收到惡意的內容,直到清除快取項目為止,雖然只會影響本機瀏覽器實例的使用者。

Cross-Site Scripting:一旦攻擊者可以控制應用程式傳送的回應,他們就可以提供各種惡意內容給使用者。Cross-site scripting 是最常見的攻擊形式,其攻擊在回應中包含惡意的 JavaScript 或其他程式碼,且在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言,最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持:除了利用易受攻擊的應用程式傳送惡意內容給使用者外,還可以利用具有相同本質的弱點,重新導向伺服器產生原本供使用者使用的敏感內容,轉而供攻擊者使用。藉由提交要求產生兩個回應,伺服器預期的回應和攻擊者產生的回應,攻擊者可能造成一個中間節點,例如一個共用的代理伺服器,來誤導伺服器針對使用者產生的回應傳遞給攻擊者。因為攻擊者所提出的要求產生兩個回應,第一個被解譯回應攻擊者的要求,而第二個被忘卻。當使用者透過相同 TCP 連線發出合法要求時,攻擊者的要求已處於等待狀態,並會被解讀成針對受害者要求的回應。接著,攻擊者會將第二個要求傳送到伺服器,且代理伺服器會將伺服器原本針對受害者要求產生的回應當作第二個要求的回應,如此一來,就會危及原本針對受害者的回應表頭或主體中的敏感資訊。

Cookie Manipulation:與跨網站偽造要求之類的攻擊結合時,攻擊者可能變更、新增至合法使用者的 Cookie,甚至覆寫合法使用者的 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.HTTP 回應標頭包含的資料在未經驗證的情況下便傳送給 Web 使用者。

如同許多軟體的安全性弱點,Header Manipulation 是達到目的的一種手段,而不是一個目的。此弱點的基礎很簡單:攻擊者將惡意資料傳送至容易受到攻擊的應用程式,應用程式再將該資料包含於 HTTP 回應標頭中。

最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊,應用程式必須允許輸入在標頭中包含 CR (Carriage Return,亦由 %0d 或 \r 指定) 與 LF (Line Feed,亦由 %0a 或 \n 指定) 字元。這些字元不僅讓攻擊者控制應用程式接下來要傳送的回應的剩餘標頭和本文,還允許他們建立完全在他們控制下的其他回應。

現今許多新型的應用程式伺服器可防止將惡意字元插入 HTTP 標頭。舉例來說,如果您嘗試使用禁用的字元設定標頭,最新版的 Apache Tomcat 會拋出 IllegalArgumentException。如果應用程式伺服器可防止使用換行字元來設定標頭,則您的應用程式面對 HTTP Response Splitting 的攻擊,具有一定的防禦能力。但是,僅篩選換行字元,應用程式可能仍對 Cookie Manipulation 或 Open Redirect 攻擊無招架能力,所以透過使用者輸入設定 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' 標頭的值由未經驗證的使用者輸入所構成,因此惡意動作執行者可以操縱它來利用漏洞、執行 Code Injection 攻擊、暴露敏感資料、啟用惡意檔案執行或觸發 Denial of Service 情況,從而對應用程式的安全性和穩定性構成重大風險。
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.HTTP 回應標頭包含的資料在未經驗證的情況下便傳送給 Web 使用者。

如同許多軟體的安全性弱點,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 連線的使用者所發出的。這種攻擊可以下列方式達成:攻擊者誘導使用者自己提交惡意要求;或是在遠端情況下,攻擊者和使用者共用相同的連線到伺服器 (例如共用的 Proxy 伺服器) 的 TCP 連線。最理想的情況是,攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊,造成使用者對應用程式的安全性失去信心。最差的狀況是,攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式的行為,但會將隱私資訊 (例如帳號和密碼) 重新導向回攻擊者。

Cache Poisoning:如果將惡意建構的回應快取到多個使用者使用的網頁快取或單一使用者的瀏覽器快取,那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如 Proxy 伺服器中常見的網頁快取),那麼該快取的所有使用者將會繼續收到惡意內容,直到清除該快取項目為止。同樣地,如果回應快取到單一使用者的瀏覽器中,那麼該使用者會繼續收到惡意內容,直到清除該快取項目為止,但是只有本機瀏覽器實例的使用者會受到影響。

Cross-Site Scripting:在攻擊者可以控制應用程式傳送的回應之後,他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式,此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼,且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言,最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持:除了利用易受攻擊的應用程式傳送惡意內容給使用者外,還可以利用具有相同本質的弱點,重新導向伺服器所產生且原本應供使用者使用的敏感內容,轉而供攻擊者使用。攻擊者藉由提交一個要求產生兩個回應,伺服器預期的回應和攻擊者產生的回應,致使中間節點 (例如共用的 Proxy 伺服器) 錯誤地將本應傳送給使用者的伺服器產生的回應傳送給攻擊者。因為攻擊者所提出的要求產生兩個回應,因此第一個被解譯為回應攻擊者的要求,而第二個則被忘卻。當使用者透過相同 TCP 連線發出合法要求時,攻擊者的要求已處於等待狀態,並會被解讀成針對受害者要求的回應。接著,攻擊者將第二個要求傳送到伺服器,Proxy 伺服器會使用伺服器針對受害者產生的要求回應伺服器,如此一來,就會危及原本針對受害者的回應標頭或本文中的敏感資訊。

Cookie Manipulation:與 Cross-Site Request Forgery 之類的攻擊結合時,攻擊者可以變更、新增合法使用者的 Cookie 或甚至覆寫合法使用者的 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 回應表頭包含的資料在未經驗證的情況下,便將其傳送給網頁使用者。

如同其他軟體的安全性弱點,Header Manipulation 是達到目的的一種手段,而不是一個目的。此弱點的基礎很簡單:攻擊者傳送惡意資料至有弱點的應用程式,應用程式再將該資料包含於 HTTP 回應表頭中。

最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊,應用程式必須允許輸入在表頭中包含 CR (Carriage Return,亦由 %0d 或 \r 指定) 與 LF (Line Feed,亦由 %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-site scripting 和網頁劫持。

跨用戶塗改:攻擊者將能夠發出單一要求到易受攻擊的伺服器,讓伺服器建立兩個回應,其中第二個回應可能會被錯誤解譯成針對不同要求的回應,該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成:攻擊者誘導使用者自己傳遞惡意要求,或是在遠端情況下,攻擊者和使用者共用相同的 TCP 連線連接到伺服器 (例如共用的代理伺服器)。最理想的情況是,攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊,造成使用者對應用程式的安全性失去信心。最差的狀況是,攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式執行方式,但會要求使用者重新導向要求私人資訊,例如帳戶號碼和密碼,接著會將這些資訊回傳給攻擊者。

Cache Poisoning:如果將惡意建構的回應快取到多個使用者使用的網頁快取或甚至單一使用者的瀏覽器快取,那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如代理伺服器中常見的網頁快取),那麼該快取的所有使用者將會繼續收到惡意內容,直到清除該快取項目為止。同樣的,如果回應貯存在單一使用者的瀏覽器中,那麼該使用者會繼續收到惡意的內容,直到清除快取項目為止,雖然只會影響本機瀏覽器實例的使用者。

Cross-Site Scripting:一旦攻擊者可以控制應用程式傳送的回應,他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式,此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼,且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言,最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持:除了利用易受攻擊的應用程式傳送惡意內容給使用者外,還可以利用具有相同本質的弱點,重新導向伺服器產生原本供使用者使用的敏感內容,轉而供攻擊者使用。藉由提交要求產生兩個回應,伺服器預期的回應和攻擊者產生的回應,攻擊者可能造成一個中間節點,例如一個共用的代理伺服器,來誤導伺服器針對使用者產生的回應傳遞給攻擊者。因為攻擊者所提出的要求產生兩個回應,第一個被解譯回應攻擊者的要求,而第二個被忘卻。當使用者透過相同 TCP 連線發出合法要求時,攻擊者的要求已處於等待狀態,並會被解讀成針對受害者要求的回應。接著,攻擊者會將第二個要求傳送到伺服器,且代理伺服器會將伺服器原本針對受害者要求產生的回應當作第二個要求的回應,如此一來,就會危及原本針對受害者的回應表頭或主體中的敏感資訊。

Cookie Manipulation:與跨網站偽造要求之類的攻擊結合時,攻擊者可能變更、新增至合法使用者的 Cookie,甚至覆寫合法使用者的 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 回應表頭包含的資料在未經驗證的情況下,便將其傳送給網頁使用者。

如同其他軟體的安全性弱點,Header Manipulation 是達到目的的一種手段,而不是一個目的。此弱點的基礎很簡單:攻擊者傳送惡意資料至有弱點的應用程式,應用程式再將該資料包含於 HTTP 回應表頭中。

最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊,應用程式必須允許輸入在表頭中包含 CR (Carriage Return,亦由 %0d 或 \r 指定) 與 LF (Line Feed,亦由 %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 回應,並造成不同的攻擊結果,這些攻擊包括:網頁與瀏覽器 Cache Poisoning、Cross-site Scripting 和 Page Hijacking。


Cache Poisoning:如果將惡意建構的回應快取到多個使用者使用的網頁快取或甚至單一使用者的瀏覽器快取,那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如代理伺服器中常見的網頁快取),那麼該快取的所有使用者將會繼續收到惡意內容,直到清除該快取項目為止。同樣的,如果回應貯存在單一使用者的瀏覽器中,那麼該使用者會繼續收到惡意的內容,直到清除快取項目為止,雖然只會影響本機瀏覽器實例的使用者。

Cross-Site Scripting:一旦攻擊者可以控制應用程式傳送的回應,他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式,此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼,且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言,最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持:除了利用易受攻擊的應用程式傳送惡意內容給使用者外,還可以利用具有相同本質的弱點,重新導向伺服器產生原本供使用者使用的敏感內容,轉而供攻擊者使用。藉由提交要求產生兩個回應,伺服器預期的回應和攻擊者產生的回應,攻擊者可能造成一個中間節點,例如一個共用的代理伺服器,來誤導伺服器針對使用者產生的回應傳遞給攻擊者。因為攻擊者所提出的要求產生兩個回應,第一個被解譯回應攻擊者的要求,而第二個被忘卻。當使用者透過相同 TCP 連線發出合法要求時,攻擊者的要求已處於等待狀態,並會被解讀成針對受害者要求的回應。接著,攻擊者會將第二個要求傳送到伺服器,且代理伺服器會將伺服器原本針對受害者要求產生的回應當作第二個要求的回應,如此一來,就會危及原本針對受害者的回應表頭或主體中的敏感資訊。

Cookie Manipulation:與跨網站偽造要求之類的攻擊結合時,攻擊者可能變更、新增至合法使用者的 Cookie,甚至覆寫合法使用者的 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 回應表頭包含的資料在未經驗證的情況下,便將其傳送給網頁使用者。

如同其他軟體的安全性弱點,Header Manipulation 是達到目的的一種手段,而不是一個目的。此弱點的基礎很簡單:攻擊者傳送惡意資料至有弱點的應用程式,應用程式再將該資料包含於 HTTP 回應表頭中。

最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊,應用程式必須允許輸入在表頭中包含 CR (Carriage Return,亦由 %0d 或 \r 指定) 與 LF (Line Feed,亦由 %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-site scripting 和網頁劫持。

跨用戶塗改:攻擊者將能夠發出單一要求到易受攻擊的伺服器,讓伺服器建立兩個回應,其中第二個回應可能會被錯誤解譯成針對不同要求的回應,該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成:攻擊者誘導使用者自己傳遞惡意要求,或是在遠端情況下,攻擊者和使用者共用相同的 TCP 連線連接到伺服器 (例如共用的代理伺服器)。最理想的情況是,攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊,造成使用者對應用程式的安全性失去信心。最差的狀況是,攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式執行方式,但會要求使用者重新導向要求私人資訊,例如帳戶號碼和密碼,接著會將這些資訊回傳給攻擊者。

快取破壞:如果將惡意建構的回應快取到多個使用者使用的網頁快取或甚至單一使用者的瀏覽器快取,那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如代理伺服器中常見的網頁快取),那麼該快取的所有使用者將會繼續收到惡意內容,直到清除該快取項目為止。同樣的,如果回應貯存在單一使用者的瀏覽器中,那麼該使用者會繼續收到惡意的內容,直到清除快取項目為止,雖然只會影響本機瀏覽器實例的使用者。

Cross-Site Scripting:一旦攻擊者可以控制應用程式傳送的回應,他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式,此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼,且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言,最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持:除了利用易受攻擊的應用程式傳送惡意內容給使用者外,還可以利用具有相同本質的弱點,重新導向伺服器產生原本供使用者使用的敏感內容,轉而供攻擊者使用。藉由提交要求產生兩個回應,伺服器預期的回應和攻擊者產生的回應,攻擊者可能造成一個中間節點,例如一個共用的代理伺服器,來誤導伺服器針對使用者產生的回應傳遞給攻擊者。因為攻擊者所提出的要求產生兩個回應,第一個被解譯回應攻擊者的要求,而第二個被忘卻。當使用者透過相同 TCP 連線發出合法要求時,攻擊者的要求已處於等待狀態,並會被解讀成針對受害者要求的回應。接著,攻擊者會將第二個要求傳送到伺服器,且代理伺服器會將伺服器原本針對受害者要求產生的回應當作第二個要求的回應,如此一來,就會危及原本針對受害者的回應表頭或主體中的敏感資訊。

Cookie Manipulation:與跨網站偽造要求之類的攻擊結合時,攻擊者可能變更、新增至合法使用者的 Cookie,甚至覆寫合法使用者的 Cookie。

開放式重新導向:允許未經驗證的輸入來控制重新導向中使用的 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 回應表頭包含的資料在未經驗證的情況下,便將其傳送給網頁使用者。

如同其他軟體的安全性弱點,Header Manipulation 是達到目的的一種手段,而不是一個目的。此弱點的基礎很簡單:攻擊者傳送惡意資料至有弱點的應用程式,應用程式再將該資料包含於 HTTP 回應表頭中。

最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊,應用程式必須允許輸入在表頭中包含 CR (Carriage Return,亦由 %0d 或 \r 指定) 與 LF (Line Feed,亦由 %0a 或 \n 指定) 字元。這些字元不僅讓攻擊者控制應用程式接下來要傳送的回應表頭和回應主題,還允許他們全權建立其他回應。

現今許多先進的應用程式伺服器可防止將惡意字元插入 HTTP 表頭。舉例而言,最新版的 PHP 在新行傳送 header() 至函數時,將會產生警告並停止建立表頭。如果您的 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-site scripting 和網頁劫持。

跨用戶塗改:攻擊者將能夠發出單一要求到易受攻擊的伺服器,讓伺服器建立兩個回應,其中第二個回應可能會被錯誤解譯成針對不同要求的回應,該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成:攻擊者誘導使用者自己傳遞惡意要求,或是在遠端情況下,攻擊者和使用者共用相同的 TCP 連線連接到伺服器 (例如共用的代理伺服器)。最理想的情況是,攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊,造成使用者對應用程式的安全性失去信心。最差的狀況是,攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式執行方式,但會要求使用者重新導向要求私人資訊,例如帳戶號碼和密碼,接著會將這些資訊回傳給攻擊者。

Cache Poisoning:如果將惡意建構的回應快取到多個使用者使用的網頁快取或甚至單一使用者的瀏覽器快取,那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如代理伺服器中常見的網頁快取),那麼該快取的所有使用者將會繼續收到惡意內容,直到清除該快取項目為止。同樣的,如果回應貯存在單一使用者的瀏覽器中,那麼該使用者會繼續收到惡意的內容,直到清除快取項目為止,雖然只會影響本機瀏覽器實例的使用者。

Cross-Site Scripting:一旦攻擊者可以控制應用程式傳送的回應,他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式,此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼,且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言,最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持:除了利用易受攻擊的應用程式傳送惡意內容給使用者外,還可以利用具有相同本質的弱點,重新導向伺服器產生原本供使用者使用的敏感內容,轉而供攻擊者使用。藉由提交要求產生兩個回應,伺服器預期的回應和攻擊者產生的回應,攻擊者可能造成一個中間節點,例如一個共用的代理伺服器,來誤導伺服器針對使用者產生的回應傳遞給攻擊者。因為攻擊者所提出的要求產生兩個回應,第一個被解譯回應攻擊者的要求,而第二個被忘卻。當使用者透過相同 TCP 連線發出合法要求時,攻擊者的要求已處於等待狀態,並會被解讀成針對受害者要求的回應。接著,攻擊者會將第二個要求傳送到伺服器,且代理伺服器會將伺服器原本針對受害者要求產生的回應當作第二個要求的回應,如此一來,就會危及原本針對受害者的回應表頭或主體中的敏感資訊。

Cookie Manipulation:與跨網站偽造要求之類的攻擊結合時,攻擊者可能變更、新增至合法使用者的 Cookie,甚至覆寫合法使用者的 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 回應表頭包含的資料在未經驗證的情況下,便將其傳送給網頁使用者。

如同其他軟體的安全性弱點,Header Manipulation 是達到目的的一種手段,而不是一個目的。此弱點的基礎很簡單:攻擊者傳送惡意資料至有弱點的應用程式,應用程式再將該資料包含於 HTTP 回應表頭中。

最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊,應用程式必須允許輸入在表頭中包含 CR (Carriage Return,亦由 %0d 或 \r 指定) 與 LF (Line Feed,亦由 %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-site scripting 和網頁劫持。

跨用戶塗改:攻擊者將能夠發出單一要求到易受攻擊的伺服器,讓伺服器建立兩個回應,其中第二個回應可能會被錯誤解譯成針對不同要求的回應,該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成:攻擊者誘導使用者自己傳遞惡意要求,或是在遠端情況下,攻擊者和使用者共用相同的 TCP 連線連接到伺服器 (例如共用的代理伺服器)。最理想的情況是,攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊,造成使用者對應用程式的安全性失去信心。最差的狀況是,攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式執行方式,但會要求使用者重新導向要求私人資訊,例如帳戶號碼和密碼,接著會將這些資訊回傳給攻擊者。

快取破壞:如果將惡意建構的回應快取到多個使用者使用的網頁快取或甚至單一使用者的瀏覽器快取,那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如代理伺服器中常見的網頁快取),那麼該快取的所有使用者將會繼續收到惡意內容,直到清除該快取項目為止。同樣的,如果回應貯存在單一使用者的瀏覽器中,那麼該使用者會繼續收到惡意的內容,直到清除快取項目為止,雖然只會影響本機瀏覽器實例的使用者。

Cross-Site Scripting:一旦攻擊者可以控制應用程式傳送的回應,他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式,此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼,且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言,最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持:除了利用易受攻擊的應用程式傳送惡意內容給使用者外,還可以利用具有相同本質的弱點,重新導向伺服器產生原本供使用者使用的敏感內容,轉而供攻擊者使用。藉由提交要求產生兩個回應,伺服器預期的回應和攻擊者產生的回應,攻擊者可能造成一個中間節點,例如一個共用的代理伺服器,來誤導伺服器針對使用者產生的回應傳遞給攻擊者。因為攻擊者所提出的要求產生兩個回應,第一個被解譯回應攻擊者的要求,而第二個被忘卻。當使用者透過相同 TCP 連線發出合法要求時,攻擊者的要求已處於等待狀態,並會被解讀成針對受害者要求的回應。接著,攻擊者會將第二個要求傳送到伺服器,且代理伺服器會將伺服器原本針對受害者要求產生的回應當作第二個要求的回應,如此一來,就會危及原本針對受害者的回應表頭或主體中的敏感資訊。

Cookie Manipulation:與跨網站偽造要求之類的攻擊結合時,攻擊者可能變更、新增至合法使用者的 Cookie,甚至覆寫合法使用者的 Cookie。

開放式重新導向:允許未經驗證的輸入來控制重新導向中使用的 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 回應表頭包含的資料在未經驗證的情況下,便將其傳送給網頁使用者。

如同其他軟體的安全性弱點,Header Manipulation 是達到目的的一種手段,而不是一個目的。此弱點的基礎很簡單:攻擊者傳送惡意資料至有弱點的應用程式,應用程式再將該資料包含於 HTTP 回應表頭中。

最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊,應用程式必須允許輸入在表頭中包含 CR (Carriage Return,亦由 %0d 或 \r 指定) 與 LF (Line Feed,亦由 %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-site scripting 和網頁劫持。

跨用戶塗改:攻擊者將能夠發出單一要求到易受攻擊的伺服器,讓伺服器建立兩個回應,其中第二個回應可能會被錯誤解譯成針對不同要求的回應,該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成:攻擊者誘導使用者自己傳遞惡意要求,或是在遠端情況下,攻擊者和使用者共用相同的 TCP 連線連接到伺服器 (例如共用的代理伺服器)。最理想的情況是,攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊,造成使用者對應用程式的安全性失去信心。最差的狀況是,攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式執行方式,但會要求使用者重新導向要求私人資訊,例如帳戶號碼和密碼,接著會將這些資訊回傳給攻擊者。

Cache Poisoning:如果將惡意建構的回應快取到多個使用者使用的網頁快取或甚至單一使用者的瀏覽器快取,那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如代理伺服器中常見的網頁快取),那麼該快取的所有使用者將會繼續收到惡意內容,直到清除該快取項目為止。同樣的,如果回應貯存在單一使用者的瀏覽器中,那麼該使用者會繼續收到惡意的內容,直到清除快取項目為止,雖然只會影響本機瀏覽器實例的使用者。

Cross-Site Scripting:一旦攻擊者可以控制應用程式傳送的回應,他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式,此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼,且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言,最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持:除了利用易受攻擊的應用程式傳送惡意內容給使用者外,還可以利用具有相同本質的弱點,重新導向伺服器產生原本供使用者使用的敏感內容,轉而供攻擊者使用。藉由提交要求產生兩個回應,伺服器預期的回應和攻擊者產生的回應,攻擊者可能造成一個中間節點,例如一個共用的代理伺服器,來誤導伺服器針對使用者產生的回應傳遞給攻擊者。因為攻擊者所提出的要求產生兩個回應,第一個被解譯回應攻擊者的要求,而第二個被忘卻。當使用者透過相同 TCP 連線發出合法要求時,攻擊者的要求已處於等待狀態,並會被解讀成針對受害者要求的回應。接著,攻擊者會將第二個要求傳送到伺服器,且代理伺服器會將伺服器原本針對受害者要求產生的回應當作第二個要求的回應,如此一來,就會危及原本針對受害者的回應表頭或主體中的敏感資訊。

Cookie Manipulation:與跨網站偽造要求之類的攻擊結合時,攻擊者可能變更、新增至合法使用者的 Cookie,甚至覆寫合法使用者的 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 回應表頭包含的資料在未經驗證的情況下,便將其傳送給網頁使用者。

如同其他軟體的安全性弱點,Header Manipulation 是達到目的的一種手段,而不是一個目的。此弱點的基礎很簡單:攻擊者傳送惡意資料至有弱點的應用程式,應用程式再將該資料包含於 HTTP 回應表頭中。

最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊,應用程式必須允許輸入在表頭中包含 CR (Carriage Return,亦由 %0d 或 \r 指定) 與 LF (Line Feed,亦由 %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-site scripting 和網頁劫持。

跨用戶塗改:攻擊者將能夠發出單一要求到易受攻擊的伺服器,讓伺服器建立兩個回應,其中第二個回應可能會被錯誤解譯成針對不同要求的回應,該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成:攻擊者誘導使用者自己傳遞惡意要求,或是在遠端情況下,攻擊者和使用者共用相同的 TCP 連線連接到伺服器 (例如共用的代理伺服器)。最理想的情況是,攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊,造成使用者對應用程式的安全性失去信心。最差的狀況是,攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式執行方式,但會要求使用者重新導向要求私人資訊,例如帳戶號碼和密碼,接著會將這些資訊回傳給攻擊者。

Cache Poisoning:如果將惡意建構的回應快取到多個使用者使用的網頁快取或甚至單一使用者的瀏覽器快取,那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如代理伺服器中常見的網頁快取),那麼該快取的所有使用者將會繼續收到惡意內容,直到清除該快取項目為止。同樣的,如果回應貯存在單一使用者的瀏覽器中,那麼該使用者會繼續收到惡意的內容,直到清除快取項目為止,雖然只會影響本機瀏覽器實例的使用者。

Cross-Site Scripting:一旦攻擊者可以控制應用程式傳送的回應,他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式,此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼,且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言,最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持:除了利用易受攻擊的應用程式傳送惡意內容給使用者外,還可以利用具有相同本質的弱點,重新導向伺服器產生原本供使用者使用的敏感內容,轉而供攻擊者使用。藉由提交要求產生兩個回應,伺服器預期的回應和攻擊者產生的回應,攻擊者可能造成一個中間節點,例如一個共用的代理伺服器,來誤導伺服器針對使用者產生的回應傳遞給攻擊者。因為攻擊者所提出的要求產生兩個回應,第一個被解譯回應攻擊者的要求,而第二個被忘卻。當使用者透過相同 TCP 連線發出合法要求時,攻擊者的要求已處於等待狀態,並會被解讀成針對受害者要求的回應。接著,攻擊者會將第二個要求傳送到伺服器,且代理伺服器會將伺服器原本針對受害者要求產生的回應當作第二個要求的回應,如此一來,就會危及原本針對受害者的回應表頭或主體中的敏感資訊。

Cookie Manipulation:與跨網站偽造要求之類的攻擊結合時,攻擊者可能變更、新增至合法使用者的 Cookie,甚至覆寫合法使用者的 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. HTTP 回應標頭包含的資料在未經驗證的情況下便傳送給 Web 使用者。

如同許多軟體的安全性弱點,Header Manipulation 是達到目的的一種手段,而不是一個目的。 此弱點的基礎很簡單:攻擊者將惡意資料傳送至容易受到攻擊的應用程式,應用程式再將該資料包含於 HTTP 回應標頭中。

最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。 為了成功進行 HTTP Response Splitting 攻擊,應用程式必須允許輸入在標頭中包含 CR (Carriage Return,亦由 %0d 或 \r 指定) 與 LF (Line Feed,亦由 %0a 或 \n 指定) 字元。 這些字元不僅讓攻擊者控制應用程式接下來要傳送之回應的剩餘標頭和正文,還允許它們全權建立其他回應。

現今許多先進的應用程式伺服器可防止將惡意字元插入 HTTP 標頭。 舉例來說,如果您嘗試使用禁用的字元設定標頭,Play Framework 會拋出一個異常。 如果應用程式伺服器可防止使用換行字元來設定標頭,則您的應用程式面對 HTTP Response Splitting 的攻擊,具有一定的防禦能力。 但是,僅篩選換行字元,應用程式可能仍對 Cookie Manipulation 或 Open Redirect 攻擊無招架能力,所以透過使用者輸入設定 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 回應表頭包含的資料在未經驗證的情況下,便將其傳送給網頁使用者。

如同其他軟體的安全性弱點,Header Manipulation 是達到目的的一種手段,而不是一個目的。此弱點的基礎很簡單:攻擊者傳送惡意資料至有弱點的應用程式,應用程式再將該資料包含於 HTTP 回應表頭中。

最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊,應用程式必須允許輸入在表頭中包含 CR (Carriage Return,亦由 %0d 或 \r 指定) 與 LF (Line Feed,亦由 %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-site scripting 和網頁劫持。

跨用戶塗改:攻擊者將能夠發出單一要求到易受攻擊的伺服器,讓伺服器建立兩個回應,其中第二個回應可能會被錯誤解譯成針對不同要求的回應,該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成:攻擊者誘導使用者自己傳遞惡意要求,或是在遠端情況下,攻擊者和使用者共用相同的 TCP 連線連接到伺服器 (例如共用的代理伺服器)。最理想的情況是,攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊,造成使用者對應用程式的安全性失去信心。最差的狀況是,攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式執行方式,但會要求使用者重新導向要求私人資訊,例如帳戶號碼和密碼,接著會將這些資訊回傳給攻擊者。

快取破壞:如果將惡意建構的回應快取到多個使用者使用的網頁快取或甚至單一使用者的瀏覽器快取,那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如代理伺服器中常見的網頁快取),那麼該快取的所有使用者將會繼續收到惡意內容,直到清除該快取項目為止。同樣的,如果回應貯存在單一使用者的瀏覽器中,那麼該使用者會繼續收到惡意的內容,直到清除快取項目為止,雖然只會影響本機瀏覽器實例的使用者。

Cross-Site Scripting:一旦攻擊者可以控制應用程式傳送的回應,他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式,此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼,且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言,最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持:除了利用易受攻擊的應用程式傳送惡意內容給使用者外,還可以利用具有相同本質的弱點,重新導向伺服器產生原本供使用者使用的敏感內容,轉而供攻擊者使用。藉由提交要求產生兩個回應,伺服器預期的回應和攻擊者產生的回應,攻擊者可能造成一個中間節點,例如一個共用的代理伺服器,來誤導伺服器針對使用者產生的回應傳遞給攻擊者。因為攻擊者所提出的要求產生兩個回應,第一個被解譯回應攻擊者的要求,而第二個被忘卻。當使用者透過相同 TCP 連線發出合法要求時,攻擊者的要求已處於等待狀態,並會被解讀成針對受害者要求的回應。接著,攻擊者會將第二個要求傳送到伺服器,且代理伺服器會將伺服器原本針對受害者要求產生的回應當作第二個要求的回應,如此一來,就會危及原本針對受害者的回應表頭或主體中的敏感資訊。

Cookie Manipulation:與跨網站偽造要求之類的攻擊結合時,攻擊者可能變更、新增至合法使用者的 Cookie,甚至覆寫合法使用者的 Cookie。

開放式重新導向:允許未經驗證的輸入來控制重新導向中使用的 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 回應表頭包含的資料在未經驗證的情況下,便將其傳送給網頁使用者。

如同其他軟體的安全性弱點,Header Manipulation 是達到目的的一種手段,而不是一個目的。此弱點的基礎很簡單:攻擊者傳送惡意資料至有弱點的應用程式,應用程式再將該資料包含於 HTTP 回應表頭中。

最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊,應用程式必須允許輸入在表頭中包含 CR (Carriage Return,亦由 %0d 或 \r 指定) 與 LF (Line Feed,亦由 %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-site scripting 和網頁劫持。

跨用戶塗改:攻擊者將能夠發出單一要求到易受攻擊的伺服器,讓伺服器建立兩個回應,其中第二個回應可能會被錯誤解譯成針對不同要求的回應,該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成:攻擊者誘導使用者自己傳遞惡意要求,或是在遠端情況下,攻擊者和使用者共用相同的 TCP 連線連接到伺服器 (例如共用的代理伺服器)。最理想的情況是,攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊,造成使用者對應用程式的安全性失去信心。最差的狀況是,攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式執行方式,但會要求使用者重新導向要求私人資訊,例如帳戶號碼和密碼,接著會將這些資訊回傳給攻擊者。

快取破壞:如果將惡意建構的回應快取到多個使用者使用的網頁快取或甚至單一使用者的瀏覽器快取,那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如代理伺服器中常見的網頁快取),那麼該快取的所有使用者將會繼續收到惡意內容,直到清除該快取項目為止。同樣的,如果回應貯存在單一使用者的瀏覽器中,那麼該使用者會繼續收到惡意的內容,直到清除快取項目為止,雖然只會影響本機瀏覽器實例的使用者。

Cross-Site Scripting:一旦攻擊者可以控制應用程式傳送的回應,他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式,此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼,且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言,最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持:除了利用易受攻擊的應用程式傳送惡意內容給使用者外,還可以利用具有相同本質的弱點,重新導向伺服器產生原本供使用者使用的敏感內容,轉而供攻擊者使用。藉由提交要求產生兩個回應,伺服器預期的回應和攻擊者產生的回應,攻擊者可能造成一個中間節點,例如一個共用的代理伺服器,來誤導伺服器針對使用者產生的回應傳遞給攻擊者。因為攻擊者所提出的要求產生兩個回應,第一個被解譯回應攻擊者的要求,而第二個被忘卻。當使用者透過相同 TCP 連線發出合法要求時,攻擊者的要求已處於等待狀態,並會被解讀成針對受害者要求的回應。接著,攻擊者會將第二個要求傳送到伺服器,且代理伺服器會將伺服器原本針對受害者要求產生的回應當作第二個要求的回應,如此一來,就會危及原本針對受害者的回應表頭或主體中的敏感資訊。

Cookie Manipulation:與跨網站偽造要求之類的攻擊結合時,攻擊者可能變更、新增至合法使用者的 Cookie,甚至覆寫合法使用者的 Cookie。

開放式重新導向:允許未經驗證的輸入來控制重新導向中使用的 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
在 Cookie 中包含未經驗證的資料會導致 HTTP 回應 Header manipulation,並引發 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect。
Explanation
Cookie Manipulation 弱點會在以下情況中出現:

1. 資料透過不可信賴的來源進入 Web 應用程式,通常是 HTTP 要求。

2. HTTP Cookie 包含的資料在未經驗證的情況下,便傳送給網頁使用者。

與許多軟體的安全性弱點一樣,Cookie manipulation 是達到目的的一種手段,而不是目的本身。此弱點的基礎很簡單:攻擊者傳送惡意資料至有弱點的應用程式,應用程式再將該資料包含於 HTTP Cookie 中。

Cookie Manipulation:與跨網站偽造要求之類的攻擊結合時,攻擊者可能變更、新增至合法使用者的 Cookie,甚至覆寫合法使用者的 Cookie。

由於 HTTP 回應表頭,Cookie manipulation 攻擊還會導致其他類型的攻擊,例如:

HTTP Response Splitting:
最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊,應用程式必須允許輸入在表頭中包含 CR (Carriage Return,亦由 %0d 或 \r 指定) 與 LF (Line Feed,亦由 %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-site scripting 和網頁劫持。

跨用戶塗改:攻擊者將能夠發出單一要求到易受攻擊的伺服器,讓伺服器建立兩個回應,其中第二個回應可能會被錯誤解譯成針對不同要求的回應,該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成:攻擊者誘導使用者自己傳遞惡意要求,或是在遠端情況下,攻擊者和使用者共用相同的 TCP 連線連接到伺服器 (例如共用的代理伺服器)。最理想的情況是,攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊,造成使用者對應用程式的安全性失去信心。最差的狀況是,攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式執行方式,但會要求使用者重新導向要求私人資訊,例如帳戶號碼和密碼,接著會將這些資訊回傳給攻擊者。

Cache Poisoning:如果將惡意建構的回應快取到多個使用者使用的網頁快取或甚至單一使用者的瀏覽器快取,那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如代理伺服器中常見的網頁快取),那麼該快取的所有使用者將會繼續收到惡意內容,直到清除該快取項目為止。同樣的,如果回應貯存在單一使用者的瀏覽器中,那麼該使用者會繼續收到惡意的內容,直到清除快取項目為止,雖然只會影響本機瀏覽器實例的使用者。

Cross-Site Scripting:一旦攻擊者可以控制應用程式傳送的回應,他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式,此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼,且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言,最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持:除了利用易受攻擊的應用程式傳送惡意內容給使用者外,還可以利用具有相同本質的弱點,重新導向伺服器產生原本供使用者使用的敏感內容,轉而供攻擊者使用。藉由提交要求產生兩個回應,伺服器預期的回應和攻擊者產生的回應,攻擊者可能造成一個中間節點,例如一個共用的代理伺服器,來誤導伺服器針對使用者產生的回應傳遞給攻擊者。因為攻擊者所提出的要求產生兩個回應,第一個被解譯回應攻擊者的要求,而第二個被忘卻。當使用者透過相同 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.HTTP Cookie 包含的資料在未經驗證的情況下,便傳送給 Web 使用者。



與許多軟體的安全性弱點一樣,Cookie Manipulation 是達到目的的一種手段,而不是目的本身。此弱點的基礎很簡單:攻擊者將惡意資料傳送至容易受到攻擊的應用程式,應用程式再將該資料包含於 HTTP Cookie 中。

Cookie Manipulation:與 Cross-Site Request Forgery 之類的攻擊結合時,攻擊者可能變更、新增合法使用者的 Cookie 或甚至覆寫合法使用者的 Cookie。

由於 HTTP 回應標頭的緣故,Cookie Manipulation 攻擊還可能導致其他類型的攻擊,例如:

HTTP Response Splitting:
最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊,應用程式必須允許輸入在標頭中包含 CR (Carriage Return,亦由 %0d 或 \r 指定) 與 LF (Line Feed,亦由 %0a 或 \n 指定) 字元。這些字元不僅讓攻擊者控制應用程式接下來要傳送的回應的剩餘標頭和本文,還允許他們建立完全在他們控制下的其他回應。

現今許多新型的應用程式伺服器可防止將惡意字元插入 HTTP 標頭。例如,如果您嘗試使用禁用的字元設定標頭,最新版的 Apache Tomcat 會擲回 IllegalArgumentException。如果應用程式伺服器可防止使用換行字元來設定標頭,則您的應用程式面對 HTTP Response Splitting 的攻擊,具有一定的防禦能力。但是,僅篩選換行字元,應用程式可能仍對 Cookie Manipulation 或 Open Redirect 攻擊無招架能力,所以透過使用者輸入設定 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 連線的使用者所發出的。這種攻擊可以下列方式達成:攻擊者誘導使用者自己提交惡意要求;或是在遠端情況下,攻擊者和使用者共用相同的連線到伺服器 (例如共用的 Proxy 伺服器) 的 TCP 連線。最理想的情況是,攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊,造成使用者對應用程式的安全性失去信心。最差的狀況是,攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式的行為,但會將隱私資訊 (例如帳戶和密碼) 重新導向回攻擊者。

Cache Poisoning:如果將惡意建構的回應快取到多個使用者使用的網頁快取或單一使用者的瀏覽器快取,那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如 Proxy 伺服器中常見的網頁快取),那麼該快取的所有使用者將會繼續收到惡意內容,直到清除該快取項目為止。同樣地,如果回應快取到單一使用者的瀏覽器中,那麼該使用者會繼續收到惡意內容,直到清除該快取項目為止,但是只有本機瀏覽器執行個體的使用者會受到影響。

Cross-Site Scripting:一旦攻擊者可以控制應用程式傳送的回應,他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式,此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼,且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言,最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持:除了利用易受攻擊的應用程式傳送惡意內容給使用者外,還可以利用具有相同本質的弱點,重新導向伺服器所產生且原本應供使用者使用的敏感內容,轉而供攻擊者使用。攻擊者藉由提交一個要求產生兩個回應,伺服器預期的回應和攻擊者產生的回應,致使中間節點 (例如共用的 Proxy 伺服器) 錯誤地將本應傳送給使用者的伺服器產生的回應傳送給攻擊者。因為攻擊者所提出的要求產生兩個回應,因此第一個被解譯為回應攻擊者的要求,而第二個則被忘卻。當使用者透過相同 TCP 連線發出合法要求時,攻擊者的要求已處於等待狀態,並會被解讀成針對受害者要求的回應。接著,攻擊者將第二個要求傳送到伺服器,Proxy 伺服器會使用伺服器針對受害者產生的要求回應伺服器,如此一來,就會危及原本針對受害者的回應標頭或本文中的敏感資訊。

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
在 Cookie 中包含未經驗證的資料會導致 HTTP 回應 Header manipulation,並引發 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect。
Explanation
Cookie Manipulation 弱點會在以下情況中出現:

1. 資料透過不可信賴的來源進入 Web 應用程式,通常是 HTTP 要求。

2. HTTP Cookie 包含的資料在未經驗證的情況下,便傳送給網頁使用者。

與許多軟體的安全性弱點一樣,Cookie manipulation 是達到目的的一種手段,而不是目的本身。此弱點的基礎很簡單:攻擊者傳送惡意資料至有弱點的應用程式,應用程式再將該資料包含於 HTTP Cookie 中。

Cookie Manipulation:與跨網站偽造要求之類的攻擊結合時,攻擊者可能變更、新增至合法使用者的 Cookie,甚至覆寫合法使用者的 Cookie。

由於 HTTP 回應表頭,Cookie manipulation 攻擊還會導致其他類型的攻擊,例如:

HTTP Response Splitting:
最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊,應用程式必須允許輸入在表頭中包含 CR (Carriage Return,亦由 %0d 或 \r 指定) 與 LF (Line Feed,亦由 %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-site scripting 和網頁劫持。

跨用戶塗改:攻擊者將能夠發出單一要求到易受攻擊的伺服器,讓伺服器建立兩個回應,其中第二個回應可能會被錯誤解譯成針對不同要求的回應,該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成:攻擊者誘導使用者自己傳遞惡意要求,或是在遠端情況下,攻擊者和使用者共用相同的 TCP 連線連接到伺服器 (例如共用的代理伺服器)。最理想的情況是,攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊,造成使用者對應用程式的安全性失去信心。最差的狀況是,攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式執行方式,但會要求使用者重新導向要求私人資訊,例如帳戶號碼和密碼,接著會將這些資訊回傳給攻擊者。

快取破壞:如果將惡意建構的回應快取到多個使用者使用的網頁快取或甚至單一使用者的瀏覽器快取,那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如代理伺服器中常見的網頁快取),那麼該快取的所有使用者將會繼續收到惡意內容,直到清除該快取項目為止。同樣的,如果回應貯存在單一使用者的瀏覽器中,那麼該使用者會繼續收到惡意的內容,直到清除快取項目為止,雖然只會影響本機瀏覽器實例的使用者。

Cross-Site Scripting:一旦攻擊者可以控制應用程式傳送的回應,他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式,此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼,且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言,最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持:除了利用易受攻擊的應用程式傳送惡意內容給使用者外,還可以利用具有相同本質的弱點,重新導向伺服器產生原本供使用者使用的敏感內容,轉而供攻擊者使用。藉由提交要求產生兩個回應,伺服器預期的回應和攻擊者產生的回應,攻擊者可能造成一個中間節點,例如一個共用的代理伺服器,來誤導伺服器針對使用者產生的回應傳遞給攻擊者。因為攻擊者所提出的要求產生兩個回應,第一個被解譯回應攻擊者的要求,而第二個被忘卻。當使用者透過相同 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.dotnet.header_manipulation_cookies
Abstract
在 Cookie 中包含未經驗證的資料會導致 HTTP 回應 Header manipulation,並引發 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect。
Explanation
Cookie Manipulation 弱點會在以下情況中出現:

1. 資料透過不可信賴的來源進入 Web 應用程式,通常是 HTTP 要求。

2. HTTP Cookie 包含的資料在未經驗證的情況下,便傳送給網頁使用者。

與許多軟體的安全性弱點一樣,Cookie manipulation 是達到目的的一種手段,而不是目的本身。此弱點的基礎很簡單:攻擊者傳送惡意資料至有弱點的應用程式,應用程式再將該資料包含於 HTTP Cookie 中。

Cookie Manipulation:與跨網站偽造要求之類的攻擊結合時,攻擊者可能變更、新增至合法使用者的 Cookie,甚至覆寫合法使用者的 Cookie。

由於 HTTP 回應表頭,Cookie manipulation 攻擊還會導致其他類型的攻擊,例如:

HTTP Response Splitting:
最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊,應用程式必須允許輸入在表頭中包含 CR (Carriage Return,亦由 %0d 或 \r 指定) 與 LF (Line Feed,亦由 %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-site scripting 和網頁劫持。

跨用戶塗改:攻擊者將能夠發出單一要求到易受攻擊的伺服器,讓伺服器建立兩個回應,其中第二個回應可能會被錯誤解譯成針對不同要求的回應,該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成:攻擊者誘導使用者自己傳遞惡意要求,或是在遠端情況下,攻擊者和使用者共用相同的 TCP 連線連接到伺服器 (例如共用的代理伺服器)。最理想的情況是,攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊,造成使用者對應用程式的安全性失去信心。最差的狀況是,攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式執行方式,但會要求使用者重新導向要求私人資訊,例如帳戶號碼和密碼,接著會將這些資訊回傳給攻擊者。

Cache Poisoning:如果將惡意建構的回應快取到多個使用者使用的網頁快取或甚至單一使用者的瀏覽器快取,那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如代理伺服器中常見的網頁快取),那麼該快取的所有使用者將會繼續收到惡意內容,直到清除該快取項目為止。同樣的,如果回應貯存在單一使用者的瀏覽器中,那麼該使用者會繼續收到惡意的內容,直到清除快取項目為止,雖然只會影響本機瀏覽器實例的使用者。

Cross-Site Scripting:一旦攻擊者可以控制應用程式傳送的回應,他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式,此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼,且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言,最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持:除了利用易受攻擊的應用程式傳送惡意內容給使用者外,還可以利用具有相同本質的弱點,重新導向伺服器產生原本供使用者使用的敏感內容,轉而供攻擊者使用。藉由提交要求產生兩個回應,伺服器預期的回應和攻擊者產生的回應,攻擊者可能造成一個中間節點,例如一個共用的代理伺服器,來誤導伺服器針對使用者產生的回應傳遞給攻擊者。因為攻擊者所提出的要求產生兩個回應,第一個被解譯回應攻擊者的要求,而第二個被忘卻。當使用者透過相同 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.HTTP Cookie 包含的資料在未經驗證的情況下,便傳送給 Web 使用者。

與許多軟體的安全性弱點一樣,Cookie Manipulation 是達到目的的一種手段,而不是目的本身。此弱點的基礎很簡單:攻擊者將惡意資料傳送至容易受到攻擊的應用程式,應用程式再將該資料包含於 HTTP Cookie 中。

Cookie Manipulation:與 Cross-Site Request Forgery 之類的攻擊結合時,攻擊者可以變更、新增合法使用者的 Cookie 或甚至覆寫合法使用者的 Cookie。

由於 HTTP 回應標頭的緣故,Cookie Manipulation 攻擊還可能導致其他類型的攻擊,例如:

HTTP Response Splitting:
最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊,應用程式必須允許輸入在標頭中包含 CR (Carriage Return,亦由 %0d 或 \r 指定) 與 LF (Line Feed,亦由 %0a 或 \n 指定) 字元。這些字元不僅讓攻擊者控制應用程式接下來要傳送之回應的剩餘標頭和正文,還允許它們全權建立其他回應。

現今許多新型的應用程式伺服器可防止將惡意字元插入 HTTP 標頭。舉例來說,如果您嘗試使用禁用的字元設定標頭,最新版的 Apache Tomcat 會拋出 IllegalArgumentException。如果應用程式伺服器可防止使用換行字元來設定標頭,則您的應用程式面對 HTTP Response Splitting 的攻擊,具有一定的防禦能力。但是,僅篩選換行字元,應用程式可能仍對 Cookie Manipulation 或 Open Redirect 攻擊無招架能力,所以透過使用者輸入設定 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-site scripting 和網頁劫持。

Cross-User Defacement:攻擊者可以發出一個要求到易受攻擊的伺服器,讓伺服器建立兩個回應,其中第二個回應可能會被錯誤解讀成針對不同要求的回應,該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成:攻擊者誘導使用者自己提交惡意要求;或是在遠端情況下,攻擊者和使用者共用相同的連線到伺服器 (例如共用的 Proxy 伺服器) 的 TCP 連線。最理想的情況是,攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊,造成使用者對應用程式的安全性失去信心。最差的狀況是,攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式的行為,但會將隱私資訊 (例如帳號和密碼) 重新導向回攻擊者。

Cache Poisoning:如果將惡意建構的回應快取到多個使用者使用的網頁快取或單一使用者的瀏覽器快取,那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如 Proxy 伺服器中常見的網頁快取),那麼該快取的所有使用者將會繼續收到惡意內容,直到清除該快取項目為止。同樣地,如果回應快取到單一使用者的瀏覽器中,那麼該使用者會繼續收到惡意內容,直到清除該快取項目為止,但是只有本機瀏覽器實例的使用者會受到影響。

Cross-Site Scripting:在攻擊者控制應用程式傳送的回應之後,他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式,此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼,且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言,最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持:除了利用易受攻擊的應用程式傳送惡意內容給使用者外,攻擊者還可以利用具有相同本質的弱點,重新導向伺服器所產生且原本供使用者使用的敏感內容,轉而供攻擊者使用。攻擊者藉由提交一個要求產生兩個回應,伺服器預期的回應和攻擊者產生的回應,致使中間節點 (例如共用的 Proxy 服務器) 錯誤地將本應傳送給使用者的伺服器產生的回應傳送給攻擊者。因為攻擊者所提出的要求產生兩個回應,因此第一個被解譯為回應攻擊者的要求,而第二個則被忘卻。當使用者透過相同 TCP 連線發出合法要求時,攻擊者的要求已處於等待狀態,並會被解讀成針對受害者要求的回應。接著,攻擊者將第二個要求傳送到伺服器,Proxy 伺服器會使用伺服器針對受害者產生的要求回應伺服器,如此一來,就會危及原本針對受害者的回應標頭或本文中的敏感資訊。

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
在 Cookie 中包含未經驗證的資料會導致 HTTP 回應 Header manipulation,並引發 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect。
Explanation
Cookie Manipulation 弱點會在以下情況中出現:

1. 資料透過不可信賴的來源進入 Web 應用程式,通常是 HTTP 要求。

2. HTTP Cookie 包含的資料在未經驗證的情況下,便傳送給網頁使用者。

與許多軟體的安全性弱點一樣,Cookie manipulation 是達到目的的一種手段,而不是目的本身。此弱點的基礎很簡單:攻擊者傳送惡意資料至有弱點的應用程式,應用程式再將該資料包含於 HTTP Cookie 中。

Cookie Manipulation:與跨網站偽造要求之類的攻擊結合時,攻擊者可能變更、新增至合法使用者的 Cookie,甚至覆寫合法使用者的 Cookie。

由於 HTTP 回應表頭,Cookie manipulation 攻擊還會導致其他類型的攻擊,例如:

HTTP Response Splitting:
最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊,應用程式必須允許輸入在表頭中包含 CR (Carriage Return,亦由 %0d 或 \r 指定) 與 LF (Line Feed,亦由 %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-site scripting 和網頁劫持。

有人認為在行動環境中,典型的 Web 應用程式弱點 (例如 Header Manipulation 與 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);

...
跨用戶塗改:攻擊者將能夠發出單一要求到易受攻擊的伺服器,讓伺服器建立兩個回應,其中第二個回應可能會被錯誤解譯成針對不同要求的回應,該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成:攻擊者誘導使用者自己傳遞惡意要求,或是在遠端情況下,攻擊者和使用者共用相同的 TCP 連線連接到伺服器 (例如共用的代理伺服器)。最理想的情況是,攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊,造成使用者對應用程式的安全性失去信心。最差的狀況是,攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式執行方式,但會要求使用者重新導向要求私人資訊,例如帳戶號碼和密碼,接著會將這些資訊回傳給攻擊者。

Cache Poisoning:如果將惡意建構的回應快取到多個使用者使用的網頁快取或甚至單一使用者的瀏覽器快取,那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如代理伺服器中常見的網頁快取),那麼該快取的所有使用者將會繼續收到惡意內容,直到清除該快取項目為止。同樣的,如果回應貯存在單一使用者的瀏覽器中,那麼該使用者會繼續收到惡意的內容,直到清除快取項目為止,雖然只會影響本機瀏覽器實例的使用者。

Cross-Site Scripting:一旦攻擊者可以控制應用程式傳送的回應,他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式,此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼,且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言,最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持:除了利用易受攻擊的應用程式傳送惡意內容給使用者外,還可以利用具有相同本質的弱點,重新導向伺服器產生原本供使用者使用的敏感內容,轉而供攻擊者使用。藉由提交要求產生兩個回應,伺服器預期的回應和攻擊者產生的回應,攻擊者可能造成一個中間節點,例如一個共用的代理伺服器,來誤導伺服器針對使用者產生的回應傳遞給攻擊者。因為攻擊者所提出的要求產生兩個回應,第一個被解譯回應攻擊者的要求,而第二個被忘卻。當使用者透過相同 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.java.header_manipulation_cookies
Abstract
在 Cookie 中包含未經驗證的資料會導致 HTTP 回應 Header manipulation,並引發 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect。
Explanation
Cookie Manipulation 弱點會在以下情況中出現:

1. 資料透過不可信賴的來源進入 Web 應用程式,通常是 HTTP 要求。

2. HTTP Cookie 包含的資料在未經驗證的情況下,便傳送給網頁使用者。

與許多軟體的安全性弱點一樣,Cookie manipulation 是達到目的的一種手段,而不是目的本身。此弱點的基礎很簡單:攻擊者傳送惡意資料至有弱點的應用程式,應用程式再將該資料包含於 HTTP Cookie 中。

Cookie Manipulation:與跨網站偽造要求之類的攻擊結合時,攻擊者可能變更、新增至合法使用者的 Cookie,甚至覆寫合法使用者的 Cookie。

由於 HTTP 回應表頭,Cookie manipulation 攻擊還會導致其他類型的攻擊,例如:

HTTP Response Splitting:
最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊,應用程式必須允許輸入在表頭中包含 CR (Carriage Return,亦由 %0d 或 \r 指定) 與 LF (Line Feed,亦由 %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-site scripting 和網頁劫持。

Cross-User Defacement:攻擊者可以發出一個要求到易受攻擊的伺服器,讓伺服器建立兩個回應,其中第二個回應可能會被錯誤解讀成針對不同要求的回應,該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成:攻擊者誘導使用者自己提交惡意要求;或是在遠端情況下,攻擊者和使用者共用相同的連線到伺服器 (例如共用的 Proxy 伺服器) 的 TCP 連線。最理想的情況是,攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊,造成使用者對應用程式的安全性失去信心。最差的狀況是,攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式的行為,但會將隱私資訊 (例如帳戶和密碼) 重新導向回攻擊者。

Cache Poisoning:如果將惡意建構的回應快取到多個使用者使用的網頁快取或甚至單一使用者的瀏覽器快取,那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如代理伺服器中常見的網頁快取),那麼該快取的所有使用者將會繼續收到惡意內容,直到清除該快取項目為止。同樣的,如果回應貯存在單一使用者的瀏覽器中,那麼該使用者會繼續收到惡意的內容,直到清除快取項目為止,雖然只會影響本機瀏覽器實例的使用者。

Cross-Site Scripting:一旦攻擊者可以控制應用程式傳送的回應,他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式,此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼,且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言,最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持:除了利用易受攻擊的應用程式傳送惡意內容給使用者外,還可以利用具有相同本質的弱點,重新導向伺服器產生原本供使用者使用的敏感內容,轉而供攻擊者使用。藉由提交要求產生兩個回應,伺服器預期的回應和攻擊者產生的回應,攻擊者可能造成一個中間節點,例如一個共用的代理伺服器,來誤導伺服器針對使用者產生的回應傳遞給攻擊者。因為攻擊者所提出的要求產生兩個回應,第一個被解譯回應攻擊者的要求,而第二個被忘卻。當使用者透過相同 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
在 Cookie 中包含未經驗證的資料會導致 HTTP 回應 Header manipulation,並引發 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect。
Explanation
Cookie Manipulation 弱點會在以下情況中出現:

1. 資料透過不可信賴的來源進入 Web 應用程式,通常是 HTTP 要求。

2. HTTP Cookie 包含的資料在未經驗證的情況下,便傳送給網頁使用者。

與許多軟體的安全性弱點一樣,Cookie manipulation 是達到目的的一種手段,而不是目的本身。此弱點的基礎很簡單:攻擊者傳送惡意資料至有弱點的應用程式,應用程式再將該資料包含於 HTTP Cookie 中。

Cookie Manipulation:與跨網站偽造要求之類的攻擊結合時,攻擊者可能變更、新增至合法使用者的 Cookie,甚至覆寫合法使用者的 Cookie。

由於 HTTP 回應表頭,Cookie manipulation 攻擊還會導致其他類型的攻擊,例如:

HTTP Response Splitting:
最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊,應用程式必須允許輸入在表頭中包含 CR (Carriage Return,亦由 %0d 或 \r 指定) 與 LF (Line Feed,亦由 %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-site scripting 和網頁劫持。

跨用戶塗改:攻擊者將能夠發出單一要求到易受攻擊的伺服器,讓伺服器建立兩個回應,其中第二個回應可能會被錯誤解譯成針對不同要求的回應,該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成:攻擊者誘導使用者自己傳遞惡意要求,或是在遠端情況下,攻擊者和使用者共用相同的 TCP 連線連接到伺服器 (例如共用的代理伺服器)。最理想的情況是,攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊,造成使用者對應用程式的安全性失去信心。最差的狀況是,攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式執行方式,但會要求使用者重新導向要求私人資訊,例如帳戶號碼和密碼,接著會將這些資訊回傳給攻擊者。

Cache Poisoning:如果將惡意建構的回應快取到多個使用者使用的網頁快取或甚至單一使用者的瀏覽器快取,那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如代理伺服器中常見的網頁快取),那麼該快取的所有使用者將會繼續收到惡意內容,直到清除該快取項目為止。同樣的,如果回應貯存在單一使用者的瀏覽器中,那麼該使用者會繼續收到惡意的內容,直到清除快取項目為止,雖然只會影響本機瀏覽器實例的使用者。

Cross-Site Scripting:一旦攻擊者可以控制應用程式傳送的回應,他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式,此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼,且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言,最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持:除了利用易受攻擊的應用程式傳送惡意內容給使用者外,還可以利用具有相同本質的弱點,重新導向伺服器產生原本供使用者使用的敏感內容,轉而供攻擊者使用。藉由提交要求產生兩個回應,伺服器預期的回應和攻擊者產生的回應,攻擊者可能造成一個中間節點,例如一個共用的代理伺服器,來誤導伺服器針對使用者產生的回應傳遞給攻擊者。因為攻擊者所提出的要求產生兩個回應,第一個被解譯回應攻擊者的要求,而第二個被忘卻。當使用者透過相同 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 回應表頭包含的資料在未經驗證的情況下,便將其傳送給網頁使用者。

如同其他軟體的安全性弱點,Header Manipulation 是達到目的的一種手段,而不是一個目的。此弱點的基礎很簡單:攻擊者傳送惡意資料至有弱點的應用程式,應用程式再將該資料包含於 HTTP 回應表頭中。

最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊,應用程式必須允許輸入在表頭中包含 CR (Carriage Return,亦由 %0d 或 \r 指定) 與 LF (Line Feed,亦由 %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-site scripting 和網頁劫持。

跨用戶塗改:攻擊者將能夠發出單一要求到易受攻擊的伺服器,讓伺服器建立兩個回應,其中第二個回應可能會被錯誤解譯成針對不同要求的回應,該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成:攻擊者誘導使用者自己傳遞惡意要求,或是在遠端情況下,攻擊者和使用者共用相同的 TCP 連線連接到伺服器 (例如共用的代理伺服器)。最理想的情況是,攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊,造成使用者對應用程式的安全性失去信心。最差的狀況是,攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式執行方式,但會要求使用者重新導向要求私人資訊,例如帳戶號碼和密碼,接著會將這些資訊回傳給攻擊者。

Cache Poisoning:如果將惡意建構的回應快取到多個使用者使用的網頁快取或甚至單一使用者的瀏覽器快取,那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如代理伺服器中常見的網頁快取),那麼該快取的所有使用者將會繼續收到惡意內容,直到清除該快取項目為止。同樣的,如果回應貯存在單一使用者的瀏覽器中,那麼該使用者會繼續收到惡意的內容,直到清除快取項目為止,雖然只會影響本機瀏覽器實例的使用者。

Cross-Site Scripting:一旦攻擊者可以控制應用程式傳送的回應,他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式,此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼,且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言,最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持:除了利用易受攻擊的應用程式傳送惡意內容給使用者外,還可以利用具有相同本質的弱點,重新導向伺服器產生原本供使用者使用的敏感內容,轉而供攻擊者使用。藉由提交要求產生兩個回應,伺服器預期的回應和攻擊者產生的回應,攻擊者可能造成一個中間節點,例如一個共用的代理伺服器,來誤導伺服器針對使用者產生的回應傳遞給攻擊者。因為攻擊者所提出的要求產生兩個回應,第一個被解譯回應攻擊者的要求,而第二個被忘卻。當使用者透過相同 TCP 連線發出合法要求時,攻擊者的要求已處於等待狀態,並會被解讀成針對受害者要求的回應。接著,攻擊者會將第二個要求傳送到伺服器,且代理伺服器會將伺服器原本針對受害者要求產生的回應當作第二個要求的回應,如此一來,就會危及原本針對受害者的回應表頭或主體中的敏感資訊。

Cookie Manipulation:與跨網站偽造要求之類的攻擊結合時,攻擊者可能變更、新增至合法使用者的 Cookie,甚至覆寫合法使用者的 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. HTTP Cookie 包含的資料在未經驗證的情況下,便傳送給 Web 使用者。

與許多軟體的安全性弱點一樣,Cookie Manipulation 是達到目的的一種手段,而不是目的本身。 此弱點的基礎很簡單:攻擊者將惡意資料傳送至容易受到攻擊的應用程式,應用程式再將該資料包含於 HTTP Cookie 中。

Cookie Manipulation: 與 Cross-Site Request Forgery 之類的攻擊結合時,攻擊者可以變更、新增至合法的使用者 Cookie,甚至覆寫合法使用者的 Cookie。

作為 HTTP 回應標頭,Cookie Manipulation 攻擊還會引發其他類型的攻擊,例如:

HTTP Response Splitting:
最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。 為了成功進行 HTTP Response Splitting 攻擊,應用程式必須允許輸入在標頭中包含 CR (Carriage Return,亦由 %0d 或 \r 指定) 與 LF (Line Feed,亦由 %0a 或 \n 指定) 字元。 這些字元不僅讓攻擊者控制應用程式接下來要傳送之回應的剩餘標頭和正文,還允許它們全權建立其他回應。

現今許多先進的應用程式伺服器可防止將惡意字元插入 HTTP 標頭。 舉例來說,如果您嘗試使用禁用的字元設定標頭,最新版的 Apache Tomcat 會拋出 IllegalArgumentException。 如果應用程式伺服器可防止使用換行字元來設定標頭,則您的應用程式面對 HTTP Response Splitting 的攻擊,具有一定的防禦能力。 但是,僅篩選換行字元,應用程式可能仍對 Cookie Manipulation 或 Open Redirect 攻擊無招架能力,所以透過使用者輸入設定 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
在 Cookie 中包含未經驗證的資料會導致 HTTP 回應 Header manipulation,並引發 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect。
Explanation
Cookie Manipulation 弱點會在以下情況中出現:

1. 資料透過不可信賴的來源進入 Web 應用程式,通常是 HTTP 要求。

2. HTTP Cookie 包含的資料在未經驗證的情況下,便傳送給網頁使用者。

與許多軟體的安全性弱點一樣,Cookie manipulation 是達到目的的一種手段,而不是目的本身。此弱點的基礎很簡單:攻擊者傳送惡意資料至有弱點的應用程式,應用程式再將該資料包含於 HTTP Cookie 中。

Cookie Manipulation:與跨網站偽造要求之類的攻擊結合時,攻擊者可能變更、新增至合法使用者的 Cookie,甚至覆寫合法使用者的 Cookie。

由於 HTTP 回應表頭,Cookie manipulation 攻擊還會導致其他類型的攻擊,例如:

HTTP Response Splitting:
最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊,應用程式必須允許輸入在表頭中包含 CR (Carriage Return,亦由 %0d 或 \r 指定) 與 LF (Line Feed,亦由 %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-site scripting 和網頁劫持。

跨用戶塗改:攻擊者將能夠發出單一要求到易受攻擊的伺服器,讓伺服器建立兩個回應,其中第二個回應可能會被錯誤解譯成針對不同要求的回應,該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成:攻擊者誘導使用者自己傳遞惡意要求,或是在遠端情況下,攻擊者和使用者共用相同的 TCP 連線連接到伺服器 (例如共用的代理伺服器)。最理想的情況是,攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊,造成使用者對應用程式的安全性失去信心。最差的狀況是,攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式執行方式,但會要求使用者重新導向要求私人資訊,例如帳戶號碼和密碼,接著會將這些資訊回傳給攻擊者。

快取破壞:如果將惡意建構的回應快取到多個使用者使用的網頁快取或甚至單一使用者的瀏覽器快取,那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如代理伺服器中常見的網頁快取),那麼該快取的所有使用者將會繼續收到惡意內容,直到清除該快取項目為止。同樣的,如果回應貯存在單一使用者的瀏覽器中,那麼該使用者會繼續收到惡意的內容,直到清除快取項目為止,雖然只會影響本機瀏覽器實例的使用者。

Cross-Site Scripting:一旦攻擊者可以控制應用程式傳送的回應,他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式,此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼,且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言,最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持:除了利用易受攻擊的應用程式傳送惡意內容給使用者外,還可以利用具有相同本質的弱點,重新導向伺服器產生原本供使用者使用的敏感內容,轉而供攻擊者使用。藉由提交要求產生兩個回應,伺服器預期的回應和攻擊者產生的回應,攻擊者可能造成一個中間節點,例如一個共用的代理伺服器,來誤導伺服器針對使用者產生的回應傳遞給攻擊者。因為攻擊者所提出的要求產生兩個回應,第一個被解譯回應攻擊者的要求,而第二個被忘卻。當使用者透過相同 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.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 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
Including unvalidated data in an SMTP header can enable attackers to add arbitrary headers, such as CC or BCC that they can use to leak the mail contents to themselves or use the mail server as a spam bot.
Explanation
SMTP Header Manipulation 弱點會在以下情況中出現:

1. 資料透過不可信賴的來源進入應用程式,通常是 Web 應用程式中的 HTTP 要求。

2. 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
Including unvalidated data in an SMTP header can enable attackers to add arbitrary headers, such as CC or BCC that they can use to leak the mail contents to themselves or use the mail server as a spam bot.
Explanation
SMTP Header Manipulation 弱點會在以下情況中出現:

1. 資料透過不可信賴的來源進入應用程式,通常是 Web 應用程式中的 HTTP 要求。

2. 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 應用程式不能妥當清潔使用者輸入,惡意使用者可能危及應用程式邏輯,執行用戶端或伺服器端的攻擊。經由提交額外參數到網頁應用程式,且如果這些參數的名稱與現有參數相同,網頁應用程式可能以下列其中一種方式反應:

僅可使用第一個參數的資料
可使用最後一個參數的資料
可使用所有參數的資料,並將這些資料串連在一起


例如:
- 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 應用程式不能妥當清潔使用者輸入,惡意使用者可能危及應用程式邏輯,執行用戶端或伺服器端的攻擊。經由提交額外參數到網頁應用程式,且如果這些參數的名稱與現有參數相同,網頁應用程式可能以下列其中一種方式反應:

僅可使用第一個參數的資料
可使用最後一個參數的資料
可使用所有參數的資料,並將這些資料串連在一起


例如:
- 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">English<a>
連結 2: <a href="002">Spanish<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 應用程式不能妥當清潔使用者輸入,惡意使用者可能危及應用程式邏輯,執行用戶端或伺服器端的攻擊。經由提交額外參數到網頁應用程式,且如果這些參數的名稱與現有參數相同,網頁應用程式可能以下列其中一種方式反應:

僅可使用第一個參數的資料
可使用最後一個參數的資料
可使用所有參數的資料,並將這些資料串連在一起


例如:
- 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">Vote for Mr. White<a>
連結 2: <a href="vote.php?poll_id=4567&candidate=green">Vote for Mrs. Green<a>

程式設計師尚未考慮到攻擊者可能會提供 poll_id,例如「4567&candidate=green」,然後結果頁面中將含有下列注入的連結,因此 Mrs. Green 將一直由選取第一個參數的應用程式伺服器進行投票。
<a href="vote.php?poll_id=4567&candidate=green&candidate=white">Vote for Mr. White<a>
<a href="vote.php?poll_id=4567&candidate=green&candidate=green">Vote for Mrs. 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 應用程式不能妥當清潔使用者輸入,惡意使用者可能危及應用程式邏輯,執行用戶端或伺服器端的攻擊。經由提交額外參數到網頁應用程式,且如果這些參數的名稱與現有參數相同,網頁應用程式可能以下列其中一種方式反應:

僅可使用第一個參數的資料。
可使用最後一個參數的資料。
可使用所有參數的資料,並將這些資料串連在一起。


例如:
- 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
允許鍵盤延伸讀取使用者輸入的每個單一按鍵輸入。通常使用第三方鍵盤來簡化文字輸入或新增其他 Emoji,它們可能會記錄使用者輸入的內容,甚至將其傳送至遠端伺服器進行處理。還可能會散佈惡意鍵盤作為鍵盤記錄木馬程式,讀取使用者輸入的每個金鑰值,以竊取諸如憑證或信用卡號等敏感資料。
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
允許鍵盤延伸讀取使用者輸入的每個單一按鍵輸入。通常使用第三方鍵盤來簡化文字輸入或新增其他 Emoji,它們可能會記錄使用者輸入的內容,甚至將其傳送至遠端伺服器進行處理。還可能會散佈惡意鍵盤作為鍵盤記錄木馬程式,讀取使用者輸入的每個金鑰值,以竊取諸如憑證或信用卡號等敏感資料。
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
Abstract
識別的方法將資料寫入加密設定可能不足的檔案。
Explanation
資料保護 API 設計為允許應用程式宣告何時可以存取金鑰鏈中的項目以及檔案系統上儲存的檔案。這適用於大多數的檔案和資料庫 API,包括 NSFileManager、CoreData、NSData 和 SQLite。開發人員可以藉由將四種保護類別之一指定給某個指定資源,指示基礎檔案系統使用衍生自裝置 UID 和使用者密碼兩者的金鑰,或是使用完全以裝置 UID 為基礎的金鑰,對該資源進行加密 (以及何時自動對其進行解密)。

資料保護類別針對 NSFileManager 定義,而常數則應該被指派為與 NSFileManager 執行個體相關聯之 NSDictionary 中的 NSFileProtectionKey 金鑰值,以及可以透過使用 NSFileManager 函數 (包括 setAttributes:ofItemAtPath:error:attributesOfItemAtPath:error:createFileAtPath:contents:attributes:) 建立檔案或修改其資料保護類別。此外,相對應的資料保護常數會針對 NSData 物件定義為 NSDataWritingOptions,以便可以做為 options 引數傳遞到 NSData 函數 writeToURL:options:error:writeToFile:options:error:NSFileManagerNSData 的各種資料保護類別常數定義如下所示:

-NSFileProtectionComplete, NSDataWritingFileProtectionComplete:
資源會以加密格式儲存在磁碟,當裝置處於鎖定狀態或者正在開機時,將無法進行讀取或寫入。
可用於 iOS 4.0 及更新版本。
-NSFileProtectionCompleteUnlessOpen, NSDataWritingFileProtectionCompleteUnlessOpen:
資源會以加密格式儲存在磁碟。當裝置處於鎖定狀態時,可以建立資源,但是一旦關閉資源,就無法再次開啟,直到裝置解除鎖定。如果在解除鎖定時開啟了資源,則可以如常繼續存取資源,即使使用者鎖定了裝置也無妨。
可用於 iOS 5.0 及更新版本。
-NSFileProtectionCompleteUntilFirstUserAuthentication, NSDataWritingFileProtectionCompleteUntilFirstUserAuthentication:
資源會以加密格式儲存在磁碟,只有在裝置開機之後,才能存取資源。在使用者首次解除鎖定裝置之後,您的應用程式可以存取資源,即使使用者之後鎖定了裝置,還是可以繼續存取。
可用於 iOS 5.0 及更新版本。
-NSFileProtectionNone, NSDataWritingFileProtectionNone:
資源沒有與其相關聯的特殊保護。任何時候都可以讀取或寫入資源。
可用於 iOS 4.0 及更新版本。

所以,雖然以 NSFileProtectionCompleteUnlessOpenNSFileProtectionCompleteUntilFirstUserAuthentication 標記檔案將會使用衍生自使用者密碼和裝置 UID 的金鑰為其加密,但是在某些情況下資料還是保持可存取的狀態。因此,使用 NSFileProtectionCompleteUnlessOpenNSFileProtectionCompleteUntilFirstUserAuthentication 時應該仔細進行檢閱,以確定是否保證提供進一步的 NSFileProtectionComplete 保護。

範例 1:在以下範例中,只有在使用者開啟裝置並首次提供密碼後 (直到下次重新開機),所指定的檔案才受到保護:


...
filepath = [self.GetDocumentDirectory stringByAppendingPathComponent:self.setFilename];
...
NSDictionary *protection = [NSDictionary dictionaryWithObject:NSFileProtectionCompleteUntilFirstUserAuthentication forKey:NSFileProtectionKey];
...
[[NSFileManager defaultManager] setAttributes:protection ofItemAtPath:filepath error:nil];
...
BOOL ok = [testToWrite writeToFile:filepath atomically:YES encoding:NSUnicodeStringEncoding error:&err];
...
範例 2:在以下範例中,只有在使用者開啟裝置並首次提供密碼後 (直到下次重新開機),所指定的資料才受到保護:


...
filepath = [self.GetDocumentDirectory stringByAppendingPathComponent:self.setFilename];
...
NSData *textData = [textToWrite dataUsingEncoding:NSUnicodeStingEncoding];
...
BOOL ok = [textData writeToFile:filepath options:NSDataWritingFileProtectionCompleteUntilFirstUserAuthentication error:&err];
...
References
[1] iOS Security Guide Apple
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[7] Standards Mapping - CIS Kubernetes Benchmark complete
[8] Standards Mapping - Common Weakness Enumeration CWE ID 311
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001350, CCI-002475
[10] Standards Mapping - FIPS200 MP
[11] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[14] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[15] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[19] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3)
[21] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[22] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[23] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[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 7.1 - Use of Cryptography
[31] 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
[32] 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
[33] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 311
[34] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 311
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[56] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.dataflow.objc.insecure_storage_insufficient_data_protection
Abstract
識別的方法將資料寫入加密設定可能不足的檔案。
Explanation
資料保護 API 設計為允許應用程式宣告何時可以存取金鑰鏈中的項目以及檔案系統上儲存的檔案。這適用於大多數的檔案和資料庫 API,包括 NSFileManager、CoreData、NSData 和 SQLite。開發人員可以藉由將四種保護類別之一指定給某個指定資源,指示基礎檔案系統使用衍生自裝置 UID 和使用者密碼兩者的金鑰,或是使用完全以裝置 UID 為基礎的金鑰,對該資源進行加密 (以及何時自動對其進行解密)。

資料保護類別定義於 NSFileManager,而常數則應該被指派為與 NSFileManager 實例相關聯之 Dictionary 中的 NSFileProtectionKey 金鑰值,以及可以透過使用 NSFileManager 函數 (包括 setAttributes(_:ofItemAtPath:)attributesOfItemAtPath(_:)createFileAtPath(_:contents:attributes:)) 建立檔案或修改其資料保護類別。此外,相對應的資料保護常數會針對 NSDataWritingOptions 列舉中的 NSData 物件定義,以便可以做為 options 引數傳遞到 NSData 函數
writeToFile(_:options:)
NSFileManagerNSData 的各種資料保護類別常數定義如下所示:

-NSFileProtectionComplete, NSDataWritingOptions.DataWritingFileProtectionComplete:
資源會以加密格式儲存在磁碟,當裝置處於鎖定狀態或者正在開機時,將無法進行讀取或寫入。
可用於 iOS 4.0 及更新版本。
-NSFileProtectionCompleteUnlessOpen, NSDataWritingOptions.DataWritingFileProtectionCompleteUnlessOpen:
資源會以加密格式儲存在磁碟。當裝置處於鎖定狀態時,可以建立資源,但是一旦關閉資源,就無法再次開啟,直到裝置解除鎖定。如果在解除鎖定時開啟了資源,則可以如常繼續存取資源,即使使用者鎖定了裝置也無妨。
可用於 iOS 5.0 及更新版本。
-NSFileProtectionCompleteUntilFirstUserAuthentication, NSDataWritingOptions.DataWritingFileProtectionCompleteUntilFirstUserAuthentication:
資源會以加密格式儲存在磁碟,只有在裝置開機之後,才能存取資源。在使用者首次解除鎖定裝置之後,您的應用程式可以存取資源,即使使用者之後鎖定了裝置,還是可以繼續存取。
可用於 iOS 5.0 及更新版本。
-NSFileProtectionNone, NSDataWritingOptions.DataWritingFileProtectionNone:
資源沒有與其相關聯的特殊保護。任何時候都可以讀取或寫入資源。
可用於 iOS 4.0 及更新版本。

所以,雖然以 NSFileProtectionCompleteUnlessOpenNSFileProtectionCompleteUntilFirstUserAuthentication 標記檔案將會使用衍生自使用者密碼和裝置 UID 的金鑰為其加密,但是在某些情況下資料還是保持可存取的狀態。因此,使用 NSFileProtectionCompleteUnlessOpenNSFileProtectionCompleteUntilFirstUserAuthentication 時應該仔細進行檢閱,以確定是否保證提供進一步的 NSFileProtectionComplete 保護。

範例 1:在以下範例中,只有在使用者開啟裝置並首次提供密碼後 (直到下次重新開機),所指定的檔案才受到保護:


...
let documentsPath = NSURL(fileURLWithPath: NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true)[0])
let filename = "\(documentsPath)/tmp_activeTrans.txt"
let protection = [NSFileProtectionKey: NSFileProtectionCompleteUntilFirstUserAuthentication]
do {
try NSFileManager.defaultManager().setAttributes(protection, ofItemAtPath: filename)
} catch let error as NSError {
NSLog("Unable to change attributes: \(error.debugDescription)")
}
...
BOOL ok = textToWrite.writeToFile(filename, atomically:true)
...
範例 2:在以下範例中,只有在使用者開啟裝置並首次提供密碼後 (直到下次重新開機),所指定的資料才受到保護:


...
let documentsPath = NSURL(fileURLWithPath: NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true)[0])
let filename = "\(documentsPath)/tmp_activeTrans.txt"
...
BOOL ok = textData.writeToFile(filepath, options: .DataWritingFileProtectionCompleteUntilFirstUserAuthentication);
...
References
[1] iOS Security Guide Apple
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[7] Standards Mapping - CIS Kubernetes Benchmark complete
[8] Standards Mapping - Common Weakness Enumeration CWE ID 311
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001350, CCI-002475
[10] Standards Mapping - FIPS200 MP
[11] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[14] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[15] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[19] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3)
[21] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[22] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[23] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[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 7.1 - Use of Cryptography
[31] 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
[32] 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
[33] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 311
[34] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 311
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[56] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.swift.insecure_storage_insufficient_data_protection
Abstract
所識別的方法將資料儲存於加密設定可能不足的金鑰鏈中。
Explanation
金鑰鏈可存取性常數設計為允許應用程式藉此宣告何時可以存取金鑰鏈中的項目。藉由將其中一種可存取性常數指定給指定金鑰鏈項目,開發人員可以指示基礎檔案系統使用衍生自裝置 UID 和使用者密碼的金鑰,或是使用完全以裝置 UID 為基礎的金鑰,對該項目進行加密 (以及何時自動對其進行解密)。

這意味著金鑰鏈可存取性常數應指定為金鑰鏈屬性字典中 kSecAttrAccessible 金鑰的值。各個金鑰鏈可存取性常數的定義如下所示:

-kSecAttrAccessibleAfterFirstUnlock:
重新啟動後,無法存取金鑰鏈項目中的資料,直到使用者進行一次裝置解除鎖定。
首次解除鎖定後,資料會保持可存取狀態,直到下次重新啟動。對於背景應用程式需要存取的項目,建議這樣做。使用加密的備份時,具有此屬性的項目會移轉至新裝置。
可用於 iOS 4.0 及更新版本。

-kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:
重新啟動後,無法存取金鑰鏈項目中的資料,直到使用者進行一次裝置解除鎖定。
首次解除鎖定後,資料會保持可存取狀態,直到下次重新啟動。對於背景應用程式需要存取的項目,建議這樣做。具有此屬性的項目不會移轉至新裝置。因此,從不同裝置的備份還原後,不會顯示這些項目。
可用於 iOS 4.0 及更新版本。

-kSecAttrAccessibleAlways:
不論裝置是否已鎖定,始終可以存取金鑰鏈項目中的資料。
如果使用應用程式,則不建議這樣做。使用加密的備份時,具有此屬性的項目會移轉至新裝置。
可用於 iOS 4.0 及更新版本。

-kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:
金鑰鏈中的資料僅在裝置解除鎖定時才可存取。僅當裝置設定有密碼時才可使用。
對於只需在應用程式於前景執行時可供存取的項目,建議這樣做。具有此屬性的項目絕不會移轉至新裝置。備份還原至新裝置後,這些項目會遺失。對於未設定密碼的裝置,沒有任何項目可儲存在此類別中。停用裝置密碼會導致此類別中的所有項目遭到刪除。
可用於 iOS 8.0 及更新版本。

-kSecAttrAccessibleAlwaysThisDeviceOnly:
不論裝置是否已鎖定,始終可以存取金鑰鏈項目中的資料。
如果使用應用程式,則不建議這樣做。具有此屬性的項目不會移轉至新裝置。因此,從不同裝置的備份還原後,不會顯示這些項目。
可用於 iOS 4.0 及更新版本。

-kSecAttrAccessibleWhenUnlocked:
金鑰鏈中的資料僅當使用者解除鎖定裝置時才可存取。
對於只需在應用程式於前景執行時可供存取的項目,建議這樣做。使用加密的備份時,具有此屬性的項目會移轉至新裝置。
這是在未明確設定可存取性常數時新增的金鑰鏈項目的預設值。
可用於 iOS 4.0 及更新版本。

-kSecAttrAccessibleWhenUnlockedThisDeviceOnly:
金鑰鏈中的資料僅當使用者解除鎖定裝置時才可存取。
對於只需在應用程式於前景執行時可供存取的項目,建議這樣做。具有此屬性的項目不會移轉至新裝置。因此,從不同裝置的備份還原後,不會顯示這些項目。
可用於 iOS 4.0 及更新版本。

所以,雖然以 kSecAttrAccessibleAfterFirstUnlock 標記金鑰鏈項目將會使用衍生自使用者密碼和裝置 UID 的金鑰進行加密,但是在某些情況下資料仍然保持可存取狀態。因此,使用 kSecAttrAccessibleAfterFirstUnlock 時應該仔細進行檢閱,確定是否保證提供進一步的保護。

範例 1:在以下範例中,只有在使用者開啟裝置電源並首次提供密碼後 (直到下次重新開機),所指定的金鑰鏈項目才受到保護:


...
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)kSecAttrAccessibleAfterFirstUnlock forKey:(__bridge id) kSecAttrAccessible];

OSStatus error = SecItemAdd((__bridge CFDictionaryRef)dict, NULL);
...
References
[1] iOS Security Guide Apple: October 2014
[2] Keychain Services Apple
[3] Keychain Item Accessibility Constants Apple
[4] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[5] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[6] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[7] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[8] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[10] Standards Mapping - CIS Kubernetes Benchmark complete
[11] Standards Mapping - Common Weakness Enumeration CWE ID 311, CWE ID 312, CWE ID 313, CWE ID 522
[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [18] CWE ID 522
[14] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [21] CWE ID 522
[15] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[16] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[17] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001350, CCI-002475
[18] Standards Mapping - FIPS200 MP
[19] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[20] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[21] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[22] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[23] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[24] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[25] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[26] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[27] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[28] 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)
[29] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[30] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[31] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[32] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.1 - Use of Cryptography
[39] 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
[40] 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
[41] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 311
[42] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 311
[43] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[63] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[64] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.dataflow.objc.insecure_storage_insufficient_keychain_protection
Abstract
所識別的方法將資料儲存於加密設定可能不足的金鑰鏈中。
Explanation
金鑰鏈可存取性常數設計為允許應用程式藉此宣告何時可以存取金鑰鏈中的項目。藉由將其中一種可存取性常數指定給指定金鑰鏈項目,開發人員可以指示基礎檔案系統使用衍生自裝置 UID 和使用者密碼的金鑰,或是使用完全以裝置 UID 為基礎的金鑰,對該項目進行加密 (以及何時自動對其進行解密)。

這意味著金鑰鏈可存取性常數應指定為金鑰鏈屬性字典中 kSecAttrAccessible 金鑰的值。各個金鑰鏈可存取性常數的定義如下所示:

-kSecAttrAccessibleAfterFirstUnlock:
重新啟動後,無法存取金鑰鏈項目中的資料,直到使用者進行一次裝置解除鎖定。
首次解除鎖定後,資料會保持可存取狀態,直到下次重新啟動。對於背景應用程式需要存取的項目,建議這樣做。使用加密的備份時,具有此屬性的項目會移轉至新裝置。
可用於 iOS 4.0 及更新版本。

-kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:
重新啟動後,無法存取金鑰鏈項目中的資料,直到使用者進行一次裝置解除鎖定。
首次解除鎖定後,資料會保持可存取狀態,直到下次重新啟動。對於背景應用程式需要存取的項目,建議這樣做。具有此屬性的項目不會移轉至新裝置。因此,從不同裝置的備份還原後,不會顯示這些項目。
可用於 iOS 4.0 及更新版本。

-kSecAttrAccessibleAlways:
不論裝置是否已鎖定,始終可以存取金鑰鏈項目中的資料。
如果使用應用程式,則不建議這樣做。使用加密的備份時,具有此屬性的項目會移轉至新裝置。
可用於 iOS 4.0 及更新版本。

-kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:
金鑰鏈中的資料僅在裝置解除鎖定時才可存取。僅當裝置設定有密碼時才可使用。
對於只需在應用程式於前景執行時可供存取的項目,建議這樣做。具有此屬性的項目絕不會移轉至新裝置。備份還原至新裝置後,這些項目會遺失。對於未設定密碼的裝置,沒有任何項目可儲存在此類別中。停用裝置密碼會導致此類別中的所有項目遭到刪除。
可用於 iOS 8.0 及更新版本。

-kSecAttrAccessibleAlwaysThisDeviceOnly:
不論裝置是否已鎖定,始終可以存取金鑰鏈項目中的資料。
如果使用應用程式,則不建議這樣做。具有此屬性的項目不會移轉至新裝置。因此,從不同裝置的備份還原後,不會顯示這些項目。
可用於 iOS 4.0 及更新版本。

-kSecAttrAccessibleWhenUnlocked:
金鑰鏈中的資料僅當使用者解除鎖定裝置時才可存取。
對於只需在應用程式於前景執行時可供存取的項目,建議這樣做。使用加密的備份時,具有此屬性的項目會移轉至新裝置。
這是在未明確設定可存取性常數時新增的金鑰鏈項目的預設值。
可用於 iOS 4.0 及更新版本。

-kSecAttrAccessibleWhenUnlockedThisDeviceOnly:
金鑰鏈中的資料僅當使用者解除鎖定裝置時才可存取。
對於只需在應用程式於前景執行時可供存取的項目,建議這樣做。具有此屬性的項目不會移轉至新裝置。因此,從不同裝置的備份還原後,不會顯示這些項目。
可用於 iOS 4.0 及更新版本。

所以,雖然以 kSecAttrAccessibleAfterFirstUnlock 標記金鑰鏈項目將會使用衍生自使用者密碼和裝置 UID 的金鑰進行加密,但是在某些情況下資料仍然保持可存取狀態。因此,使用 kSecAttrAccessibleAfterFirstUnlock 時應該仔細進行檢閱,確定是否保證提供進一步的保護。

範例 1:在以下範例中,只有在使用者開啟裝置電源並首次提供密碼後 (直到下次重新開機),所指定的金鑰鏈項目才受到保護:


...
// 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] = kSecAttrAccessibleAfterFirstUnlock

SecItemAdd(query as CFDictionary, nil)
...
References
[1] iOS Security Guide Apple: October 2014
[2] Keychain Services Apple
[3] Keychain Item Accessibility Constants Apple
[4] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[5] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[6] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[7] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[8] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[10] Standards Mapping - CIS Kubernetes Benchmark complete
[11] Standards Mapping - Common Weakness Enumeration CWE ID 311, CWE ID 312, CWE ID 313, CWE ID 522
[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [18] CWE ID 522
[14] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [21] CWE ID 522
[15] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[16] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[17] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001350, CCI-002475
[18] Standards Mapping - FIPS200 MP
[19] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[20] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[21] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[22] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[23] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[24] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[25] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[26] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[27] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[28] 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)
[29] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[30] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[31] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[32] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.1 - Use of Cryptography
[39] 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
[40] 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
[41] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 311
[42] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 311
[43] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[63] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[64] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.dataflow.swift.insecure_storage_insufficient_keychain_protection
Abstract
識別的方法將資料寫入加密設定不足的檔案。
Explanation
資料保護 API 設計為允許應用程式宣告何時可以存取金鑰鏈中的項目以及檔案系統上儲存的檔案。這適用於大多數的檔案和資料庫 API,包括 NSFileManager、CoreData、NSData 和 SQLite。開發人員可以藉由將四種保護類別之一指定給某個指定資源,指示基礎檔案系統使用衍生自裝置 UID 和使用者密碼兩者的金鑰,或是使用完全以裝置 UID 為基礎的金鑰,對該資源進行加密 (以及何時自動對其進行解密)。

資料保護類別針對 NSFileManager 定義,而常數則應該被指派為與 NSFileManager 執行個體相關聯之 NSDictionary 中的 NSFileProtectionKey 金鑰值,以及可以透過使用 NSFileManager 函數 (包括 setAttributes:ofItemAtPath:error:attributesOfItemAtPath:error:createFileAtPath:contents:attributes:) 建立檔案或修改其資料保護類別。此外,相對應的資料保護常數會針對 NSData 物件定義為 NSDataWritingOptions,以便可以做為 options 引數傳遞到 NSData 函數 writeToURL:options:error:writeToFile:options:error:NSFileManagerNSData 的各種資料保護類別常數定義如下所示:

-NSFileProtectionComplete, NSDataWritingFileProtectionComplete:
資源會以加密格式儲存在磁碟,當裝置處於鎖定狀態或者正在開機時,將無法進行讀取或寫入。
可用於 iOS 4.0 及更新版本。
-NSFileProtectionCompleteUnlessOpen, NSDataWritingFileProtectionCompleteUnlessOpen:
資源會以加密格式儲存在磁碟。當裝置處於鎖定狀態時,可以建立資源,但是一旦關閉資源,就無法再次開啟,直到裝置解除鎖定。如果在解除鎖定時開啟了資源,則可以如常繼續存取資源,即使使用者鎖定了裝置也無妨。
可用於 iOS 5.0 及更新版本。
-NSFileProtectionCompleteUntilFirstUserAuthentication, NSDataWritingFileProtectionCompleteUntilFirstUserAuthentication:
資源會以加密格式儲存在磁碟,只有在裝置開機之後,才能存取資源。在使用者首次解除鎖定裝置之後,您的應用程式可以存取資源,即使使用者之後鎖定了裝置,還是可以繼續存取。
可用於 iOS 5.0 及更新版本。
-NSFileProtectionNone, NSDataWritingFileProtectionNone:
資源沒有與其相關聯的特殊保護。任何時候都可以讀取或寫入資源。
可用於 iOS 4.0 及更新版本。

即使 iOS 裝置上的所有檔案 (包括未明確指派有資料保護類別的檔案) 都以加密格式儲存,指定 NSFileProtectionNone 也會導致使用完全以裝置 UID 為基礎的衍生金鑰進行加密。如此一來,在裝置開機的任何時候 (包括以密碼鎖定時或正在開機時),此類檔案都會處於可存取的狀態。因此,使用 NSFileProtectionNone 時應該仔細進行檢閱,以確定是否保證使用較嚴格的資料保護類別提供進一步的保護。

範例 1:在以下範例中,指定的檔案未受保護 (在裝置開機的任何時候均可存取):


...
filepath = [self.GetDocumentDirectory stringByAppendingPathComponent:self.setFilename];
...
NSDictionary *protection = [NSDictionary dictionaryWithObject:NSFileProtectionNone forKey:NSFileProtectionKey];
...
[[NSFileManager defaultManager] setAttributes:protection ofItemAtPath:filepath error:nil];
...
BOOL ok = [testToWrite writeToFile:filepath atomically:YES encoding:NSUnicodeStringEncoding error:&err];
...
範例 2:在以下範例中,指定的資料未受保護 (在裝置開機的任何時候均可存取):


...
filepath = [self.GetDocumentDirectory stringByAppendingPathComponent:self.setFilename];
...
NSData *textData = [textToWrite dataUsingEncoding:NSUnicodeStingEncoding];
...
BOOL ok = [textData writeToFile:filepath options:NSDataWritingFileProtectionNone error:&err];
...
References
[1] iOS Security Guide Apple
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[7] Standards Mapping - CIS Kubernetes Benchmark complete
[8] Standards Mapping - Common Weakness Enumeration CWE ID 311
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001350, CCI-002475
[10] Standards Mapping - FIPS200 MP
[11] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[14] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[15] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[19] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3)
[21] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[22] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[23] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[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 7.1 - Use of Cryptography
[31] 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
[32] 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
[33] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 311
[34] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 311
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[56] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.dataflow.objc.insecure_storage_lacking_data_protection
Abstract
識別的方法將資料寫入加密設定不足的檔案。
Explanation
資料保護 API 設計為允許應用程式宣告何時可以存取金鑰鏈中的項目以及檔案系統上儲存的檔案。這適用於大多數的檔案和資料庫 API,包括 NSFileManager、CoreData、NSData 和 SQLite。開發人員可以藉由將四種保護類別之一指定給某個指定資源,指示基礎檔案系統使用衍生自裝置 UID 和使用者密碼兩者的金鑰,或是使用完全以裝置 UID 為基礎的金鑰,對該資源進行加密 (以及何時自動對其進行解密)。

資料保護類別定義於 NSFileManager,而常數則應該被指派為與 NSFileManager 實例相關聯之 Dictionary 中的 NSFileProtectionKey 金鑰值。可以透過使用 NSFileManager 函數 (包括 setAttributes(_:ofItemAtPath:)attributesOfItemAtPath(_:)createFileAtPath(_:contents:attributes:)) 建立檔案或修改其資料保護類別。此外,相對應的資料保護常數會針對 NSDataWritingOptions 列舉中的 NSData 物件定義,以便可以做為 options 引數傳遞到 NSData 函數,例如
writeToFile(_:options:)
NSFileManagerNSData 的各種資料保護類別常數定義如下所示:

-NSFileProtectionComplete, NSDataWritingOptions.DataWritingFileProtectionComplete:
資源會以加密格式儲存在磁碟,當裝置處於鎖定狀態或者正在開機時,將無法進行讀取或寫入。
可用於 iOS 4.0 及更新版本。
-NSFileProtectionCompleteUnlessOpen, NSDataWritingOptions.DataWritingFileProtectionCompleteUnlessOpen:
資源會以加密格式儲存在磁碟。當裝置處於鎖定狀態時,可以建立資源,但是一旦關閉資源,就無法再次開啟,直到裝置解除鎖定。如果在解除鎖定時開啟了資源,則可以如常繼續存取資源,即使使用者鎖定了裝置也無妨。
可用於 iOS 5.0 及更新版本。
-NSFileProtectionCompleteUntilFirstUserAuthentication, NSDataWritingOptions.DataWritingFileProtectionCompleteUntilFirstUserAuthentication:
資源會以加密格式儲存在磁碟,只有在裝置開機之後,才能存取資源。在使用者首次解除鎖定裝置之後,您的應用程式可以存取資源,即使使用者之後鎖定了裝置,還是可以繼續存取。
可用於 iOS 5.0 及更新版本。
-NSFileProtectionNone, NSDataWritingOptions.DataWritingFileProtectionNone:
資源沒有與其相關聯的特殊保護。任何時候都可以讀取或寫入資源。
可用於 iOS 4.0 及更新版本。

即使 iOS 裝置上的所有檔案 (包括未明確指派有資料保護類別的檔案) 都以加密格式儲存,指定 NSFileProtectionNone 也會導致使用完全以裝置 UID 為基礎的衍生金鑰進行加密。如此一來,在裝置開機的任何時候 (包括以密碼鎖定時或正在開機時),此類檔案都會處於可存取的狀態。因此,使用 NSFileProtectionNone 時應該仔細進行檢閱,以確定是否保證使用較嚴格的資料保護類別提供進一步的保護。

範例 1:在以下範例中,指定的檔案未受保護 (只要裝置開機便可存取):


...
let documentsPath = NSURL(fileURLWithPath: NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true)[0])
let filename = "\(documentsPath)/tmp_activeTrans.txt"
let protection = [NSFileProtectionKey: NSFileProtectionNone]
do {
try NSFileManager.defaultManager().setAttributes(protection, ofItemAtPath: filename)
} catch let error as NSError {
NSLog("Unable to change attributes: \(error.debugDescription)")
}
...
BOOL ok = textToWrite.writeToFile(filename, atomically:true)
...
範例 2:在以下範例中,指定的資料未受保護 (只要裝置開機便可存取):


...
let documentsPath = NSURL(fileURLWithPath: NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true)[0])
let filename = "\(documentsPath)/tmp_activeTrans.txt"
...
BOOL ok = textData.writeToFile(filepath, options: .DataWritingFileProtectionNone);
...
References
[1] iOS Security Guide Apple
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[7] Standards Mapping - CIS Kubernetes Benchmark complete
[8] Standards Mapping - Common Weakness Enumeration CWE ID 311
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001350, CCI-002475
[10] Standards Mapping - FIPS200 MP
[11] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[14] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[15] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[19] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3)
[21] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[22] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[23] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[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 7.1 - Use of Cryptography
[31] 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
[32] 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
[33] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 311
[34] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 311
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[56] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.swift.insecure_storage_lacking_data_protection