界: Input Validation and Representation

輸入驗證和表示法問題是由中繼字元、替代編碼和數值表示法引起的。信任輸入會導致安全問題。問題包括:「Buffer Overflows」、「Cross-Site Scripting」攻擊、「SQL Injection」及其他許多問題。

175 找到的項目
弱點
Abstract
接受使用者提供的資料做為 apex:iframe 來源 URL 可能會導致在 Visualforce 頁面內載入惡意內容。
Explanation
框架欺騙弱點會在以下情況中出現:

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

2. 此資料將用作 iframe URL,且無需進行驗證。

這樣一來,攻擊者可能會控制將轉譯成內嵌框架的內容。透過修改框架 URL 以指向惡意網站,可能會嘗試執行釣魚攻擊來竊取使用者資訊 (包括認證或其他敏感資料)。假設基礎網域可以信任 - Salesforce.com,受害者將信任該頁面並提供所有要求的資訊。

範例 1:在以下程式碼範例中,iframesrc URL 參數將直接用作 apex:iframe 目標 URL。

<apex:page>
<apex:iframe src="{!$CurrentPage.parameters.iframesrc}"></apex:iframe>
</apex:page>


這樣一來,如果攻擊者為受害者提供設為惡意網站的 iframesrc 參數,則框架將使用惡意網站的內容進行轉譯。

<iframe src="http://evildomain.com/">
References
[1] Ryan C. Barnett Content Spoofing - TechTarget
[2] Salesforce Developers Technical Library Secure Coding Guidelines
desc.dataflow.apex.frame_spoofing
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);
...
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]);
...
}
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();

}
desc.dataflow.java.hadoop_job_manipulation
Abstract
Handlebars 範本中停用了逸出,這可能導致多個新漏洞。
Explanation
Handlebars 範本中執行的預設逸出,有助於保護應用程式免於攻擊者的攻擊。這可以防止跨不同類型漏洞的許多攻擊途徑。其中最顯著的保護機制是防範特定類型的 Cross-site scripting 攻擊。在此應用程式中,此保護機制遭到明確停用。

範例 1:以下範例顯示停用了 Handlebars 範本逸出。

let template = Handlebars.compile('{{foo}}', { noEscape: true })
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.5
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark complete
[6] Standards Mapping - Common Weakness Enumeration CWE ID 554
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[10] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[11] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] 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 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 - 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)
[23] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[24] Standards Mapping - OWASP Mobile 2024 M8 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.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 3.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.javascript.handlebars_misconfiguration_escaping_disabled
Abstract
Handlebars 範本中允許使用原型,會製造利用 Prototype Pollution 漏洞的機會。
Explanation
Handlebars 範本無法存取物件的原型,因為它讓應用程式容易受到 Prototype Pollution 攻擊。

當惡意使用者可以控制物件原型上的功能或屬性時,就會發生 Prototype Pollution 攻擊。控制傳遞到範本中的物件原型會導致許多漏洞,包括 Dynamic Code Evaluation、Cross-Site Scripting 和 Remote Code Execution。

範例 1:在以下設定 Handlebars 範本的範例中,依預設允許使用原型方法,以及特殊的 __defineGetter__ 函式。

let template2 = Handlebars.compile('{{foo}}')
console.log(template2({ foo: argument }, {
allowProtoMethodsByDefault: true,
allowedProtoMethods: {
__defineGetter__: true
}
}))
References
[1] Handlebars Runtime Options: Options to Control Prototype Access Handlebars
[2] Mahmoud Gamal Handlebars template injection and RCE in a Shopify app
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.5
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[7] Standards Mapping - CIS Kubernetes Benchmark complete
[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 - 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 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 - 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)
[25] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[26] Standards Mapping - OWASP Mobile 2024 M8 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.2 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[36] 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
[37] 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
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 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 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 5.1 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.structural.javascript.handlebars_misconfiguration_prototypes_allowed
Abstract
在 HTTP 回應表頭中包含未經驗證的資料會導致 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect 攻擊。
Explanation
Header Manipulation 弱點會在以下情況中出現:

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

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

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

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

現今許多先進的應用程式伺服器可防止將惡意字元插入 HTTP 表頭。如果應用程式伺服器可防止使用新行的字元來設定表頭,則您的應用程式對於 HTTP Response Splitting 的攻擊,具有一定的防禦能力。但是,僅篩選新行的字元,應用程式可能仍對 Cookie Manipulation 或 Open Redirects 攻擊無招架能力,所以透過使用者輸入設定 HTTP 表頭時,仍需特別注意。

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


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


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


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


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


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

