543 找到的項目
弱點
Abstract
設定了一個 GraphQL 端點以啟用結構描述印表機。
Explanation
Spring GraphQL 應用程式可以選擇啟用結構描述印表機,這是一個自動產生的端點,提供 GraphQL 結構描述的完整視圖。雖然這主要是用於方便內部測試和開發,但在生產中啟用時會對整體安全態勢構成風險。

當在生產中啟用結構描述印表機端點時,它會允許攻擊者取得實作細節,進而使他們能夠執行更具目標性的攻擊。GraphQL 結構描述可能會洩漏資訊,例如內部使用的欄位、描述和過時說明,這些資訊可能非供公開使用。

範例 1:以下 Spring GraphQL 應用程式組態檔會啟用結構描述印表機端點。

spring.graphql.schema.printer.enabled=true
References
[1] OWASP OWASP Cheat Sheet Series: GraphQL Cheat Sheet
[2] Standards Mapping - Common Weakness Enumeration CWE ID 94
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [18] CWE ID 094
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [17] CWE ID 094
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [25] CWE ID 094
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [23] CWE ID 094
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [11] CWE ID 094
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[9] Standards Mapping - FIPS200 CM
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[13] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.5 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.8 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[16] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[18] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[31] 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
[32] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 094
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3600 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3600 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3600 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3600 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3600 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3600 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3600 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-003300 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-003300 CAT II
[56] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.java.graphql_bad_practices_schema_printer_enabled
Abstract
從不受信任的來源建立了 Google 遠端程序呼叫 (gRPC) Metadata 物件,這可能允許攻擊者控制關鍵通訊協定欄位。
Explanation
Metadata 類別通常用於存放 Google 遠端程序呼叫 (gRPC) 所用之基礎通訊協定的標頭資料。當基礎通訊協定是 HTTP 時,控制 Metadata 物件中的資料會使系統容易遭受 HTTP Header Manipulation 攻擊。其他攻擊途徑也是可能的,並且主要都是根據基礎通訊協定。

範例 1:以下程式碼顯示不可信賴的資料被當成 gRPC Metadata 物件的輸入使用。


...
String? evnVar = System.Environment.GetEnvironmentVariable("evnVar ");
Metadata headers = new Metadata();
headers.Add("field", evnVar);
CallOptions callOptions = new CallOptions(headers);
...
References
[1] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[2] Standards Mapping - FIPS200 SI
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[6] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[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 Data Security Standard Version 4.0.1 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 - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
desc.dataflow.dotnet.grpc_metadata_manipulation
Abstract
從不受信任的來源建立了 Google 遠端程序呼叫 (gRPC) Metadata 物件,這可能允許攻擊者控制關鍵通訊協定欄位。
Explanation
Metadata 類別通常用於存放 Google 遠端程序呼叫 (gRPC) 所用之基礎通訊協定的標頭資料。當基礎通訊協定是 HTTP 時,控制 Metadata 物件中的資料會使系統容易遭受 HTTP Header Manipulation 攻擊。其他攻擊途徑也是可能的,並且主要都是根據基礎通訊協定。

範例 1:以下程式碼顯示使用者可控資料被當成 gRPC Metadata 物件的輸入使用。


...
String badData = getUserInput();
Metadata headers = new Metadata();
headers.put(Metadata.Key.of("sample", Metadata.ASCII_STRING_MARSHALLER), badData);
...
References
[1] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[2] Standards Mapping - FIPS200 SI
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[6] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[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 Data Security Standard Version 4.0.1 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 - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
desc.dataflow.java.grpc_metadata_manipulation
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 Data Security Standard Version 4.0.1 Requirement 6.2.4
[13] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[14] 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
[15] 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
[16] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[17] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[18] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[19] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[20] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[32] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.hadoop_cluster_manipulation
Abstract
提交到 Hadoop 叢集的 Job 在不友善的環境中可能遭到竄改。
Explanation
以下情況中會發生 Hadoop 工作竄改錯誤:

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

- 資料被用來指定控制用戶端工作的 JobConf 值。

Hadoop 叢集是不友善的環境。當未正確設定安全配置,無法防護未獲授權而存取叢集機器上的 HDFS 時,攻擊就有可能控制情況。這可能導致 Hadoop 叢集提供的資料遭到竄改。

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


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

String inputDir = args[0];
String outputDir = args[1];

// Untrusted command line argument
int numOfReducers = Integer.parseInt(args[3]);
Class mapper = getClassByName(args[4]);
Class reducer = getClassByName(args[5]);

Configuration defaults = new Configuration();
JobConf job = new JobConf(defaults, OptimizedDataJoinJob.class);
job.setNumMapTasks(1);
// An attacker may set random values that exceed the range of acceptable number of reducers
job.setNumReduceTasks(numOfReducers);

return job;
}
範例 2:以下程式碼顯示的案例為攻擊者控制執行中工作,透過指令行引數使工作無法執行:


public static void main(String[] args) throws Exception {

JobID id = JobID.forName(args[0]);
JobConf conf = new JobConf(WordCount.class);
// configure this JobConf instance
...
JobClient.runJob(conf);
RunningJob job = JobClient.getJob(id);
job.killJob();

}
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 Data Security Standard Version 4.0.1 Requirement 6.2.4
[13] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[14] 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
[15] 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
[16] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[17] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[18] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[19] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[20] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[32] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.hadoop_job_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 表頭時,仍需特別注意。

範例 1:以下程式碼區段會從 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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] 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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] 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 表頭時,仍需特別注意。

範例 1:以下程式碼區段會從 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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] 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 表頭時,仍需特別注意。

範例 1:以下程式碼區段會從 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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] 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 表頭時,仍需特別注意。

範例 1:以下程式碼區段會從 Web 要求中讀取網路部落格項目的作者名稱 (author),並且將該名稱設定在 HTTP 回應的 Cookie 標頭中。


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


假設在要求中提交了一個由標準英數字元所組成的字串,如 "Jane Smith",那麼包含這個 Cookie 的 HTTP 回應可能會採用以下形式:


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


不過,因為 cookie 的值是由未經驗證的使用者輸入而得來,所以只有當傳送給 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字元,那麼回應才會保留這種形式。若攻擊者提交惡意字串,例如「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」,則 HTTP 回應將分割為以下形式的兩種回應:


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

HTTP/1/1 200 OK
...


很明顯的,第二個回應完全被攻擊者所控制,並且能使用任何標頭和想要的正文內容來建構。攻擊者可以建構任何 HTTP 回應,並造成不同的攻擊結果,這些攻擊包括:跨用戶塗改、網頁和瀏覽器快取記憶體下毒、Cross-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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] 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 標頭時,仍需特別注意。

