界: Input Validation and Representation

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

175 找到的項目
弱點
Abstract
在 Cookie 中包含未經驗證的資料會導致 HTTP 回應 Header manipulation,並引發 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect。
Explanation
Cookie Manipulation 弱點會在以下情況中出現:

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

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

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

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

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

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

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

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


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


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


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


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


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

HTTP/1.1 200 OK
...


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

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

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

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

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

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

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



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



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

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

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

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

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

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


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


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


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


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


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

HTTP/1.1 200 OK
...


很明顯,第二個回應完全受到攻擊者所控制,而且可以使用所需的任何標頭和本文內容來建構。攻擊者可以建構任何 HTTP 回應,並造成不同的攻擊結果,這些攻擊包括:Cross-user Defacement、Web and Browser Cache Poisoning、Cross-site Scripting 和 Page Hijacking。

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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


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


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


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

HTTP/1.1 200 OK
...


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

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

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

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

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

開放式重新導向:允許未經驗證的輸入來控制重新導向中使用的 URL,如此會助長網路釣魚攻擊。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.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 3.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.dotnet.header_manipulation_cookies
Abstract
在 Cookie 中包含未經驗證的資料會導致 HTTP 回應 Header manipulation,並引發 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect。
Explanation
Cookie Manipulation 弱點會在以下情況中出現:

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

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

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

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

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

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

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

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


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


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


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


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


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

HTTP/1.1 200 OK
...


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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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


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


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


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

HTTP/1.1 200 OK
...


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

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

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

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

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

Open Redirect:允許未經驗證的輸入控制重新導向中所使用的 URL,有助於網路釣魚攻擊。
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 113
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[9] Standards Mapping - FIPS200 SI
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[20] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[21] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.2 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 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 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 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 5.1 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 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.golang.header_manipulation_cookies
Abstract
在 Cookie 中包含未經驗證的資料會導致 HTTP 回應 Header manipulation,並引發 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect。
Explanation
Cookie Manipulation 弱點會在以下情況中出現:

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

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

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

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

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

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

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

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


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


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


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


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


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

HTTP/1.1 200 OK
...


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

有人認為在行動環境中,典型的 Web 應用程式弱點 (例如 Header Manipulation 與 Cookie Manipulation) 不會產生影響,因為使用者為何會攻擊自己呢?但是請謹記,行動平台的本質是從多種來源下載,並在相同裝置上一起執行的應用程式。在金融應用程式旁執行惡意程式碼的可能性很高,這必然會擴大行動應用程式的受攻擊面,將程序之間的通訊包括在內。

範例 2:以下程式碼改寫 Example 1 以適用於 Android 平台。


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

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

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

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

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

Open Redirect: 允許未經驗證的輸入來控制重新導向中使用的 URL,如此會助長網路釣魚的攻擊。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.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 3.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.java.header_manipulation_cookies
Abstract
在 Cookie 中包含未經驗證的資料會導致 HTTP 回應 Header manipulation,並引發 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect。
Explanation
Cookie Manipulation 弱點會在以下情況中出現:

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

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

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

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

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

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

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

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


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


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


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


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


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

HTTP/1.1 200 OK
...


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

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

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

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

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

Open Redirect: 允許未經驗證的輸入來控制重新導向中使用的 URL,如此會助長網路釣魚的攻擊。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.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 3.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.javascript.header_manipulation_cookies
Abstract
在 Cookie 中包含未經驗證的資料會導致 HTTP 回應 Header manipulation,並引發 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect。
Explanation
Cookie Manipulation 弱點會在以下情況中出現:

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

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

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

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

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

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

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

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


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


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


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


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


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

HTTP/1.1 200 OK
...


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

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

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

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

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

Open Redirect: 允許未經驗證的輸入來控制重新導向中使用的 URL,如此會助長網路釣魚的攻擊。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.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 3.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.php.header_manipulation_cookies
Abstract
在 HTTP 回應表頭中包含未經驗證的資料會導致 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect 攻擊。
Explanation
Header Manipulation 弱點會在以下情況中出現:

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

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

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

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

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

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


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


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


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


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


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

HTTP/1.1 200 OK
...


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

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

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

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

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

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

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

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

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

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

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

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

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

現今許多先進的應用程式伺服器可防止將惡意字元插入 HTTP 標頭。 舉例來說,如果您嘗試使用禁用的字元設定標頭,最新版的 Apache Tomcat 會拋出 IllegalArgumentException。 如果應用程式伺服器可防止使用換行字元來設定標頭,則您的應用程式面對 HTTP Response Splitting 的攻擊,具有一定的防禦能力。 但是,僅篩選換行字元,應用程式可能仍對 Cookie Manipulation 或 Open Redirect 攻擊無招架能力,所以透過使用者輸入設定 HTTP 標頭時,仍需特別注意。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.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 3.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.scala.header_manipulation_cookies
Abstract
在 Cookie 中包含未經驗證的資料會導致 HTTP 回應 Header manipulation,並引發 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect。
Explanation
Cookie Manipulation 弱點會在以下情況中出現:

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

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

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

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

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

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

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

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


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


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


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


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


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