HTTP/1.1 200 OK
...


很明顯的,第二個回應完全被攻擊者所控制,並且能使用任何標頭和想要的正文內容來建構。攻擊者可以建構任何 HTTP 回應,並造成不同的攻擊結果,這些攻擊包括:跨用戶塗改、網頁和瀏覽器快取記憶體下毒、Cross-site scripting 和網頁劫持。

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

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

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

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

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

Open Redirect: 允許未經驗證的輸入來控制重新導向中使用的 URL,如此會助長網路釣魚的攻擊。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
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
desc.dataflow.apex.header_manipulation
Abstract
在 HTTP 回應表頭中包含未經驗證的資料會導致 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect 攻擊。
Explanation
Header Manipulation 弱點會在以下情況中出現:

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

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

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

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

現今許多先進的應用程式伺服器與框架都可避免惡意字元插入 HTTP 表頭中。舉例來說、Microsoft .NET 框架的最新版本可將 CR、LF 與 NULL 字元在傳送至 HttpResponse.AddHeader() 方法時,將其轉換成 %0d、%0a 與 %00。如果您使用了可避免使用新行字元設定表頭的最新版.NET 框架,您的應用程式可能就可以抵擋 HTTP Response Splitting 攻擊。但是,僅篩選新行的字元,應用程式可能仍對 Cookie Manipulation 或 Open Redirects 攻擊無招架能力,所以透過使用者輸入設定 HTTP 表頭時,仍需特別注意。

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


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


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


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


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


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

HTTP/1.1 200 OK
...


很明顯的,第二個回應完全被攻擊者所控制,並且能使用任何標頭和想要的正文內容來建構。攻擊者可以建構任何 HTTP 回應,並造成不同的攻擊結果,這些攻擊包括:跨用戶塗改、網頁和瀏覽器快取記憶體下毒、Cross-site scripting 和網頁劫持。

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

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

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

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

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

開放式重新導向:允許未經驗證的輸入來控制重新導向中使用的 URL,如此會助長網路釣魚攻擊。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
desc.dataflow.dotnet.header_manipulation
Abstract
在 HTTP 回應表頭中包含未經驗證的資料會導致 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement 或 Page Hijacking 攻擊。
Explanation
Header Manipulation 弱點會在以下情況中出現:

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

2. 在未驗證包含資料的 HTTP 回應表頭是否存在惡意特徵的情況下,便將其傳送給某個網頁使用者。

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

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

現今許多先進的應用程式伺服器可防止將惡意字元插入 HTTP 表頭。如果應用程式伺服器可防止使用新行的字元來設定表頭,則您的應用程式對於 HTTP Response Splitting 的攻擊,具有一定的防禦能力。但是,僅篩選新行的字元,應用程式可能仍對 Cookie Manipulation 或 Open Redirects 攻擊無招架能力,所以透過使用者輸入設定 HTTP 表頭時,仍需特別注意。

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


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

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


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


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


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


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

HTTP/1.1 200 OK
...


很明顯的,第二個回應完全被攻擊者所控制,並且能使用任何標頭和想要的正文內容來建構。攻擊者可以建構任何 HTTP 回應,並造成不同的攻擊結果,這些攻擊包括:跨用戶塗改、網頁和瀏覽器快取記憶體下毒、Cross-site scripting 和網頁劫持。

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

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

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

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

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

Open Redirect: 允許未經驗證的輸入來控制重新導向中使用的 URL,如此會助長網路釣魚的攻擊。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
desc.dataflow.cobol.header_manipulation
Abstract
在 HTTP 回應表頭中包含未經驗證的資料會導致 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect 攻擊。
Explanation
Header Manipulation 弱點會在以下情況中出現:

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

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

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

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

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

範例: 以下的程式碼片段是從網路表單中讀取網誌項目的作者名字 author,並且在 HTTP 回應的 cookie 表頭中設定。


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


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


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


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


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

HTTP/1/1 200 OK
...


很明顯的,第二個回應完全被攻擊者所控制,並且能使用任何標頭和想要的正文內容來建構。攻擊者可以建構任何 HTTP 回應,並造成不同的攻擊結果,這些攻擊包括:跨用戶塗改、網頁和瀏覽器快取記憶體下毒、Cross-site scripting 和網頁劫持。

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

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

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

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

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