範例 1:以下程式碼片段會讀取 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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[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 Data Security Standard Version 4.0.1 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 - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[53] 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 回應標頭中。


範例 1:以下程式碼區段會從 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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[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 Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[28] 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
[29] 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
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] 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 表頭時,仍需特別注意。

範例 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 和網頁劫持。

跨用戶塗改:攻擊者將能夠發出單一要求到易受攻擊的伺服器,讓伺服器建立兩個回應,其中第二個回應可能會被錯誤解譯成針對不同要求的回應,該要求可能是由另一個與伺服器共用相同 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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] 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 表頭時,仍需特別注意。

範例 1:以下程式碼區段會從 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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] 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 表頭時,仍需特別注意。

範例 1:以下程式碼片段假設 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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] 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 表頭時,仍需特別注意。

範例 1:以下程式碼片段會讀取 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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] 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 表頭時,仍需特別注意。

範例 1:以下程式碼區段會從 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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] 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 表頭時,仍需特別注意。

範例 1:以下程式碼片段會讀取 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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] 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 表頭時,仍需特別注意。

範例 1:以下程式碼區段會從 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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[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 Data Security Standard Version 4.0.1 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 - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[53] 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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] 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 表頭時,仍需特別注意。

範例 1:以下程式碼片段假設 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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] 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 的伺服器通常沒有這項保護機制。

範例 1:以下程式碼區段會從 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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] 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 表頭時,仍需特別注意。

範例 1:以下程式碼區段會從 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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] 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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] 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 表頭時,仍需特別注意。

範例 1:以下程式碼區段會從 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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] 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 表頭時,仍需特別注意。

範例 1:以下程式碼區段會從 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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] 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 標頭時,仍需特別注意。

範例 1:以下程式碼區段會從 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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[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 Data Security Standard Version 4.0.1 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 - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[53] 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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] 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 表頭時,仍需特別注意。

範例 1:以下程式碼區段會從 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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] 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 表頭時,仍需特別注意。

範例 1:以下程式碼區段會從 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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] 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 表頭時,仍需特別注意。

範例 1:以下程式碼片段會讀取 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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] 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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] 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 表頭時,仍需特別注意。

範例 1:以下程式碼區段會從 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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] 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 表頭以匿名散發垃圾郵件。

範例 1:以下程式碼片段會讀取「聯絡我們」表單的主旨和內文:


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 Data Security Standard Version 4.0.1 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 - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] 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 標頭以匿名散發垃圾郵件。

範例 1:以下程式碼片段會讀取「聯絡我們」表單的主旨和內文:


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 Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[28] 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
[29] 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
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] 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 表頭以匿名散發垃圾郵件。

範例 1:以下程式碼片段會讀取「聯絡我們」表單的主旨和內文:


$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 Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[28] 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
[29] 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
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] 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 表頭以匿名散發垃圾郵件。

範例 1:以下程式碼片段會讀取「聯絡我們」表單的主旨和內文:


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 Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[28] 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
[29] 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
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.python.header_manipulation_smtp
Abstract
程式會建立隱藏表單欄位。
Explanation
程式設計師通常會信任隱藏欄位的內容,預期使用者無法檢視或竄改他們的內容。攻擊者將會推翻這些假設。他們會檢查寫入隱藏欄位的值並加以修改,或以攻擊資料取代這些內容。

範例 1:

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 - Security Technical Implementation Guide Version 6.1 APSC-DV-002485 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002485 CAT I
[32] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[33] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.dotnet.hidden_field
Abstract
程式會建立隱藏表單欄位。
Explanation
程式設計師通常會信任隱藏欄位的內容,預期使用者無法檢視或竄改他們的內容。攻擊者將會推翻這些假設。他們會檢查寫入隱藏欄位的值並加以修改,或以攻擊資料取代這些內容。

範例 1:

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 - Security Technical Implementation Guide Version 6.1 APSC-DV-002485 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002485 CAT I
[33] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[34] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.java.hidden_field
Abstract
已使用隱藏表單欄位。
Explanation
程式設計師通常會信任隱藏欄位的內容,預期使用者無法檢視或竄改他們的內容。攻擊者將會推翻這些假設。他們會檢查寫入隱藏欄位的值並加以修改,或以攻擊資料取代這些內容。

範例 1: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 - Security Technical Implementation Guide Version 6.1 APSC-DV-002485 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002485 CAT I
[32] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[33] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.content.html.hidden_field
Abstract
X-XSS-Protection 表頭已明確停用,這可能會增加 Cross-site scripting 攻擊的風險。
Explanation
在現代瀏覽器中,通常預設啟用 X-XSS-Protection 標頭。設定標頭值為 false (0) 時,會停用 Cross-Site Scripting 保護。

可在多個位置設定表頭,並應檢查該表頭是否存在配置錯誤與惡意篡改。
References
[1] IE8 Security Part IV: The XSS Filter
[2] OWASP OWASP Secure Headers Project
[3] HttpResponse.AppendHeader Method
[4] How to prevent cross-site scripting security issues
[5] HOW TO: Disable the Documentation Protocol for ASP.NET Web Services
[6] Configuring Services Using Configuration Files
[7] Standards Mapping - Common Weakness Enumeration CWE ID 554, CWE ID 1173
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[13] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[15] Standards Mapping - FIPS200 CM
[16] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[19] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[20] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[21] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[23] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[24] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[25] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[26] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.dotnet.html5_xss_protection
Abstract
X-XSS-Protection 標頭已明確停用,這可能會增加 Cross-Site Scripting 攻擊的風險。
Explanation
在現代瀏覽器中,通常預設啟用 X-XSS-Protection 標頭。設定標頭值為 false (0) 時,會停用 Cross-Site Scripting 保護。

可在多個位置設定標頭,並應檢查該標頭是否存在配置錯誤與惡意篡改。

範例 1:以下程式碼會將受 Spring Security 保護的應用程式設定為停用 XSS 保護:

<http auto-config="true">
...
<headers>
...
<xss-protection xss-protection-enabled="false" />
</headers>
</http>
References
[1] IE8 Security Part IV: The XSS Filter
[2] OWASP OWASP Secure Headers Project
[3] Standards Mapping - Common Weakness Enumeration CWE ID 554, CWE ID 1173
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 CM
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[17] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[19] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.java.html5_cross_site_scripting_protection
Abstract
X-XSS-Protection 表頭已明確停用,這可能會增加 Cross-site scripting 攻擊的風險。
Explanation
在現代瀏覽器中,通常預設啟用 X-XSS-Protection 標頭。設定標頭值為 false (0) 時,會停用 Cross-Site Scripting 保護。
可在多個位置設定表頭,並應檢查該表頭是否存在配置錯誤與惡意篡改。
References
[1] IE8 Security Part IV: The XSS Filter
[2] OWASP OWASP Secure Headers Project
[3] Node.js Security Checklist
[4] Standards Mapping - Common Weakness Enumeration CWE ID 554, CWE ID 1173
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[10] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[12] Standards Mapping - FIPS200 CM
[13] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[16] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[17] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[18] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[20] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[23] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.dataflow.javascript.html5_cross_site_scripting_protection
Abstract
X-XSS-Protection 表頭已明確停用,這可能會增加 Cross-site scripting 攻擊的風險。
Explanation
在現代瀏覽器中,通常預設啟用 X-XSS-Protection 標頭。設定標頭值為 false (0) 時,會停用 Cross-Site Scripting 保護。