HTTP/1.1 200 OK
...


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

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

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

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

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

開放式重新導向:允許未經驗證的輸入來控制重新導向中使用的 URL,如此會助長網路釣魚攻擊。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.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 3.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.vb.header_manipulation_cookies
Abstract
將未驗證的資料包含在 SMTP 表頭中,會讓攻擊者新增如 CCBCC 等任意表頭,這些表頭可用於將郵件內容洩漏給他們自己,或將郵件伺服器用作垃圾郵件機器人。
Explanation
SMTP Header Manipulation 弱點會在以下情況中出現:

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

2.SMTP 表頭中包含的資料未經驗證便傳送給郵件伺服器。

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

最常見的一種 SMTP Header Manipulation 攻擊是散發垃圾電子郵件。如果應用程式包含一個易受攻擊的「聯絡我們」表單,該表單允許設定電子郵件的主旨和內文,則從受害者伺服器傳送電子郵件之後,攻擊者即可設定任意內容,並注入包含電子郵件地址清單的 CC 表頭以匿名散發垃圾郵件。

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


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


假設在要求中提交一個由標準英數字元所組成的字串,如「Page not working」,那麼 SMTP 表頭可能會採用下列形式:


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


不過,因為表頭的值是根據未經驗證的使用者輸入建構的,所以只有當提交給 subject 的值不包含任何 CR 和 LF 字元時,回應才會保留這種形式。如果攻擊者提交惡意字串,例如「Congratulations!! You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ...」,SMTP 表頭可能會採用以下形式:


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


這實際上會讓攻擊者能修改垃圾郵件或在其他攻擊中傳送匿名電子郵件。
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.1
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark complete
[8] Standards Mapping - Common Weakness Enumeration CWE ID 93
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[15] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[16] Standards Mapping - OWASP Top 10 2010 A1 Injection
[17] Standards Mapping - OWASP Top 10 2013 A1 Injection
[18] Standards Mapping - OWASP Top 10 2017 A1 Injection
[19] Standards Mapping - OWASP Top 10 2021 A03 Injection
[20] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[21] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[22] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.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 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.golang.header_manipulation_smtp
Abstract
將未驗證的資料包含在 SMTP 表頭中,會讓攻擊者新增如 CCBCC 任意表頭,攻擊者可使用這些表頭將郵件內容洩漏給他們自己,或將郵件伺服器用作垃圾郵件機器人。
Explanation
SMTP Header Manipulation 弱點會在以下情況中出現:

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

2. SMTP 表頭中包含的資料未經驗證便傳送給郵件伺服器。

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

最常見的一種 SMTP Header Manipulation 攻擊,是用於散發垃圾電子郵件。如果應用程式包含一個易受攻擊的「聯絡我們」表單,該表單允許設定電子郵件的主旨和內文,則從受害者伺服器傳送電子郵件之後,攻擊者即可設定任意內容,並注入包含電子郵件地址清單的 CC 標頭以匿名散發垃圾郵件。

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


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


假設在要求中提交一個由標準英數字元所組成的字串,如「Page not working」,那麼 SMTP 表頭可能會採用下列形式:


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


不過,因為表頭的值是由未經驗證的使用者輸入建構,所以只有當為 subject 提交的值不包含任何 CR 和 LF 字元,回應才會保留這種形式。如果攻擊者提交惡意字串,例如「Congratulations!!You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ...」,SMTP 表頭可能會採用以下形式:


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


這將有效允許攻擊者修改垃圾郵件或在其他攻擊中傳送匿名電子郵件。
References
[1] OWASP Testing for IMAP/SMTP Injection (OTG-INPVAL-011)
[2] Vicente Aguilera Díaz MX Injection: Capturing and Exploiting Hidden Mail Servers
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.1
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - CIS Kubernetes Benchmark complete
[10] Standards Mapping - Common Weakness Enumeration CWE ID 93
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[12] Standards Mapping - FIPS200 SI
[13] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[17] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A03 Injection
[22] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.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 Abuse of Functionality (WASC-42)
desc.dataflow.java.header_manipulation_smtp
Abstract
Including unvalidated data in an SMTP header can enable attackers to add arbitrary headers, such as CC or BCC that they can use to leak the mail contents to themselves or use the mail server as a spam bot.
Explanation
SMTP Header Manipulation 弱點會在以下情況中出現:

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

2. SMTP 表頭中包含的資料未經驗證便傳送給郵件伺服器。

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

