207 找到的項目
弱點
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 - Common Weakness Enumeration CWE ID 264, CWE ID 732
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[6] Standards Mapping - FIPS200 AC
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[10] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[11] 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)
[12] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[13] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[15] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[26] 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
[27] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[28] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[29] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] 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 - Common Weakness Enumeration CWE ID 264, CWE ID 732
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[7] Standards Mapping - FIPS200 AC
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[11] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[12] 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)
[13] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[14] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[16] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[28] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[29] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[30] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[31] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] 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 - Common Weakness Enumeration CWE ID 264, CWE ID 732
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[7] Standards Mapping - FIPS200 AC
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[11] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[12] 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)
[13] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[14] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[16] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[28] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[29] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[30] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[31] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] 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 - Common Weakness Enumeration CWE ID 264, CWE ID 732
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[6] Standards Mapping - FIPS200 AC
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[10] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[11] 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)
[12] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[13] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[15] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[26] 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
[27] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[28] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[29] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] 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 - Common Weakness Enumeration CWE ID 264, CWE ID 732
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[7] Standards Mapping - FIPS200 AC
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[11] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[12] 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)
[13] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[14] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[16] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[28] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[29] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[30] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[31] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.ruby.file_permission_manipulation
Abstract
程式會定義過度許可的跨網域策略。
Explanation
依預設,Flash 應用程式需遵守相同來源策略 (Same Origin Policy),它可以確保只有在兩個 SWF 應用程式都來自相同網域時,才可以存取彼此的資料。Adobe Flash 允許開發人員在程式上或透過 crossdomain.xml 組態設定檔案的適當設定來修改策略。但是,變更設定時應特別小心,因為過度允許的跨網域策略會允許惡意應用程式以不適當的方式與受害者應用程式通訊,導致欺騙、資料遭竊取、傳遞和其他攻擊。

範例 1:以下內容是使用萬用字元在程式上指定允許應用程式與哪些網域通訊的範例。


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


使用 * 做為給 allowDomain() 的引數,表示應用程式的資料可以讓其他來自任何網域的 SWF 應用程式存取。
References
[1] Peleus Uhley Creating more secure SWF web applications
[2] Matt Wood and Prajakta Jagdale Auditing Adobe Flash through Static Analysis
[3] Standards Mapping - Common Weakness Enumeration CWE ID 942
[4] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[6] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.6 HTTP Security Headers Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[11] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[12] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[13] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[22] 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
[23] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.semantic.actionscript.flash_misconfiguration_overly_permissive_cross_domain_policy
Abstract
程式定義過度允許的自訂表頭原則。
Explanation
依預設,Flash 應用程式需遵守相同來源策略 (Same Origin Policy),它可以確保只有在兩個 SWF 應用程式都來自相同網域時,才可以存取彼此的資料。Adobe Flash 允許開發人員在程式上或透過 crossdomain.xml 組態設定檔案的適當設定來修改策略。從 Flash Player 9,0,124,0 開始,Adobe 也引進了定義 Flash Player 可以在網域間傳送哪些自訂表頭的功能。但是,定義這些設定時應特別小心,因為將過度允許的自訂表頭策略和過度允許的跨網域策略一起套用時,會允許惡意應用程式將其選擇的表頭傳送到目標應用程式,可能會導致多種攻擊,或在不知道如何處理所接收之表頭的應用程式執行中造成錯誤。

範例 1:以下配置顯示了使用萬用字元指定 Flash Player 可以在網域間傳送哪些標頭。


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


使用 * 做為 headers 屬性的值,表示任何表頭都會在網域間傳送。
References
[1] Peleus Uhley Creating more secure SWF web applications
[2] Matt Wood and Prajakta Jagdale Auditing Adobe Flash through Static Analysis
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[7] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[8] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[9] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[10] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[19] 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
[20] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.actionscript.flash_misconfiguration_overly_permissive_custom_headers_policy
Abstract
程式使用未經驗證的使用者輸入來略過預期的跨網域策略限制。
Explanation
依預設,Flash 應用程式需遵守相同來源策略 (Same Origin Policy),它可以確保只有在兩個 SWF 應用程式都來自相同網域時,才可以存取彼此的資料。Adobe Flash 允許開發人員在程式上或透過 crossdomain.xml 組態設定檔案的適當設定來修改策略。但是,決定誰可以影響設定時應特別小心,因為過度允許的跨網域策略會允許惡意應用程式以不適當的方式與受害者應用程式通訊,導致欺騙、資料遭竊取、傳遞和其他攻擊。Policy restrictions bypass 弱點會在以下情況中出現:

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