可在多個位置設定表頭,並應檢查該表頭是否存在配置錯誤與惡意篡改。
References
[1] IE8 Security Part IV: The XSS Filter
[2] OWASP OWASP Secure Headers Project
[3] django-secure
[4] SECURE_BROWSER_XSS_FILTER
[5] Standards Mapping - Common Weakness Enumeration CWE ID 554, CWE ID 1173
[6] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[10] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[11] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[13] Standards Mapping - FIPS200 CM
[14] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[19] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[21] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[23] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[24] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.python.html5_cross_site_scripting_protection
Abstract
方法 Application_BeginRequest 為空,或不包括將 X-Content-Type-Options 設定為 nosniff 的函數呼叫,或嘗試移除該表頭。
Explanation
MIME 攔截,是檢查位元組資料流內容的作法,可嘗試推算其內資料的檔案格式。

如果不明確停用 MIME 攔截,則某些瀏覽器可能會遭受操縱,從而以非預期的方式解譯資料,導致出現 Cross-site scripting 攻擊。

對於可能包含使用者可控內容的每個頁面,您應該使用 HTTP 表頭 X-Content-Type-Options: nosniff
References
[1] Reducing MIME type security risks
[2] ASP.NET Configuration Files
[3] Global.asax Syntax
[4] IE8 Security Part V: Comprehensive Protection
[5] Custom HttpModule Example
[6] HttpResponse Class
[7] MIME types and stylesheets
[8] Standards Mapping - Common Weakness Enumeration CWE ID 554
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[12] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[13] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[14] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[16] Standards Mapping - FIPS200 CM
[17] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[22] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[23] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[24] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[25] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[26] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[27] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002560 CAT I
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.dotnet.html5_mime_sniffing
Abstract
應用程式套用 MIME 攔截演算法,或未將 X-Content-Type-Options 設定為 nosniff
Explanation
MIME 攔截是檢查位元組串流內容的做法,可嘗試推算其中所包含資料的檔案格式。

如果不明確停用 MIME 攔截,則某些瀏覽器可能會遭受操縱,從而以非預期的方式解譯資料,導致出現 Cross-Site Scripting 攻擊。
撰寫 Web 應用程式時,請將 HTTP 標頭 X-Content-Type-Options: nosniff 用於可能含有使用者可控制內容的每個頁面中。
撰寫用戶端應用程式時,不得使用 MIME 攔截演算法確定伺服器的回應 Content-Type。

範例 1:下列程式碼使用 net.http.DetectContentType() 確定資源 Content-Type:


...
resp, err := http.Get("http://example.com/")
if err != nil {
// handle error
}
defer resp.Body.Close()
body, err := ioutil.ReadAll(resp.Body)

content_type := DetectContentType(body)
...
References
[1] OWASP OWASP Secure Headers Project
[2] WHATWG MIME Sniffing
[3] Standards Mapping - Common Weakness Enumeration CWE ID 554
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 CM
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[17] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[19] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.dataflow.golang.html5_mime_sniffing
Abstract
應用程式不會將 X-Content-Type-Options 設定為 nosniff,或明確停用此安全性標頭。
Explanation
MIME 攔截是檢查位元組串流內容的做法,可推算其中所包含資料的檔案格式。

如果未明確停用 MIME 攔截,攻擊者可以操縱某些瀏覽器以非預期的方式解譯資料,進行導致出現 Cross-Site Scripting 攻擊。對於可能包含使用者可控內容的每個頁面,您應該使用 HTTP 標頭 X-Content-Type-Options: nosniff

範例 1:以下程式碼會將受 Spring Security 保護的應用程式設定為停用 MIME 攔截保護:

<http auto-config="true">
...
<headers>
...
<content-type-options disabled="true"/>
</headers>
</http>
References
[1] OWASP OWASP Secure Headers Project
[2] Standards Mapping - Common Weakness Enumeration CWE ID 554
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 CM
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[16] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[18] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.java.html5_mime_sniffing
Abstract
Node.js 應用程式不會將 X-Content-Type-Options 設定為 nosniff,或明確停用此安全性標頭。
Explanation
MIME 攔截是檢查位元組串流內容的做法,可嘗試推算其中所包含資料的檔案格式。

如果不明確停用 MIME 攔截,則某些瀏覽器可能會遭受操縱,從而以非預期的方式解譯資料,導致出現 Cross-site scripting 攻擊。

對於可能包含使用者可控內容的每個頁面,您應該使用 HTTP 表頭 X-Content-Type-Options: nosniff
References
[1] Node.js Security Checklist
[2] OWASP OWASP Secure Headers Project
[3] Standards Mapping - Common Weakness Enumeration CWE ID 554
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 CM
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[17] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[19] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.dataflow.javascript.html5_mime_sniffing
Abstract
Django 應用程式不會將 X-Content-Type-Options 設為 nosniff,或明確停用此安全性表頭。
Explanation
MIME 攔截是檢查位元組串流內容的做法,可嘗試推算其中所包含資料的檔案格式。

如果不明確停用 MIME 攔截,則某些瀏覽器可能會遭受操縱,從而以非預期的方式解譯資料,導致出現 Cross-Site Scripting 攻擊。

對於可能包含使用者可控內容的每個頁面,您應該使用 HTTP 表頭 X-Content-Type-Options: nosniff
References
[1] SECURE_CONTENT_TYPE_NOSNIFF
[2] django-secure
[3] OWASP OWASP Secure Headers Project
[4] Standards Mapping - Common Weakness Enumeration CWE ID 554
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[10] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[12] Standards Mapping - FIPS200 CM
[13] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[16] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[17] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[18] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[20] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[23] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.python.html5_mime_sniffing
Abstract
內容安全性原則 (CSP) 未設定。
Explanation
內容安全性原則 (CSP) 是一種宣告式安全性標頭,可讓開發人員指示在網頁瀏覽器中轉譯時,允許網站從哪些網域載入內容或起始到哪些網域的連線。除了程式碼中的輸入驗證和檢查允許清單外,它還提供額外一層的安全性,以防禦重要弱點,例如,Cross-Site Scripting、Clickjacking、Cross-Origin Access 等。

依預設,Spring Security 和其他架構並不新增內容安全性原則標頭。Web 應用程式作者必須宣告一或多個安全性原則,以強制執行或監視受保護的資源,進而從這額外一層的安全性受益。
References
[1] Mozilla Content Security Policy
[2] W3C Content Security Policy 2.0
[3] Standards Mapping - Common Weakness Enumeration CWE ID 1173
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[16] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[46] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.java.html5_missing_content_security_policy
Abstract
應用程式未限制瀏覽器讓第三方網站轉譯其內容。
Explanation
允許將您的網站新增到框架會引起安全問題。例如,這可能導致點擊劫持弱點,或允許不希望的跨框架通訊。