Open Redirect: 允許未經驗證的輸入來控制重新導向中使用的 URL,如此會助長網路釣魚的攻擊。
References
[1] Amit Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] Diabolic Crab HTTP Response Splitting
desc.dataflow.cfml.header_manipulation
Abstract
在 HTTP 回應標頭中包含未經驗證的資料會引發 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect 攻擊。
Explanation
Header Manipulation 弱點會在以下情況中出現:

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

2.HTTP 回應標頭包含的資料在未經驗證的情況下便傳送給 Web 使用者。

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

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

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

範例:以下程式碼片段會讀取 HTTP 要求中的 'content-type',並將其設定在新 HTTP 要求的標頭中。


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


由於 'Content-Type' 標頭的值由未經驗證的使用者輸入所構成,因此惡意動作執行者可以操縱它來利用漏洞、執行 Code Injection 攻擊、暴露敏感資料、啟用惡意檔案執行或觸發 Denial of Service 情況,從而對應用程式的安全性和穩定性構成重大風險。
desc.dataflow.dart.header_manipulation
Abstract
在 HTTP 回應標頭中包含未經驗證的資料會引發 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect 攻擊。
Explanation
Header Manipulation 弱點會在以下情況中出現:

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

2.HTTP 回應標頭包含的資料在未經驗證的情況下便傳送給 Web 使用者。

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


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


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


攻擊者可以建構任何 HTTP 回應,並造成不同的攻擊結果,這些攻擊包括:Cross-user Defacement, Web and Browser Cache Poisoning, Cross-site Scripting 和 Page Hijacking。

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

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

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

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

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

Open Redirect:允許未經驗證的輸入控制重新導向中所使用的 URL,有助於網路釣魚攻擊。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
desc.dataflow.golang.header_manipulation
Abstract
在 HTTP 回應表頭中包含未經驗證的資料會導致 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect 攻擊。
Explanation
Header Manipulation 弱點會在以下情況中出現:

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

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

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

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

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

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


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


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


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


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


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

HTTP/1.1 200 OK
...


很明顯的,第二個回應完全被攻擊者所控制,並且能使用任何標頭和想要的正文內容來建構。攻擊者可以建構任何 HTTP 回應,並造成不同的攻擊結果,這些攻擊包括:跨用戶塗改、網頁和瀏覽器快取記憶體下毒、Cross-site scripting 和網頁劫持。

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

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

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

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

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

Open Redirect: 允許未經驗證的輸入來控制重新導向中使用的 URL,如此會助長網路釣魚的攻擊。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
desc.dataflow.java.header_manipulation
Abstract
在 HTTP 回應表頭中包含未經驗證的資料會導致 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect 攻擊。
Explanation
Header Manipulation 弱點會在以下情況中出現:

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

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

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

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

現今許多先進的應用程式伺服器可防止將惡意字元插入 HTTP 表頭。如果應用程式伺服器可防止使用新行的字元來設定表頭,則您的應用程式對於 HTTP Response Splitting 的攻擊,具有一定的防禦能力。但是,僅篩選新行的字元,應用程式可能仍對 Cookie Manipulation 或 Open Redirects 攻擊無招架能力,所以透過使用者輸入設定 HTTP 表頭時,仍需特別注意。

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


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


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


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


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


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

HTTP/1.1 200 OK
...


很明顯的,第二個回應完全被攻擊者所控制,並且能使用任何標頭和想要的正文內容來建構。攻擊者可以建構任何 HTTP 回應,並造成不同的攻擊結果,這些攻擊包括:網頁與瀏覽器 Cache Poisoning、Cross-site Scripting 和 Page Hijacking。


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

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

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

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

Open Redirect: 允許未經驗證的輸入來控制重新導向中使用的 URL,如此會助長網路釣魚的攻擊。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
desc.dataflow.javascript.header_manipulation
Abstract
在 HTTP 回應表頭中包含未經驗證的資料會導致 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect 攻擊。
Explanation
Header Manipulation 弱點會在以下情況中出現:

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


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

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

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

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

範例:以下程式碼片段假設 namevalue 可能會被攻擊者控制。此程式碼會設定一個名稱和值可能被攻擊者控制的 HTTP 標頭。


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


假設名稱/值組由 authorJane Smith 組成,則包含此標頭的 HTTP 回應可能會採用以下形式:


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