2. 資料用來載入或修改跨網域策略設定。
範例 1:以下程式碼對載入的 SWF 檔案使用其中一個參數的值,做為載入跨網域策略檔案的來源 URL。


...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var url:String = String(params["url"]);
flash.system.Security.loadPolicyFile(url);
...
範例 2:以下程式碼對載入的 SWF 檔案使用其中一個參數的值,以定義可信任網域的清單。


...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var domain:String = String(params["domain"]);
flash.system.Security.allowDomain(domain);
...
References
[1] Peleus Uhley Creating more secure SWF web applications
[2] Matt Wood and Prajakta Jagdale Auditing Adobe Flash through Static Analysis
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[4] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[7] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[8] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[9] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[16] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[18] 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
[19] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.actionscript.flash_misconfiguration_policy_restrictions_bypass
Abstract
程式允許 HTTP 和 HTTPS SWF 應用程式進行通訊。
Explanation
從 Flash Player 7 開始,透過 HTTP 載入的 SWF 應用程式不允許存取預設透過 HTTPS 載入的 SWF 應用程式。Adobe Flash 允許開發人員在程式上或透過 crossdomain.xml 組態設定檔案的適當設定來修改此限制。但是,定義這些設定時應特別小心,因為 HTTP 載入的 SWF 應用程式容易遭到 man-in-the-middle 攻擊,因此不應該受信賴。

範例:以下程式碼會呼叫 allowInsecureDomain(),它會關閉以下限制:防止 HTTP 載入的 SWF 應用程式存取 HTTPS 載入之 SWF 應用程式的資料。


flash.system.Security.allowInsecureDomain("*");
References
[1] Peleus Uhley Creating more secure SWF web applications
[2] Matt Wood and Prajakta Jagdale Auditing Adobe Flash through Static Analysis
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[4] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[7] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[8] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[9] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[10] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.4, Requirement 6.5.8
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.4, Requirement 6.5.8
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.4, Requirement 6.5.8
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.4, Requirement 6.5.8
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control, Control Objective 6.2 - Sensitive Data Protection
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control, Control Objective 6.2 - Sensitive Data Protection
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective 6.2 - Sensitive Data Protection, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.4.1 - Web Software Communications
[20] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 862
[21] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.semantic.actionscript.flash_misconfiguration_unauthorized_data_access
Abstract
程式讓攻擊者可以控制用戶端應用程式執行所在的 Hadoop 叢集的核心元件。
Explanation
在以下情況會發生 Hadoop 叢集控制錯誤:

- 資料從一個不可信賴的來源進入程式。

- 資料被 Hadoop 叢集的核心元件例如 NameNodeDataNodeJobTraker 用來更改叢集的狀態。

Hadoop 叢集是不友善的環境。當未正確設定安全配置,無法防護未獲授權而存取叢集節點時,攻擊就有可能控制基礎架構。這可能造成 Hadoop 叢集提供的資料被竄改。

範例 1: 下列程式碼顯示一般用戶端應用程式中的 Job 提交,從 Hadoop 叢集主機器的指令行取其輸入資料:


public static void run(String args[]) throws IOException {

String path = "/path/to/a/file";
DFSclient client = new DFSClient(arg[1], new Configuration());
ClientProtocol nNode = client.getNameNode();

/* This sets the ownership of a file pointed by the path to a user identified
* by command line arguments.
*/
nNode.setOwner(path, args[2], args[3]);
...
}
References
[1] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[2] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[3] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[4] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[5] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[6] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[12] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[13] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[14] 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
[15] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[16] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[17] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[18] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[19] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[20] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[29] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.hadoop_cluster_manipulation
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 - Common Weakness Enumeration CWE ID 494, CWE ID 829
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[6] 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)
[7] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[8] Standards Mapping - OWASP Mobile 2024 M7 Insufficient Binary Protections
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-PLATFORM-2
[10] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 094
[11] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[12] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[25] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Process Validation (WASC-40)
[26] 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 - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 - Common Weakness Enumeration CWE ID 113
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[8] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[10] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[11] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2010 A1 Injection
[13] Standards Mapping - OWASP Top 10 2013 A1 Injection
[14] Standards Mapping - OWASP Top 10 2017 A1 Injection
[15] Standards Mapping - OWASP Top 10 2021 A03 Injection
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[25] 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
[26] 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
[27] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 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 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[49] 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 - Common Weakness Enumeration CWE ID 113
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[4] Standards Mapping - FIPS200 SI
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[8] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[9] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[11] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[12] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2010 A1 Injection
[14] Standards Mapping - OWASP Top 10 2013 A1 Injection
[15] Standards Mapping - OWASP Top 10 2017 A1 Injection
[16] Standards Mapping - OWASP Top 10 2021 A03 Injection
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] 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
[27] 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
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[50] 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 - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 - Common Weakness Enumeration CWE ID 113
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[8] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[10] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[11] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2010 A1 Injection
[13] Standards Mapping - OWASP Top 10 2013 A1 Injection
[14] Standards Mapping - OWASP Top 10 2017 A1 Injection
[15] Standards Mapping - OWASP Top 10 2021 A03 Injection
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[25] 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
[26] 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
[27] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 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 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[49] 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 - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 - Common Weakness Enumeration CWE ID 113
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[8] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[10] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[11] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2010 A1 Injection
[13] Standards Mapping - OWASP Top 10 2013 A1 Injection
[14] Standards Mapping - OWASP Top 10 2017 A1 Injection
[15] Standards Mapping - OWASP Top 10 2021 A03 Injection
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[25] 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
[26] 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
[27] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 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 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[49] 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 - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 - Common Weakness Enumeration CWE ID 93
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[8] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[10] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[11] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2010 A1 Injection
[13] Standards Mapping - OWASP Top 10 2013 A1 Injection
[14] Standards Mapping - OWASP Top 10 2017 A1 Injection
[15] Standards Mapping - OWASP Top 10 2021 A03 Injection
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[25] 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
[26] 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
[27] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 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 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[48] 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 - Common Weakness Enumeration CWE ID 93
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] 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 - Common Weakness Enumeration CWE ID 93
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] 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 - Common Weakness Enumeration CWE ID 93
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.python.header_manipulation_smtp
Abstract
請勿使用 realloc() 來調整儲存敏感資訊的緩衝區大小。此函數可能會將敏感資訊的副本鎖在記憶體中,無法覆寫。
Explanation
當敏感資料 (如密碼或密鑰) 沒有從記憶體中刪除而被駭客看到的時候,就會產生 Heap Inspection 弱點。

realloc() 函數通常是用來提高分配記憶體區塊的大小。此操作通常需要將舊記憶體區塊中的內容轉移到容量更大的新記憶體區塊。它會完整無缺地保留原來記憶體區塊中的內容,但是不會讓程式得到任何內容,藉此阻止了程式清除記憶體中敏感資訊的能力。如果攻擊者之後能夠檢查記憶體傾印的內容,敏感資料就會暴露出來。

範例:以下程式碼在包含敏感資料的緩衝區中呼叫了 realloc()


plaintext_buffer = get_secret();
...
plaintext_buffer = realloc(plaintext_buffer, 1024);
...
scrub_memory(plaintext_buffer, 1024);