依預設,Spring Security 之類的架構包含 X-Frame-Options 標頭,以指示瀏覽器是否應對應用程式進行框架處理。停用或未設定此標頭會導致跨框架相關弱點。

範例 1:以下程式碼會將受 Spring Security 保護的應用程式設定為停用 X-Frame-Options 標頭:

<http auto-config="true">
...
<headers>
...
<frame-options disabled="true"/>
</headers>
</http>
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 1021
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[6] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.7 HTTP Security Headers Requirements (L1 L2 L3)
[7] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[8] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[9] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[10] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[11] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[12] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[22] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.java.html5_missing_framing_protection
Abstract
內容安全性原則 (CSP) 使用過度許可原則進行配置,會有安全上的風險。
Explanation
內容安全性原則 (CSP) 是一種宣告式安全性標頭,可讓開發人員指定瀏覽器中允許的安全性相關行為,包括可從中擷取內容的位置允許清單。除了程式碼中的輸入驗證和檢查允許清單外,它還提供額外一層的安全性,以防禦重要弱點,例如,Cross-Site Scripting、Clickjacking、Cross-Origin Access 等。但設定不當的標頭無法提供這種額外一層的安全性。該原則藉助於 15 個指令進行定義,其中包括 8 個用於控制資源存取的指令,即:script-srcimg-srcobject-srcstyle_srcfont-srcmedia-srcframe-srcconnect-src。這 8 個指令都將一個來源清單做為值,指定網站可存取的網域,以使用該指令所涵蓋的功能。開發人員可使用萬用字元 * 來指示所有或部分來源。其他來源清單關鍵字 (例如 'unsafe-inline''unsafe-eval') 提供更精細的方式來控制 script 執行,但這些是潛在有害的關鍵字。所有指令都不是強制性的。瀏覽器允許未列示指令的所有來源,或從選用的 default-src 指令衍生值。此外,此標頭的規格隨著時間的推移而不斷演變。在第 23 版之前的 Firefox 和第 10 版之前的 IE 中,其實作為 X-Content-Security-Policy,而在第 25 版之前的 Chrome 中,則實作為 X-Webkit-CSP。兩個名稱都已棄用,取代為現在的標準名稱 Content Security Policy。鑒於指令的數目、兩個棄用的替代名稱,以及對待多次出現之同一標頭和單一標頭中重複指令的方式,開發人員很可能會錯誤地設定此標頭。

範例 1:以下程式碼會設定過度寬鬆且不安全的 default-src 指令:

<http auto-config="true">
...
<headers>
...
<content-security-policy policy-directives="default-src '*'" />
</headers>
</http>
References
[1] Mozilla Content Security Policy
[2] W3C Content Security Policy 2.0
[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 2024 M8 Security Misconfiguration
[8] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[9] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[10] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[11] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 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 - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.java.html5_overly_permissive_content_security_policy
Abstract
內容安全性原則 (CSP) 使用過度許可原則進行配置,會有安全上的風險。
Explanation
內容安全性原則 (CSP) 是一種宣告式安全性標頭,可讓開發人員指定瀏覽器中允許的安全性相關行為,包括可從中擷取內容的位置允許清單。除了程式碼中的輸入驗證和檢查允許清單外,它還提供額外一層的安全性,以防禦重要弱點,例如,Cross-Site Scripting、Clickjacking、Cross-Origin Access 等。但設定不當的標頭無法提供這種額外一層的安全性。該原則藉助於 15 個指令進行定義,其中包括 8 個用於控制資源存取的指令,即:script-srcimg-srcobject-srcstyle_srcfont-srcmedia-srcframe-srcconnect-src。這 8 個指令都將一個來源清單做為值,指定網站可存取的網域,以使用該指令所涵蓋的功能。開發人員可使用萬用字元 * 來指示所有或部分來源。其他來源清單關鍵字 (例如 'unsafe-inline''unsafe-eval') 提供更精細的方式來控制 script 執行,但這些是潛在有害的關鍵字。所有指令都不是強制性的。瀏覽器允許未列示指令的所有來源,或從選用的 default-src 指令衍生值。此外,此標頭的規格隨著時間的推移而不斷演變。在第 23 版之前的 Firefox 和第 10 版之前的 IE 中,其實作為 X-Content-Security-Policy,而在第 25 版之前的 Chrome 中,則實作為 X-Webkit-CSP。兩個名稱都已棄用,取代為現在的標準名稱 Content Security Policy。鑒於指令的數目、兩個棄用的替代名稱,以及對待多次出現之同一標頭和單一標頭中重複指令的方式,開發人員很可能會錯誤地設定此標頭。

在此案例中,使用了過度許可原則 (如 *) 來配置 *-src 指令。

範例 1:以下 django-csp 設定會設定過度許可且不安全的 default-src 指令:


...
MIDDLEWARE = (
...
'csp.middleware.CSPMiddleware',
...
)
...
CSP_DEFAULT_SRC = ("'self'", '*')
...
References
[1] Mozilla Content Security Policy
[2] W3C Content Security Policy 2.0
[3] Mozilla django-csp
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[8] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[9] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[10] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[11] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[12] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[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 Data Security Standard Version 4.0.1 Requirement 6.2.4
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[24] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.python.html5_overly_permissive_content_security_policy
Abstract
程式會定義過度許可的跨原始來源資源分享 (CORS) 政策。
Explanation
在 HTML5 之前,網頁瀏覽器會強制執行相同來源原則,確保在使用 JavaScript 存取網頁內容時,JavaScript 和網頁來自相同的網域。若不使用相同來源策略 (Same Origin Policy),惡意的網站可使用用戶端的憑證來執行 JavaScript,從其他網站載入敏感的資訊,從中挑選出資訊並將資訊回傳給攻擊者。HTML5 使 JavaScript 可以在定義稱為 Access-Control-Allow-Origin 的新 HTTP 標頭時,存取不同網域間的資料。Web 伺服器可使用此標頭,定義允許使用跨來源要求存取其網域的其他網域。但是,定義標頭時請謹慎小心,因為過度許可的 CORS 原則會允許惡意應用程式以不當方式與受害應用程式通訊,進行導致詐騙、資料竊取、轉送和其他攻擊。

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


Response.AppendHeader("Access-Control-Allow-Origin", "*");


使用 * 做為 Access-Control-Allow-Origin 表頭的值,表示應用程式的資料可以讓在任何網域上執行的 JavaScript 存取。
References
[1] W3C Cross-Origin Resource Sharing
[2] Enable Cross-Origin Resource Sharing
[3] Michael Schmidt HTML5 Web Security
[4] Philippe De Ryck, Lieven Desmet, Pieter Philippaerts, and Frank Piessens A Security Analysis of Next Generation Web Standards
[5] Standards Mapping - Common Weakness Enumeration CWE ID 942
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [18] CWE ID 863
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[13] 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)
[14] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[15] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[29] 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, Control Objective C.3.6 - Web Software Attack Mitigation
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[46] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.semantic.dotnet.html5_overly_permissive_cors_policy
Abstract
程式定義過度許可的 Cross-Origin Resource Sharing (CORS) 原則。
Explanation
在 HTML5 之前,網頁瀏覽器會強制執行相同來源原則,確保在使用 JavaScript 存取網頁內容時,JavaScript 和網頁來自相同的網域。若不使用相同來源策略 (Same Origin Policy),惡意的網站可使用用戶端的憑證來執行 JavaScript,從其他網站載入敏感的資訊,從中挑選出資訊並將資訊回傳給攻擊者。HTML5 使 JavaScript 可以在定義稱為 Access-Control-Allow-Origin 的新 HTTP 標頭時,存取不同網域間的資料。Web 伺服器可使用此標頭,定義允許使用跨來源要求存取其網域的其他網域。但是,定義標頭時請謹慎小心,因為過度許可的 CORS 原則會允許惡意應用程式以不當方式與受害應用程式通訊,進行導致詐騙、資料竊取、轉送和其他攻擊。

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


<websocket:handlers allowed-origins="*">
<websocket:mapping path="/myHandler" handler="myHandler" />
</websocket:handlers>


使用 * 做為 Access-Control-Allow-Origin 表頭的值,表示應用程式的資料可以讓在任何網域上執行的 JavaScript 存取。
References
[1] W3C Cross-Origin Resource Sharing
[2] Enable Cross-Origin Resource Sharing
[3] Michael Schmidt HTML5 Web Security
[4] Philippe De Ryck, Lieven Desmet, Pieter Philippaerts, and Frank Piessens A Security Analysis of Next Generation Web Standards
[5] Standards Mapping - Common Weakness Enumeration CWE ID 942
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [18] CWE ID 863
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[13] 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)
[14] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[15] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[29] 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, Control Objective C.3.6 - Web Software Attack Mitigation
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[46] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.java.html5_overly_permissive_cors_policy
Abstract
程式會定義過度許可的跨原始來源資源分享 (CORS) 政策。
Explanation
在 HTML5 之前,網頁瀏覽器會強制執行相同來源原則,確保在使用 JavaScript 存取網頁內容時,JavaScript 和網頁來自相同的網域。若不使用相同來源策略 (Same Origin Policy),惡意的網站可使用用戶端的憑證來執行 JavaScript,從其他網站載入敏感的資訊,從中挑選出資訊並將資訊回傳給攻擊者。HTML5 使 JavaScript 可以在定義稱為 Access-Control-Allow-Origin 的新 HTTP 標頭時,存取不同網域間的資料。Web 伺服器可使用此標頭,定義允許使用跨來源要求存取其網域的其他網域。但是,定義標頭時請謹慎小心,因為過度許可的 CORS 原則會允許惡意應用程式以不當方式與受害應用程式通訊,進行導致詐騙、資料竊取、轉送和其他攻擊。

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