不過,由於標頭的值是由未經驗證的使用者輸入而得來,攻擊者可能會提交惡意的名稱/值組 (例如 HTTP/1.1 200 OK\r\n...foobar),然後 HTTP 回應將分割為以下形式的兩種回應:


HTTP/1.1 200 OK
...

HTTP/1.1 200 OK
...
foo:bar


很明顯的,第二個回應完全被攻擊者所控制,並且能使用任何標頭和想要的正文內容來建構。攻擊者可以建構任何 HTTP 回應,並造成不同的攻擊結果,這些攻擊包括:跨用戶塗改、網頁和瀏覽器快取記憶體下毒、Cross-site scripting 和網頁劫持。

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

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

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

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

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

開放式重新導向:允許未經驗證的輸入來控制重新導向中使用的 URL,如此會助長網路釣魚攻擊。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
desc.dataflow.objc.header_manipulation
Abstract
在 HTTP 回應表頭中包含未經驗證的資料會導致 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect 攻擊。
Explanation
Header Manipulation 弱點會在以下情況中出現:

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

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

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

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

現今許多先進的應用程式伺服器可防止將惡意字元插入 HTTP 表頭。舉例而言,最新版的 PHP 在新行傳送 header() 至函數時,將會產生警告並停止建立表頭。如果您的 PHP 版本無法使用新行字元設定表頭,您的應用程式可能就可以抵擋 HTTP Response Splitting 攻擊。但是,僅篩選新行的字元,應用程式可能仍對 Cookie Manipulation 或 Open Redirects 攻擊無招架能力,所以透過使用者輸入設定 HTTP 表頭時,仍需特別注意。

範例:以下程式碼片段會讀取 HTTP 要求中的位置,並在 HTTP 回應的表頭位置欄位中設定該位置。


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


假設在要求中提交了一個由標準英數字元所組成的字串,如「index.html」,那麼包含這個 Cookie 的 HTTP 回應可能會以下列形式表示:


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


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


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

HTTP/1.1 200 OK
...


很明顯的,第二個回應完全被攻擊者所控制,並且能使用任何標頭和想要的正文內容來建構。攻擊者可以建構任何 HTTP 回應,並造成不同的攻擊結果,這些攻擊包括:跨用戶塗改、網頁和瀏覽器快取記憶體下毒、Cross-site scripting 和網頁劫持。

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

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

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

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

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

Open Redirect: 允許未經驗證的輸入來控制重新導向中使用的 URL,如此會助長網路釣魚的攻擊。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
desc.dataflow.php.header_manipulation
Abstract
在 HTTP 回應表頭中包含未經驗證的資料會導致 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect 攻擊。
Explanation
Header Manipulation 弱點會在以下情況中出現:

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

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

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

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

現今許多先進的應用程式伺服器可防止將惡意字元插入 HTTP 表頭。如果應用程式伺服器可防止使用新行的字元來設定表頭,則您的應用程式對於 HTTP Response Splitting 的攻擊,具有一定的防禦能力。但是,僅篩選新行的字元,應用程式可能仍對 Cookie Manipulation 或 Open Redirects 攻擊無招架能力,所以透過使用者輸入設定 HTTP 表頭時,仍需特別注意。

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


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


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


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


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


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

HTTP/1.1 200 OK
...


很明顯的,第二個回應完全被攻擊者所控制,並且能使用任何標頭和想要的正文內容來建構。攻擊者可以建構任何 HTTP 回應,並造成不同的攻擊結果,這些攻擊包括:跨用戶塗改、網頁和瀏覽器快取記憶體下毒、Cross-site scripting 和網頁劫持。

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

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

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

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

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

開放式重新導向:允許未經驗證的輸入來控制重新導向中使用的 URL,如此會助長網路釣魚攻擊。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
desc.dataflow.sql.header_manipulation
Abstract
在 HTTP 回應表頭中包含未經驗證的資料會導致 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect 攻擊。
Explanation
Header Manipulation 弱點會在以下情況中出現:

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

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

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

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

現今許多先進的應用程式伺服器可防止將惡意字元插入 HTTP 表頭。如果應用程式伺服器可防止使用新行的字元來設定表頭,則您的應用程式對於 HTTP Response Splitting 的攻擊,具有一定的防禦能力。但是,僅篩選新行的字元,應用程式可能仍對 Cookie Manipulation 或 Open Redirects 攻擊無招架能力,所以透過使用者輸入設定 HTTP 表頭時,仍需特別注意。

