Header Manipulation

ABSTRACT

HTTP 響應頭文件中包含未驗證的數據會引發 cache-poisoning、cross-site scripting、cross-user defacement、page hijacking、cookie manipulation 或 open redirect。

EXPLANATION

以下情況中會出現 Header Manipulation 漏洞：

1. 數據通過一個不可信賴的數據源進入 Web 應用程序，最常見的是 HTTP 請求。

2. 數據包含在一個 HTTP 響應頭文件里，未經驗證就發送給了 Web 用戶。

如同許多軟件安全漏洞一樣，Header Manipulation 只是通向終端的一個途徑，它本身并不是終端。從本質上看，這些漏洞是顯而易見的：一個攻擊者將惡意數據傳送到易受攻擊的應用程序，且該應用程序將數據包含在 HTTP 響應頭文件中。

其中最常見的一種 Header Manipulation 攻擊是 HTTP Response Splitting。為了成功地實施 HTTP Response Splitting 盜取，應用程序必須允許將那些包含 CR（回車，由 %0d 或 \r 指定）和 LF（換行，由 %0a 或 \n 指定）的字符輸入到頭文件中。攻擊者利用這些字符不僅可以控制應用程序要發送的響應剩余頭文件和正文，還可以創建完全受其控制的其他響應。

如今的許多現代應用程序服務器和框架可以防止 HTTP 頭文件感染惡意字符。例如，Microsoft 的 .NET 框架的最新版本會在 CR、LF 和 NULL 字符被傳送給 HttpResponse.AddHeader() 方法時將其轉換為 %0d、%0a 和 %00。如果您正在使用的最新的 .NET 框架不允許使用新行字符設置頭文件，則應用程序便不會容易受到 HTTP Response Splitting 攻擊。然而，單純地過濾換行符可能無法保證應用程序不受 Cookie Manipulation 或 Open Redirects 的攻擊，因此必須在設置帶有用戶輸入的 HTTP 頭文件時采取措施。

例：下列代碼片段會從 HTTP 請求中讀取網絡日志項的作者名字 author，并將其置于一個 HTTP 響應的 cookie 頭文件中。


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

假設在請求中提交了一個字符串，該字符串由標準的字母數字字符組成，如 "Jane Smith"，那么包含該 cookie 的 HTTP 響應可能表現為以下形式：


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

然而，因為 cookie 的值是根據未經驗證的用戶輸入形成的，所以只有當傳遞給 Author.Text 的值不包含任何 CR 和 LF 字符時，響應才會保留這種形式。如果攻擊者提交的是一個惡意字符串，比如 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n..."，那么 HTTP 響應就會被分割成以下形式的兩個響應：


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

HTTP/1.1 200 OK
...

顯然，第二個響應已完全由攻擊者控制，攻擊者可以用所需的頭文件和正文內容構建該響應。攻擊者可以構建任意 HTTP 響應，從而發起多種形式的攻擊，包括：cross-user defacement、網絡和瀏覽器 cache poisoning、cross-site scripting 和 page hijacking。

cross-user defacement：攻擊者可以向一個易受攻擊的服務器發出一個請求，導致服務器創建兩個響應，其中第二個響應可能會被曲解為對其他請求的響應，而這一請求很可能是與服務器共享相同 TCP 連接的另一用戶發出的。這種攻擊可以通過以下方式實現：攻擊者誘騙用戶，讓他們自己提交惡意請求；或在遠程情況下，攻擊者與用戶共享同一個連接到服務器（如共享代理服務器）的 TCP 連接。最理想的情況是，攻擊者只能通過這種做法讓用戶相信自己的應用程序已經遭受了黑客攻擊，進而對應用程序的安全性失去信心。最糟糕的情況是，攻擊者可能提供經特殊技術處理的內容，這些內容旨在模仿應用程序的執行方式，但會重定向用戶的私人信息（如帳號和密碼），將這些信息發送給攻擊者。

cache-poisoning： 如果多用戶 Web 緩存或者單用戶瀏覽器緩存將惡意構建的響應緩存起來，該響應的破壞力會更大。如果響應緩存在共享的 Web 緩存（如在代理服務器中常見的緩存）中，那么使用該緩存的所有用戶都會不斷收到惡意內容，直到清除該緩存項為止。同樣，如果響應緩存在單個用戶的瀏覽器中，那么在清除該緩存項以前，該用戶會不斷收到惡意內容。然而，影響僅局限于本地瀏覽器的用戶。

Cross-Site Scripting：一旦攻擊者控制了應用程序傳送的響應，就可以選擇多種惡意內容來傳播給用戶。Cross-Site Scripting 是最常見的攻擊形式，這種攻擊在響應中包含了惡意的 JavaScript 或其他代碼，并在用戶的瀏覽器中執行。基于 XSS 的攻擊手段花樣百出，幾乎是無窮無盡的，但通常它們都會包含傳輸給攻擊者的私人數據（如 Cookie 或者其他會話信息）。在攻擊者的控制下，指引受害者進入惡意的網絡內容；或者利用易受攻擊的站點，對用戶的機器進行其他惡意操作。對于易受攻擊的應用程序用戶，最常見且最危險的攻擊就是使用 JavaScript 將會話和 authentication 信息返回給攻擊者，而后攻擊者就可以完全控制受害者的帳號了。

Page Hijacking：除了利用一個易受攻擊的應用程序向用戶傳輸惡意內容，還可以利用相同的根漏洞，將服務器生成的供用戶使用的敏感內容重定向，轉而供攻擊者使用。攻擊者通過提交一個會導致兩個響應的請求，即服務器做出的預期響應和攻擊者創建的響應，致使某個中間節點（如共享的代理服務器）誤導服務器所生成的響應，將本來應傳送給用戶的響應錯誤地傳給攻擊者。因為攻擊者創建的請求產生了兩個響應，第一個被解析為針對攻擊者請求做出的響應，第二個則被忽略。當用戶通過同一 TCP 連接發出合法請求時，攻擊者的請求已經在此處等候，并被解析為針對受害者這一請求的響應。這時，攻擊者將第二個請求發送給服務器，代理服務器利用針對受害者（用戶）的、由該服務器產生的這一請求對服務器做出響應，因此，針對受害者的這一響應中會包含所有頭文件或正文中的敏感信息。

Cookie Manipulation：當與類似 Cross-Site Request Forgery 的攻擊相結合時，攻擊者就可以篡改、添加、甚至覆蓋合法用戶的 cookie。

Open Redirect：如果允許未驗證的輸入來控制重定向機制所使用的 URL，可能會有利于攻擊者發動釣魚攻擊。

REFERENCES

[1] Standards Mapping - OWASP Top 10 2010 - (OWASP 2010) A1 Injection

[2] Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A1 Unvalidated Input

[3] Standards Mapping - OWASP Top 10 2007 - (OWASP 2007) A2 Injection Flaws

[4] Standards Mapping - Security Technical Implementation Guide Version 3 - (STIG 3) APP3510 CAT I

[5] Standards Mapping - Security Technical Implementation Guide Version 3.4 - (STIG 3.4) APP3510 CAT I

[6] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 113

[7] A. Klein Divide and Conquer:HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics

[8] D. Crab HTTP Response Splitting

[9] Standards Mapping - Web Application Security Consortium 24 + 2 - (WASC 24 + 2) HTTP Response Splitting

[10] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.3.1.1, Requirement 6.5.2

[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.1

[12] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 - (PCI 2.0) Requirement 6.5.1

[13] Standards Mapping - FIPS200 - (FISMA) SI

亚洲欧美在线