常見的 SMTP Header Manipulation 攻擊之一就是散佈垃圾郵件。如果應用程式包含一個易受攻擊的「聯絡我們」表單,該表單允許設定電子郵件的主旨和內文,則從受害者伺服器傳送電子郵件之後,攻擊者即可設定任意內容,並插入包含電子郵件地址清單的 CC 表頭以匿名散發垃圾郵件。

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


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


假設在要求中提交一個由標準英數字元所組成的字串,如「Page not working」,那麼 SMTP 表頭可能會採用下列形式:


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


不過,因為表頭的值是由未經驗證的使用者輸入建構,所以只有當為 subject 提交的值不包含任何 CR 和 LF 字元,回應才會保留這種形式。如果攻擊者提交惡意字串,例如「Congratulations!!You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ...」,SMTP 表頭可能會採用以下形式:


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


這將有效允許攻擊者修改垃圾郵件或在其他攻擊中傳送匿名電子郵件。
References
[1] OWASP Testing for IMAP/SMTP Injection (OTG-INPVAL-011)
[2] Vicente Aguilera Díaz MX Injection: Capturing and Exploiting Hidden Mail Servers
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.1
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - CIS Kubernetes Benchmark complete
[10] Standards Mapping - Common Weakness Enumeration CWE ID 93
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[12] Standards Mapping - FIPS200 SI
[13] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[17] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A03 Injection
[22] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.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 Abuse of Functionality (WASC-42)
desc.dataflow.php.header_manipulation_smtp
Abstract
Including unvalidated data in an SMTP header can enable attackers to add arbitrary headers, such as CC or BCC that they can use to leak the mail contents to themselves or use the mail server as a spam bot.
Explanation
SMTP Header Manipulation 弱點會在以下情況中出現:

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

2. SMTP 表頭中包含的資料未經驗證便傳送給郵件伺服器。

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

常見的 SMTP Header Manipulation 攻擊之一就是散佈垃圾郵件。如果應用程式包含一個易受攻擊的「聯絡我們」表單,該表單允許設定電子郵件的主旨和內文,則從受害者伺服器傳送電子郵件之後,攻擊者即可設定任意內容,並插入包含電子郵件地址清單的 CC 表頭以匿名散發垃圾郵件。

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


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


假設在要求中提交一個由標準英數字元所組成的字串,如「Page not working」,那麼 SMTP 表頭可能會採用下列形式:


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


不過,因為表頭的值是由未經驗證的使用者輸入建構,所以只有當為 subject 提交的值不包含任何 CR 和 LF 字元,回應才會保留這種形式。如果攻擊者提交惡意字串,例如「Congratulations!!You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ...」,SMTP 表頭可能會採用以下形式:


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


這將有效允許攻擊者修改垃圾郵件或在其他攻擊中傳送匿名電子郵件。
References
[1] OWASP Testing for IMAP/SMTP Injection (OTG-INPVAL-011)
[2] Vicente Aguilera Díaz MX Injection: Capturing and Exploiting Hidden Mail Servers
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.1
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - CIS Kubernetes Benchmark complete
[10] Standards Mapping - Common Weakness Enumeration CWE ID 93
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[12] Standards Mapping - FIPS200 SI
[13] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[17] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A03 Injection
[22] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.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 Abuse of Functionality (WASC-42)
desc.dataflow.python.header_manipulation_smtp
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 - CIS Azure Kubernetes Service Benchmark 3.5
[8] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[9] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[10] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[11] Standards Mapping - CIS Kubernetes Benchmark complete
[12] Standards Mapping - Common Weakness Enumeration CWE ID 554, CWE ID 1173
[13] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[14] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[15] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[16] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[17] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[18] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[19] Standards Mapping - FIPS200 CM
[20] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[21] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[22] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[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 - 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)
[29] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[30] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[40] 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
[41] 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
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.configuration.dotnet.html5_xss_protection
Abstract
X-XSS-Protection 標頭已明確停用,這可能會增加 Cross-Site Scripting 攻擊的風險。
Explanation
在現代瀏覽器中,通常預設啟用 X-XSS-Protection 標頭。設定標頭值為 false (0) 時,會停用 Cross-Site Scripting 保護。

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