<?php
header('Access-Control-Allow-Origin: *');
?>


使用 * 做為 Access-Control-Allow-Origin 表頭的值,表示應用程式的資料可以讓在任何網域上執行的 JavaScript 存取。
References
[1] W3C Cross-Origin Resource Sharing
[2] Enable Cross-Origin Resource Sharing
[3] Michael Schmidt HTML5 Web Security
[4] Philippe De Ryck, Lieven Desmet, Pieter Philippaerts, and Frank Piessens A Security Analysis of Next Generation Web Standards
[5] Standards Mapping - Common Weakness Enumeration CWE ID 942
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [18] CWE ID 863
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[13] 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)
[14] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[15] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[29] 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, Control Objective C.3.6 - Web Software Attack Mitigation
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[46] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.semantic.php.html5_overly_permissive_cors_policy
Abstract
程式會定義過度許可的跨原始來源資源分享 (CORS) 政策。
Explanation
在 HTML5 之前,網頁瀏覽器會強制執行相同來源原則,確保在使用 JavaScript 存取網頁內容時,JavaScript 和網頁來自相同的網域。若不使用相同來源策略 (Same Origin Policy),惡意網站可使用用戶端的憑證執行從其他網站載入敏感資訊的 JavaScript,從中挑選資訊,並將資訊回傳給攻擊者。HTML5 使 JavaScript 可以在定義稱為 Access-Control-Allow-Origin 的新 HTTP 標頭時,存取不同網域間的資料。Web 伺服器可使用此標頭,定義允許使用跨來源要求存取其網域的其他網域。但是,定義標頭時請謹慎小心,因為過度許可的 CORS 原則會允許惡意應用程式以不當方式與受害應用程式通訊,進行導致詐騙、資料竊取、轉送和其他攻擊。

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


response.addHeader("Access-Control-Allow-Origin", "*")


使用 * 作為 Access-Control-Allow-Origin 表頭的值,表示應用程式的資料可供在任何網域上執行的 JavaScript 存取。
References
[1] W3C Cross-Origin Resource Sharing
[2] Enable Cross-Origin Resource Sharing
[3] Michael Schmidt HTML5 Web Security
[4] Philippe De Ryck, Lieven Desmet, Pieter Philippaerts, and Frank Piessens A Security Analysis of Next Generation Web Standards
[5] Standards Mapping - Common Weakness Enumeration CWE ID 942
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [18] CWE ID 863
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[13] 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)
[14] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[15] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[29] 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, Control Objective C.3.6 - Web Software Attack Mitigation
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[46] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.semantic.python.html5_overly_permissive_cors_policy
Abstract
程式會定義過度許可的 Cross-Origin Resource Sharing (CORS) 政策。
Explanation
在 HTML5 之前,網頁瀏覽器會強制執行相同來源原則,確保在使用 JavaScript 存取網頁內容時,JavaScript 和網頁來自相同的網域。若不使用相同來源策略 (Same Origin Policy),惡意網站可使用用戶端的憑證執行從其他網站載入敏感資訊的 JavaScript,從中挑選資訊,並將資訊回傳給攻擊者。HTML5 使 JavaScript 可以在定義稱為 Access-Control-Allow-Origin 的新 HTTP 標頭時,存取不同網域間的資料。Web 伺服器可使用此標頭,定義允許使用跨來源要求存取其網域的其他網域。但是,定義標頭時請謹慎小心,因為過度許可的 CORS 原則會允許惡意應用程式以不當方式與受害應用程式通訊,進行導致詐騙、資料竊取、轉送和其他攻擊。

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


play.filters.cors {
pathPrefixes = ["/some/path", ...]
allowedOrigins = ["*"]
allowedHttpMethods = ["GET", "POST"]
allowedHttpHeaders = ["Accept"]
preflightMaxAge = 3 days
}