這嘗試清除記憶體中的敏感資料,但因為使用了 realloc(),所以資料副本仍然會在原來對 plaintext_buffer 分配的記憶體中暴露出來。
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 244
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001090, CCI-001199
[6] Standards Mapping - FIPS200 MP
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-4 Information in Shared Resources (P1), SC-28 Protection of Information at Rest (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-4 Information in Shared System Resources, SC-28 Protection of Information at Rest
[10] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data (L1 L2 L3), 8.3.6 Sensitive Private Data (L2 L3)
[11] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[12] Standards Mapping - OWASP Mobile 2024 M6 Inadequate Privacy Controls
[13] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[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 A05 Security Misconfiguration
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.4, Requirement 6.5.8, Requirement 8.4
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.4, Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.4, Requirement 6.5.3, Requirement 8.4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.5.1, Requirement 6.2.4, Requirement 8.3.1
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.5 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.5 - Sensitive Data Retention
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.5 - Sensitive Data Retention
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3230.2 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3230.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3230.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3230.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3230.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3230.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3230.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[53] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.cpp.heap_inspection
Abstract
請勿使用 VirtualLock 來鎖定包含敏感資料的頁面。此函數並不是隨時都可執行的。
Explanation
當敏感資料 (如密碼或密鑰) 沒有從記憶體中刪除而被駭客看到的時候,就會產生 Heap Inspection 弱點。

VirtualLock 函數是用來鎖住記憶體的頁面,以防止在磁碟中被分頁。然而,在 Windows 95/98/ME 作業系統裡,這個函數是不能完整執行的,而且沒有任何影響。

References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 591
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001090, CCI-001199
[3] Standards Mapping - FIPS200 MP
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-4 Information in Shared Resources (P1), SC-28 Protection of Information at Rest (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-4 Information in Shared System Resources, SC-28 Protection of Information at Rest
[7] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[8] Standards Mapping - OWASP Mobile 2024 M6 Inadequate Privacy Controls
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[10] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[11] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[12] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[13] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[14] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.4, Requirement 6.5.8, Requirement 8.4
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.4, Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.4, Requirement 6.5.3, Requirement 8.4
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.5.1, Requirement 6.2.4, Requirement 8.3.1
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.5 - Sensitive Data Retention, Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.5 - Sensitive Data Retention, Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.5 - Sensitive Data Retention, Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[27] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3230.2 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3230.2 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3230.2 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3230.2 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3230.2 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3230.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3230.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[48] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[49] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.cpp.heap_inspection_swappable_memory
Abstract
程式會建立隱藏表單欄位。
Explanation
程式設計師通常會信任隱藏欄位的內容,預期使用者無法檢視或竄改他們的內容。攻擊者將會推翻這些假設。他們會檢查寫入隱藏欄位的值並加以修改,或以攻擊資料取代這些內容。

範例:

HtmlInputHidden hidden = new HtmlInputHidden();


若隱藏欄位具有敏感資訊,該資訊的快取方式將與其他的頁面相同。這可能會導致敏感資訊在使用者不知情的狀況下貯存至瀏覽器快取中。
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 472
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002420
[3] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-8 Transmission Confidentiality and Integrity (P1)
[4] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-8 Transmission Confidentiality and Integrity
[5] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[6] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[7] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[8] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 642
[9] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3610 CAT I
[10] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3610 CAT I
[11] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3610 CAT I
[12] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3610 CAT I
[13] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3610 CAT I
[14] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3610 CAT I
[15] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3610 CAT I
[16] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002485 CAT I
[17] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002485 CAT I
[18] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002485 CAT I
[19] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002485 CAT I
[20] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002485 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002485 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002485 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002485 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002485 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002485 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002485 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002485 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002485 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002485 CAT I
[30] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[31] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.dotnet.hidden_field
Abstract
程式會建立隱藏表單欄位。
Explanation
程式設計師通常會信任隱藏欄位的內容,預期使用者無法檢視或竄改他們的內容。攻擊者將會推翻這些假設。他們會檢查寫入隱藏欄位的值並加以修改,或以攻擊資料取代這些內容。

範例:

Hidden hidden = new Hidden(element);


若隱藏欄位具有敏感資訊,該資訊的快取方式將與其他的頁面相同。這可能會導致敏感資訊在使用者不知情的狀況下貯存至瀏覽器快取中。
References
[1] IDS14-J. Do not trust the contents of hidden form fields CERT
[2] Standards Mapping - Common Weakness Enumeration CWE ID 472
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002420
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-8 Transmission Confidentiality and Integrity (P1)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-8 Transmission Confidentiality and Integrity
[6] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[7] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[8] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[9] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 642
[10] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3610 CAT I
[11] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3610 CAT I
[12] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3610 CAT I
[13] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3610 CAT I
[14] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3610 CAT I
[15] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3610 CAT I
[16] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3610 CAT I
[17] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002485 CAT I
[18] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002485 CAT I
[19] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002485 CAT I
[20] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002485 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002485 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002485 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002485 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002485 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002485 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002485 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002485 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002485 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002485 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002485 CAT I
[31] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[32] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.java.hidden_field
Abstract
已使用隱藏表單欄位。
Explanation
程式設計師通常會信任隱藏欄位的內容,預期使用者無法檢視或竄改他們的內容。攻擊者將會推翻這些假設。他們會檢查寫入隱藏欄位的值並加以修改,或以攻擊資料取代這些內容。

範例: hidden 類型的 <input> 標籤表示使用隱藏欄位。

<input type="hidden">


若隱藏欄位具有敏感資訊,該資訊的快取方式將與其他的頁面相同。這可能會導致敏感資訊在使用者不知情的狀況下貯存至瀏覽器快取中。
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 472
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002420
[3] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-8 Transmission Confidentiality and Integrity (P1)
[4] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-8 Transmission Confidentiality and Integrity
[5] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[6] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[7] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[8] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 642
[9] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3610 CAT I
[10] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3610 CAT I
[11] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3610 CAT I
[12] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3610 CAT I
[13] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3610 CAT I
[14] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3610 CAT I
[15] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3610 CAT I
[16] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002485 CAT I
[17] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002485 CAT I
[18] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002485 CAT I
[19] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002485 CAT I
[20] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002485 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002485 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002485 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002485 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002485 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002485 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002485 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002485 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002485 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002485 CAT I
[30] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[31] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.content.html.hidden_field
Abstract
某些函數會傳回要搜尋之緩衝區邊界以外的記憶體指標。後續操作指標可能會產生意想不到的結果。
Explanation
在以下任一情況下,在緩衝區內搜尋字元的函數,可傳回緩衝區邊界以外的指標:

- 使用者控制了要搜尋的緩衝區內容。

- 使用者控制了要搜尋的值。

範例 1:以下的簡短程式將一個不受信任的指令行引數作為呼叫 rawmemchr() 時的搜尋緩衝區。


int main(int argc, char** argv) {
char* ret = rawmemchr(argv[0], 'x');
printf("%s\n", ret);
}


這個程式本來是要顯示出 argv[0] 的子字串,但是程式可能會以顯示 argv[0] 之前的部分記憶體的方式結束。

這個問題類似於「字串終止錯誤」,程式設計師是依賴字元陣列來包含一個 Null 結束字元。
References
[1] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[2] Standards Mapping - Common Weakness Enumeration CWE ID 466
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [1] CWE ID 119
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [5] CWE ID 119
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [17] CWE ID 119
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [19] CWE ID 119
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [17] CWE ID 119
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754, CCI-002824
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1), SI-16 Memory Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation, SI-16 Memory Protection
[13] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[14] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[16] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] 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
[27] 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
[28] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 119
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
desc.semantic.cpp.illegal_pointer_value.master
Abstract
已將類別註解為不可變,但欄位為可變。
Explanation
此類別已從 JCIP 註解封包加上不可變的註解。但是,類別的可變欄位的其中一欄接收到來自建構函數與解構函數外的可變方式的呼叫。

範例 1:下列不可變 final 類別的程式碼宣告 privatefinal 集,然後錯誤地建立會變動集的方法。


@Immutable
public final class ThreeStooges {
private final Set stooges = new HashSet>();
...

public void addStooge(String name) {
stooges.add(name);
}
...
}
References
[1] B. Goetz Java Concurrency in Practice. Chapter 3: Sharing Objects Guidelines
[2] Package net.jcip.annotations Specification
[3] MUTABLE-1: Prefer immutability for value types Oracle
[4] Standards Mapping - Common Weakness Enumeration CWE ID 471
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[13] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[14] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control
[16] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
desc.structural.java.immutable_field_mutation
Abstract
已將類別註解為不可變,但欄位並非 final
Explanation
此類別已從 JCIP 註解封包加上 Immutable 註解。非 final 欄位允許變更值,因而違反了該類別的不可變性。

範例 1:下列不可變 final 類別的程式碼錯誤地聲明欄位為 public,而不是 final


@Immutable
public class ImmutableInteger {
public int value;

}
References
[1] B. Goetz Java Concurrency in Practice. Chapter 3: Sharing Objects Guidelines
[2] Package net.jcip.annotations Specification
[3] OBJ58-J. Limit the extensibility of classes and methods with invariants CERT
[4] MUTABLE-1: Prefer immutability for value types Oracle
[5] Standards Mapping - Common Weakness Enumeration CWE ID 471
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[14] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[16] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control
[17] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
desc.structural.java.immutable_non_final_fields
Abstract
已將類別註解為不可變,但欄位為可變。
Explanation
此類別已從 JCIP 註解封包加上不可變的註解。可變類型的公用欄位允許至類別以外的外部程式碼修改內容,並違反該類別的不可變性。

範例 1:下列不可變 final 類別的程式碼錯誤地聲明 publicfinal 集。


@Immutable
public final class ThreeStooges {
public final Set stooges = new HashSet();
...
}
References
[1] B. Goetz Java Concurrency in Practice. Chapter 3: Sharing Objects Guidelines
[2] Package net.jcip.annotations Specification
[3] MUTABLE-1: Prefer immutability for value types Oracle
[4] Standards Mapping - Common Weakness Enumeration CWE ID 471
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[13] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[14] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control
[16] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
desc.structural.java.immutable_public_mutable_fields
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 - Common Weakness Enumeration CWE ID 522, CWE ID 829
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [18] CWE ID 522
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [21] CWE ID 522
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[9] 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)
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-3
[11] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
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 - Common Weakness Enumeration CWE ID 522, CWE ID 829
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [18] CWE ID 522
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [21] CWE ID 522
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[9] 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)
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-3
[11] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
desc.structural.swift.input_interception_keyboard_extensions_allowed
Abstract
應用程式包含一個並非專用於在生產環境中部署的元件。
Explanation
Django 應用程式會暴露 static files 應用程式的 serve 視圖,此視圖並非專用於在生產環境中部署。根據 Django 說明文件:

static files 工具主要用於協助取得已在生產中成功部署的靜態檔案。這通常是指單獨、專用的靜態檔案伺服器,於本機開發時,此伺服器的運作成本極高。因此,靜態檔案應用程式隨附臨時應急的協助程式視圖,用來在開發期間於本機執行檔案。

僅當 DEBUGTrue 時,此視圖才有效。

這是因為,此視圖非常低效且可能不安全。這僅適用於本機開發,絕不能用於生產中。」
References
[1] Django Foundation The staticfiles app
[2] Django Foundation Managing static files
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000381
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 CM-7 Least Functionality (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 CM-7 Least Functionality
[7] Standards Mapping - OWASP Mobile 2024 M2 Inadequate Supply Chain Security
[8] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 10.2 - Threat and Vulnerability Management
[9] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 10.2 - Threat and Vulnerability Management
[10] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 10.2 - Threat and Vulnerability Management, Control Objective C.1.6 - Web Software Components & Services
[11] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001500 CAT II
[12] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001500 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001500 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001500 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001500 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001500 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001500 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001500 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001500 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001500 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001500 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001500 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001500 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001500 CAT II
desc.structural.python.insecure_deployment_non_production_ready_staticfiles
Abstract
針對敏感資源使用可預測的名稱有助於攻擊者展開應用程式探索程序。
Explanation
包含敏感資訊或提供具有特殊權限的功能的應用程式資源通常面臨更大的攻擊風險。在偵察階段,攻擊者會嘗試尋找此類檔案和目錄。針對此類資源使用可預測的命名架構會讓攻擊者更容易找到這些資源。處理敏感功能 (例如,驗證、管理工作或私人資訊處理) 的所有應用程式資源都必須得到充分保護,以免被發現。

範例 1:在以下範例中,admin 應用程式部署在可預測的 URL 中:


from django.conf.urls import patterns
from django.contrib import admin

admin.autodiscover()

urlpatterns = patterns('',
...
url(r'^admin/', include(admin.site.urls)),
...


負責儲存資料的資源必須與實作應用程式功能的資源分開。程式設計師必須在建立暫存或備份資源時小心謹慎。
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 340
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[3] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[4] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[5] Standards Mapping - OWASP Mobile 2024 M2 Inadequate Supply Chain Security
[6] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[7] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[8] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[9] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[10] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[11] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[12] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[22] Standards Mapping - Web Application Security Consortium Version 2.00 Predictable Resource Location (WASC-34)
desc.structural.python.insecure_deployment_predictable_resource_name