範例:以下程式碼會將受 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 - CIS Azure Kubernetes Service Benchmark 3.5
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[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, CWE ID 1173
[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.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.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 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 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 - CIS Azure Kubernetes Service Benchmark 3.5
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[8] Standards Mapping - CIS Kubernetes Benchmark complete
[9] Standards Mapping - Common Weakness Enumeration CWE ID 554, CWE ID 1173
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] 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 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 - 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)
[26] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[27] Standards Mapping - OWASP Mobile 2024 M8 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.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 3.1 Requirement 6.5.7
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 APSC-DV-002560 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 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 - 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 - CIS Azure Kubernetes Service Benchmark 3.5
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[9] Standards Mapping - CIS Kubernetes Benchmark complete
[10] Standards Mapping - Common Weakness Enumeration CWE ID 554, CWE ID 1173
[11] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[12] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[13] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[14] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[15] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[16] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[17] Standards Mapping - FIPS200 CM
[18] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[19] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[20] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[21] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[22] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[23] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[24] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[25] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[26] 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)
[27] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[28] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[39] 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
[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.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 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-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.python.html5_cross_site_scripting_protection
Abstract
已停用 HTML5 輸入表單欄位驗證。
Explanation
HTML5 提供了簡易輸入表單欄位驗證的新功能。您可以藉由 required 屬性指定輸入表單欄位是否為必要。指定表單類型可確保輸入內容會根據其類型進行檢驗。您甚至可以提供自訂 pattern 屬性,根據一般表示式檢查輸入內容。但是,若在表單標籤上新增 novalidate,並在提交輸入標籤上新增 formnovalidate 屬性,則此驗證便會停用。

範例 1: 下列範例藉由 novalidate 屬性停用表單驗證。


<form action="demo_form.asp" novalidate="novalidate">
E-mail: <input type="email" name="user_email" />
<input type="submit" />
</form>
範例 2: 下列範例藉由 formnovalidate 屬性停用表單驗證。


<form action="demo_form.asp" >
E-mail: <input type="email" name="user_email" />
<input type="submit" formnovalidate="formnovalidate"/>
</form>


停用驗證的 HTML 表單對使用者而言並不方便,且可能造成伺服器面臨各種類型的攻擊。未經驗證的輸入是導致各種弱點的根源,如 cross-site scripting、process control 和 SQL injection。
References
[1] HTML5 form novalidate Attribute W3Schools
[2] HTML5 input formnovalidate Attribute W3Schools
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 1173
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[16] Standards Mapping - FIPS200 SI
[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 Top 10 2004 A1 Unvalidated Input
[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 - 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)
[26] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[27] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[39] 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
[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.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 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-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.content.html.html5_form_validation_turned_off
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
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.server.com/login.php?name=alice&name=hacker

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

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


URL: http://www.host.com?poll_id=4567
連結 1:<a href="http://www.host.com/vote.php?lang=en&poll_id=4567">English<a>
連結 2:<a href="http://www.host.com/vote.php?lang=es&poll_id=4567">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
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
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
desc.dataflow.ruby.http_parameter_pollution
Abstract
某些函數會傳回要搜尋之緩衝區邊界以外的記憶體指標。後續操作指標可能會產生意想不到的結果。
Explanation
在以下任一情況下,在緩衝區內搜尋字元的函數,可傳回緩衝區邊界以外的指標:

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

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

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


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


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

這個問題類似於「字串終止錯誤」,程式設計師是依賴字元陣列來包含一個 Null 結束字元。
References
[1] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
desc.semantic.cpp.illegal_pointer_value.master
Abstract
使用使用者控制的資料或不可信賴的資料定義 HTML 序列化程式原則時,可能會允許攻擊者避開序列化需求,並啟動 Cross-site scripting (XSS) 攻擊。
Explanation
「輸入處理」這個概括性用語是指,對輸入資料執行驗證、序列化、篩選及編碼/解碼等功能。Cross-Site Scripting、SQL Injection 和程序控制弱點是由於輸入處理錯誤或缺少輸入處理而造成的。序列化輸入需要將輸入轉換成可接受的形式,通常在實作之外加上輸入驗證。HTML 序列化是指,清理並清除使用者輸入,以僅允許視為安全的標籤、屬性和元素。
實作一個徹底的 HTML 序列化原則很困難,成功實作的關鍵在於瞭解將使用資料的環境。每一個環境有其自己的弱點,無法一體適用。雖然使用 HTML 序列化程式 (例如 OWASP HTML 序列化程式) 防範 Web 應用程式中的 XSS 弱點是明智的做法,但是實作不當可能會導致產生虛假的安全感。
範例 1:以下 Java 程式碼使用使用者控制的輸入變數 elements 來建立 HTML 序列化程式原則:


...
String elements = prop.getProperty("AllowedElements");
...
public static final PolicyFactory POLICY_DEFINITION = new HtmlPolicyBuilder()
.allowElements(elements)
.toFactory();

....


惡意使用者會藉由提供 <script> 之類的危險元素給 elements,造成 HTML 序列化程式原則接受這些危險元素。

References
[1] OWASP Cross-Site Scripting (XSS) Prevention Cheat Sheet
[2] Understanding Malicious Content Mitigation for Web Developers CERT
[3] HTML 4.01 Specification W3
desc.dataflow.java.insecure_sanitizer_policy