使用 * 作為 Access-Control-Allow-Origin 標頭的值,表示應用程式的資料可供在任何網域上執行的 JavaScript 存取。
References
[1] W3C Cross-Origin Resource Sharing
[2] Enable Cross-Origin Resource Sharing
[3] Michael Schmidt HTML5 Web Security
[4] Philippe De Ryck, Lieven Desmet, Pieter Philippaerts, and Frank Piessens A Security Analysis of Next Generation Web Standards
[5] Standards Mapping - Common Weakness Enumeration CWE ID 942
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [18] CWE ID 863
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[13] 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)
[14] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[15] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[29] 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, Control Objective C.3.6 - Web Software Attack Mitigation
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[46] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.semantic.scala.html5_overly_permissive_cors_policy
Abstract
程式會定義過度許可的跨原始來源資源分享 (CORS) 政策。
Explanation
在 HTML5 之前,網頁瀏覽器會強制執行相同來源原則,確保在使用 JavaScript 存取網頁內容時,JavaScript 和網頁來自相同的網域。若不使用相同來源策略 (Same Origin Policy),惡意的網站可使用用戶端的憑證來執行 JavaScript,從其他網站載入敏感的資訊,從中挑選出資訊並將資訊回傳給攻擊者。HTML5 使 JavaScript 可以在定義稱為 Access-Control-Allow-Origin 的新 HTTP 標頭時,存取不同網域間的資料。Web 伺服器可使用此標頭,定義允許使用跨來源要求存取其網域的其他網域。但是,定義標頭時請謹慎小心,因為過度許可的 CORS 原則會允許惡意應用程式以不當方式與受害應用程式通訊,進行導致詐騙、資料竊取、轉送和其他攻擊。

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


Response.AddHeader "Access-Control-Allow-Origin", "*"


使用 * 做為 Access-Control-Allow-Origin 表頭的值,表示應用程式的資料可以讓在任何網域上執行的 JavaScript 存取。
References
[1] W3C Cross-Origin Resource Sharing
[2] Enable Cross-Origin Resource Sharing
[3] Michael Schmidt HTML5 Web Security
[4] Philippe De Ryck, Lieven Desmet, Pieter Philippaerts, and Frank Piessens A Security Analysis of Next Generation Web Standards
[5] Standards Mapping - Common Weakness Enumeration CWE ID 942
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [18] CWE ID 863
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[13] 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)
[14] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[15] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[29] 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, Control Objective C.3.6 - Web Software Attack Mitigation
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[46] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.semantic.vb.html5_overly_permissive_cors_policy
Abstract
程式發佈了跨文件訊息,但其目標來源過度允許。
Explanation
HTML5 的新功能之一便是跨文件訊息。此功能可允許 Script 將訊息發佈至其他視窗。相應的 API 允許使用者指定目標視窗的來源。但是,指定目標來源時應特別小心,因為過度允許的目標來源會允許惡意指令碼以不適當的方式與受害者視窗通訊,導致欺騙、資料遭竊取、傳遞和其他攻擊。

範例 1:以下範例使用萬用字元來以程式化方式指定要傳送之訊息的目標來源。


WebMessage message = new WebMessage(WEBVIEW_MESSAGE);
webview.postWebMessage(message, Uri.parse("*"));