範例:以下程式碼片段會讀取 HTTP 要求中的位置,並在 HTTP 回應的位置欄位表頭中設定該位置。


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


假設在要求中提交了一個由標準英數字元所組成的字串,如「index.html」,那麼包含這個 Cookie 的 HTTP 回應可能會以下列形式表示:


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


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


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

HTTP/1.1 200 OK
...


很明顯的,第二個回應完全被攻擊者所控制,並且能使用任何標頭和想要的正文內容來建構。攻擊者可以建構任何 HTTP 回應,並造成不同的攻擊結果,這些攻擊包括:跨用戶塗改、網頁和瀏覽器快取記憶體下毒、Cross-site scripting 和網頁劫持。

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

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

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

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

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

Open Redirect: 允許未經驗證的輸入來控制重新導向中使用的 URL,如此會助長網路釣魚的攻擊。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
desc.dataflow.python.header_manipulation
Abstract
在 HTTP 回應表頭中包含未經驗證的資料會導致 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect 攻擊。
Explanation
Header Manipulation 弱點會在以下情況中出現:

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

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

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

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

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

範例:以下程式碼區段會從 HTTP 要求中讀取網路部落格項目的作者名稱 (author),並且將此名稱用於網站其他部分的 GET 要求中。


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


假設在要求中提交了一個由標準英數字元所組成的字串,如「Jane Smith」,那麼 HTTP 回應可能會表現為以下形式:


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


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


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

POST /index.php HTTP/1.1
...


很明顯的,第二個回應完全被攻擊者所控制,並且能使用任何標頭和想要的正文內容來建構。攻擊者可以建構任何 HTTP 回應,並造成不同的攻擊結果,這些攻擊包括:跨用戶塗改、網頁和瀏覽器快取記憶體下毒、Cross-site scripting 和網頁劫持。

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

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

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

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

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

Open Redirect: 允許未經驗證的輸入來控制重新導向中使用的 URL,如此會助長網路釣魚的攻擊。
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
desc.dataflow.scala.header_manipulation
Abstract
在 HTTP 回應表頭中包含未經驗證的資料會導致 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect 攻擊。
Explanation
Header Manipulation 弱點會在以下情況中出現:

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


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

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

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

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

範例:以下程式碼片段假設 namevalue 可能會被攻擊者控制。此程式碼會設定一個名稱和值可能被攻擊者控制的 HTTP 標頭。


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


假設名稱/值組由 authorJane Smith 組成,則包含此標頭的 HTTP 回應可能會採用以下形式:


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


不過,由於標頭的值是由未經驗證的使用者輸入而得來,攻擊者可能會提交惡意的名稱/值組 (例如 HTTP/1.1 200 OK\r\n...foobar),然後 HTTP 回應將分割為以下形式的兩種回應:


HTTP/1.1 200 OK
...

HTTP/1.1 200 OK
...
foo:bar


很明顯的,第二個回應完全被攻擊者所控制,並且能使用任何標頭和想要的正文內容來建構。攻擊者可以建構任何 HTTP 回應,並造成不同的攻擊結果,這些攻擊包括:跨用戶塗改、網頁和瀏覽器快取記憶體下毒、Cross-site scripting 和網頁劫持。

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

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

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

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

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

開放式重新導向:允許未經驗證的輸入來控制重新導向中使用的 URL,如此會助長網路釣魚攻擊。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
desc.dataflow.swift.header_manipulation
Abstract
在 HTTP 回應表頭中包含未經驗證的資料會導致 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect 攻擊。
Explanation
Header Manipulation 弱點會在以下情況中出現:

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

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

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

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

現今許多先進的應用程式伺服器與框架都可避免惡意字元插入 HTTP 表頭中,但是支援典型 ASP 的伺服器通常沒有這項保護機制。

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


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


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


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


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


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

HTTP/1.1 200 OK
...


很明顯的,第二個回應完全被攻擊者所控制,並且能使用任何標頭和想要的正文內容來建構。攻擊者可以建構任何 HTTP 回應,並造成不同的攻擊結果,這些攻擊包括:跨用戶塗改、網頁和瀏覽器快取記憶體下毒、Cross-site scripting 和網頁劫持。

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

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

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

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

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

開放式重新導向:允許未經驗證的輸入來控制重新導向中使用的 URL,如此會助長網路釣魚攻擊。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
desc.dataflow.vb.header_manipulation