使用 * 作為目標來源值,代表指令碼會傳送訊息至視窗而不論其來源。
References
[1] Michael Schmidt HTML5 Web Security
[2] Philippe De Ryck, Lieven Desmet, Pieter Philippaerts, and Frank Piessens A Security Analysis of Next Generation Web Standards
[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 - Common Weakness Enumeration Top 25 2024 [18] CWE ID 863
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[10] 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)
[11] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[12] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[13] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-1
[14] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[15] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[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 Data Security Standard Version 4.0.1 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[28] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
desc.controlflow.java.html5_overly_permissive_message_posting_policy
Abstract
程式發佈了跨文件訊息,但其目標來源過度允許。
Explanation
HTML5 的新功能之一便是跨文件訊息。此功能可允許 Script 將訊息發佈至其他視窗。相應的 API 允許使用者指定目標視窗的來源。但是,指定目標來源時應特別小心,因為過度允許的目標來源會允許惡意指令碼以不適當的方式與受害者視窗通訊,導致欺騙、資料遭竊取、傳遞和其他攻擊。

範例 1:以下範例使用萬用字元來以程式化方式指定要傳送之訊息的目標來源。


o.contentWindow.postMessage(message, '*');


使用 * 做為目標來源值,代表 Script 會傳送訊息至視窗而不論其來源。
References
[1] Michael Schmidt HTML5 Web Security
[2] Philippe De Ryck, Lieven Desmet, Pieter Philippaerts, and Frank Piessens A Security Analysis of Next Generation Web Standards
[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 - Common Weakness Enumeration Top 25 2024 [18] CWE ID 863
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[10] 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)
[11] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[12] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[13] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-1
[14] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[15] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[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 Data Security Standard Version 4.0.1 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[28] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
desc.structural.javascript.html5_overly_permissive_message_posting_policy
Abstract
將 Referrer-Policy 標頭設定為 Unsafe-URL 可能導致應用程式將敏感網站與使用者資料 (包括階段作業權杖、使用者名稱和密碼) 洩漏給第三方網站。
Explanation
依預設,瀏覽器不會將包含來自 HTTPS 之要求的參照標頭傳送給未加密的 HTTP 連結。不過,如果要求目的地也是 HTTPS,則不論來源為何,都會傳送標頭。開發人員可能將敏感資訊留在 URL 中,這些 URL 會透過參照標頭而洩漏給第三方網站。引入 Referrer-Policy 標頭可控制與參照標頭相關的瀏覽器行為。Unsafe-URL 選項會移除所有限制,並傳送包含每個要求的參照標頭。

範例 1:以下程式碼會將受 Spring Security 保護的應用程式設定為停用預設的保護參照原則:

<http auto-config="true">
...
<headers>
...
<referrer-policy policy="unsafe-url"/>
</headers>
</http>
References
[1] Referrer-Policy
[2] OWASP OWASP Secure Headers Project
[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 - Common Weakness Enumeration Top 25 2024 [18] CWE ID 863
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002418, CCI-002420, CCI-002421, CCI-002422
[7] Standards Mapping - FIPS200 CM
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-8 Transmission Confidentiality and Integrity (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-8 Transmission Confidentiality and Integrity
[11] 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)
[12] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[13] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[17] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.10
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[30] 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
[31] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3250.1 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3250.1 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3250.1 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3250.1 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3250.1 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[53] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.config.java.html5_overly_permissive_referrer_policy
Abstract
內容安全性原則 (CSP) 是在監視模式下進行設定,因此瀏覽器不會強制執行。
Explanation
內容安全性原則 (CSP) 是一種宣告式安全性標頭,可讓開發人員指示在網頁瀏覽器中轉譯時,允許網站從哪些網域載入內容或起始到哪些網域的連線。除了程式碼中的輸入驗證和檢查允許清單外,它還提供額外一層的安全性,以防禦重要弱點,例如,Cross-Site Scripting、Clickjacking、Cross-Origin Access 等。

Content-Security-Policy-Report-Only 標頭為 Web 應用程式作者和管理員提供了監視安全性原則的功能,而不是強制執行原則。此標頭通常在實驗和/或開發網站的安全性原則時使用。當某原則被視為有效時,您可透過改用 Content-Security-Policy 標頭欄位來強制執行此原則。

範例 1:下列程式碼會在 Report-Only 模式中設定內容安全性原則:

<http auto-config="true">
...
<headers>
...
<content-security-policy report-only="true" policy-directives="default-src https://content.cdn.example.com" />
</headers>
</http>
References
[1] Mozilla Content Security Policy
[2] W3C Content Security Policy 2.0
[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 M1 Weak Server Side Controls
[8] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[9] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[10] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[11] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[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 - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 6.2 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.config.java.html5_unenforced_content_security_policy
Abstract
內容安全性原則 (CSP) 是在監視模式下進行設定,因此瀏覽器不會強制執行。
Explanation
內容安全性原則 (CSP) 是一種宣告式安全性標頭,可讓開發人員指示在網頁瀏覽器中轉譯時,允許網站從哪些網域載入內容或起始到哪些網域的連線。除了程式碼中的輸入驗證和檢查允許清單外,它還提供額外一層的安全性,以防禦重大漏洞,例如,Cross-Site Scripting、Clickjacking、Cross-Origin Access 等。

Content-Security-Policy-Report-Only 標頭為 Web 應用程式作者和管理員提供了監視安全性原則的功能,而不是強制執行原則。此標頭通常在實驗和/或開發網站的安全性原則時使用。當某原則視為有效時,您可以透過改用 Content-Security-Policy 標頭來強制執行此原則。

範例 1:以下程式碼將內容安全性原則設為 Report-Only 模式:

response.content_security_policy_report_only = "*"
References
[1] OWASP Content Security Policy
[2] W3C Content Security Policy 1.1
[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 M1 Weak Server Side Controls
[8] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[9] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[10] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[11] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[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 - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 6.2 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.structural.python.html5_unenforced_content_security_policy
Abstract
將未經驗證的輸入連結成 URL 可能讓攻擊者覆寫要求參數的值。攻擊者可能可以覆寫現有參數值,注入新的參數或者利用直接接觸得到的變數。
Explanation
HTTP Parameter Pollution (HPP)攻擊包含將編碼的字串限制字元注入其他現有參數。如果 Web 應用程式不能妥當清潔使用者輸入,惡意使用者可能危及應用程式邏輯,執行用戶端或伺服器端的攻擊。經由提交額外參數到網頁應用程式,且如果這些參數的名稱與現有參數相同,網頁應用程式可能以下列其中一種方式反應:

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


例如:
- ASP.NET/IIS 會使用所有出現的參數
- Apache Tomcat 僅使用第一個出現的參數並忽略其他位置出現的參數
- mod_perl/Apache 會將值轉換為一個值陣列

範例 1:根據應用程式伺服器及應用程式本身的邏輯而定,下列要求可能造成驗證系統的混淆,進而允許攻擊者模擬另一位使用者。
http://www.server.com/login.aspx?name=alice&name=hacker

範例 2:以下程式碼使用 HTTP 要求的輸入建立兩個超連結。

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


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

程式設計師沒有考慮到攻擊者可能會提供 lang (例如 en&poll_id=1) 的可能性,然後該攻擊者可能會隨意變更 poll_id
References
[1] HTTP Parameter Pollution Luca Carettoni, Independent Researcher & Stefano Di Paola, MindedSecurity
[2] HTTP Parameter Pollution Vulnerabilities in Web Applications Marco `embyte’ Balduzzi
[3] Standards Mapping - Common Weakness Enumeration CWE ID 235
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[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 API 2023 API1 Broken Object Level Authorization
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[13] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 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 4.2 APSC-DV-002560 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[44] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.dotnet.http_parameter_pollution
Abstract
將未經驗證的輸入連結成 URL 可能讓攻擊者覆寫要求參數的值。攻擊者可能可以覆寫現有參數值,注入新的參數或者利用直接接觸得到的變數。
Explanation
HTTP Parameter Pollution (HPP)攻擊包含將編碼的字串限制字元注入其他現有參數。如果 Web 應用程式不能妥當清潔使用者輸入,惡意使用者可能危及應用程式邏輯,執行用戶端或伺服器端的攻擊。經由提交額外參數到網頁應用程式,且如果這些參數的名稱與現有參數相同,網頁應用程式可能以下列其中一種方式反應:

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


例如:
- ASP.NET/IIS 會使用所有出現的參數
- Apache Tomcat 僅使用第一個出現的參數並忽略其他位置出現的參數
- mod_perl/Apache 會將值轉換為一個值陣列

範例 1:根據應用程式伺服器及應用程式本身的邏輯而定,下列要求可能造成驗證系統的混淆,進而允許攻擊者模擬另一位使用者。
http://www.example.com/login.php?name=alice&name=hacker

範例 2:以下程式碼使用 HTTP 要求的輸入建立兩個超連結。

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


URL: http://www.example.com?poll_id=4567
連結 1: <a href="001">English<a>
連結 2: <a href="002">Spanish<a>

程式設計師沒有考慮到攻擊者能夠提供 lang (例如 en&poll_id=1) 的可能性,然後該攻擊者可以隨意變更 poll_id
References
[1] HTTP Parameter Pollution Luca Carettoni, Independent Researcher & Stefano Di Paola, MindedSecurity
[2] HTTP Parameter Pollution Vulnerabilities in Web Applications Marco `embyte’ Balduzzi
[3] Standards Mapping - Common Weakness Enumeration CWE ID 235
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[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 API 2023 API1 Broken Object Level Authorization
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[13] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 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 4.2 APSC-DV-002560 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[44] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.http_parameter_pollution
Abstract
將未經驗證的輸入連結成 URL 可能讓攻擊者覆寫要求參數的值。攻擊者可能可以覆寫現有參數值,注入新的參數或者利用直接接觸得到的變數。
Explanation
HTTP Parameter Pollution (HPP)攻擊包含將編碼的字串限制字元注入其他現有參數。如果 Web 應用程式不能妥當清潔使用者輸入,惡意使用者可能危及應用程式邏輯,執行用戶端或伺服器端的攻擊。經由提交額外參數到網頁應用程式,且如果這些參數的名稱與現有參數相同,網頁應用程式可能以下列其中一種方式反應:

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


例如:
- ASP.NET/IIS 會使用所有出現的參數
- Apache Tomcat 僅使用第一個出現的參數並忽略其他位置出現的參數
- mod_perl/Apache 會將值轉換為一個值陣列

範例 1:根據應用程式伺服器及應用程式本身的邏輯而定,下列要求可能造成驗證系統的混淆,進而允許攻擊者模擬另一位使用者。
http://www.server.com/login.php?name=alice&name=hacker

範例 2:以下程式碼使用 HTTP 要求的輸入建立兩個超連結。


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


URL: http://www.host.com/election.php?poll_id=4567
連結 1: <a href="vote.php?poll_id=4567&candidate=white">Vote for Mr. White<a>
連結 2: <a href="vote.php?poll_id=4567&candidate=green">Vote for Mrs. Green<a>

程式設計師尚未考慮到攻擊者可能會提供 poll_id,例如「4567&candidate=green」,然後結果頁面中將含有下列注入的連結,因此 Mrs. Green 將一直由選取第一個參數的應用程式伺服器進行投票。
<a href="vote.php?poll_id=4567&candidate=green&candidate=white">Vote for Mr. White<a>
<a href="vote.php?poll_id=4567&candidate=green&candidate=green">Vote for Mrs. Green<a>
References
[1] HTTP Parameter Pollution Luca Carettoni, Independent Researcher & Stefano Di Paola, MindedSecurity
[2] HTTP Parameter Pollution Vulnerabilities in Web Applications Marco `embyte’ Balduzzi
[3] Standards Mapping - Common Weakness Enumeration CWE ID 235
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[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 API 2023 API1 Broken Object Level Authorization
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[13] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 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 4.2 APSC-DV-002560 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[44] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.php.http_parameter_pollution
Abstract
將未經驗證的輸入連結成 URL 可能讓攻擊者覆寫要求參數的值。攻擊者可能可以覆寫現有參數值,注入新的參數或者利用直接接觸得到的變數。
Explanation
HTTP Parameter Pollution (HPP)攻擊包含將編碼的字串限制字元注入其他現有參數。如果 Web 應用程式不能妥當清潔使用者輸入,惡意使用者可能危及應用程式邏輯,執行用戶端或伺服器端的攻擊。經由提交額外參數到網頁應用程式,且如果這些參數的名稱與現有參數相同,網頁應用程式可能以下列其中一種方式反應:

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


例如:
- ASP.NET/IIS 會使用所有出現的參數
- Apache Tomcat 僅使用第一個出現的參數並忽略其他位置出現的參數
- mod_perl/Apache 會將值轉換為一個值陣列

範例 1:根據應用程式伺服器及應用程式本身的邏輯而定,下列要求可能造成驗證系統的混淆,進而允許攻擊者模擬另一位使用者。
http://www.server.com/login.php?name=alice&name=hacker

如此所示,攻擊者已經指定 name=alice,但新增了其他 name=alice&,如果這是在第一次出現的伺服器上使用,則會模擬 alice 以便取得其帳戶的進一步資訊。
References
[1] HTTP Parameter Pollution Luca Carettoni, Independent Researcher & Stefano Di Paola, MindedSecurity
[2] HTTP Parameter Pollution Vulnerabilities in Web Applications Marco `embyte’ Balduzzi
[3] Standards Mapping - Common Weakness Enumeration CWE ID 235
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[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 API 2023 API1 Broken Object Level Authorization
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[13] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 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 4.2 APSC-DV-002560 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[44] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.ruby.http_parameter_pollution
Abstract
指定 HTTP 動詞的安全限制通常可允許比預期更大量的存取。
Explanation
在下列情況下,可使用 HTTP 動詞竄改來略過應用程式的 Authentication 和授權機制:
1) 該應用程式使用列出 HTTP 動詞的安全性控制。
2) 安全性控制無法封鎖未列出的動詞。
3) 應用程式根據 GET 要求或其他任意 HTTP 動詞來更新其狀態。



以下組態將易受 HTTP 動詞篡改的攻擊:

<authorization>
<allow verbs="GET,POST" users="admin"/>
<deny verbs="GET,POST"users="*" />
</authorization>

依預設,.NET Framework 允許所有 HTTP 動詞,因此即使此配置拒絕讓所有使用者存取 GET 和 POST,仍無法防止 HEAD 要求。攻擊者也許可透過以 HEAD 要求替代 GET 或 POST 要求,來執行管理功能。換句話說,此程式碼將滿足上述的條件 1 和 2。接著若要讓 HEAD 請求執行管理功能,則應用程式須依據使用 POST 以外的動詞的要求,來執行指令。

就其核心而言,此弱點是嘗試建立拒絕清單 (指示使用者不可進行之事項的原則) 的結果。拒絕清單很少達成預期的效果。
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 288, CWE ID 302
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [25] CWE ID 306
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[9] Standards Mapping - FIPS200 CM
[10] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[13] Standards Mapping - OWASP API 2023 API5 Broken Function Level Authorization
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[16] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[18] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.10
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.10
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.10
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[31] 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
[32] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
[49] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authentication
desc.config.dotnet.http_verb_tampering
Abstract
指定 HTTP 動詞的安全限制通常可允許比預期更大量的存取。
Explanation
在下列情況下,可使用 HTTP 動詞竄改來略過應用程式的 Authentication 和授權機制:
1) 該應用程式使用列出 HTTP 動詞的安全性控制。
2) 安全性控制無法封鎖未列出的動詞。
3) 應用程式根據 GET 要求或其他任意 HTTP 動詞來更新其狀態。



多數的 Java EE 執行允許組態中未明確列出的 HTTP 方法。例如,下列安全限制會套用至 HTTP GET 方法,但不會套用至其他 HTTP 動詞:


<security-constraint>
<display-name>Admin Constraint</display-name>
<web-resource-collection>
<web-resource-name>Admin Area</web-resource-name>
<url-pattern>/pages/index.jsp</url-pattern>
<url-pattern>/admin/*.do</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<description>only admin</description>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>


由於此組態的 <http-method> 標籤中未明確定義如 HEAD 的動詞,因此可透過以 HEAD 要求替代 GET 或 POST 要求,來執行管理功能。為了能讓 HEAD 要求執行管理功能,條件 3 必須適用 - 應用程式必須依據 POST 以外的動詞執行指令。某些網路/應用程式伺服器會接受任意的非標準 HTTP 動詞,並以具有指定 GET 要求的型態回應。若情況為此,攻擊者將可使用要求中的任意動詞,來檢視管理頁面。

例如,典型的用戶端 GET 要求範例如下:

GET /admin/viewUsers.do HTTP/1.1
Host: www.example.com


在 HTTP 動詞竄改攻擊中,攻擊者會以與 FOO 同類的要求替代 GET。

FOO /admin/viewUsers.do HTTP/1.1
Host: www.example.com


就其核心而言,此弱點是嘗試建立拒絕清單 (指示使用者不可進行之事項的原則) 的結果。拒絕清單很少達成預期的效果。
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 288, CWE ID 302
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [25] CWE ID 306
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[9] Standards Mapping - FIPS200 CM
[10] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[13] Standards Mapping - OWASP API 2023 API5 Broken Function Level Authorization
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[16] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[18] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.10
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.10
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.10
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[31] 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
[32] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
[49] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authentication
desc.config.java.http_verb_tampering
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 Data Security Standard Version 4.0.1 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
[31] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
desc.structural.java.immutable_field_mutation