Web14：HTTP 協定中的安全性問題

本文介紹了在兩個文件 RFC 7230 和 RFC 7231 中提出的HTTP 協定中的一些安全性問題。文章中有關特定錯誤的範例引用自 OWASP。

1.中間因素帶來的風險

HTTP 允許使用中介體透過一系列連線來回應請求。共有三種常見的中介元素：代理、網關和隧道。

請求或回應必須經過 A、B 和 C 點。他們可以存取正在傳輸的敏感訊息，例如使用者或組織的個人資訊。中介機構對安全和隱私缺乏關注可能會導致廣泛的潛在攻擊。

系統開發人員和開發人員在系統設計、編碼和部署過程中應考慮隱私和安全因素。

使用者需要意識到使用不受信任的代理或網關的危險。

2. 響應分裂

回應分割（又稱 CRLF 注入）是一種流行的 Web 漏洞利用技術。攻擊者在某些請求參數中發送編碼數據，然後將其解碼並在回應標頭的特定欄位中重複。

如果該資料是代表回應結束的符號，並且發動後續回應，則原始回應將分割成兩個，並且第二個回應的內容將被攻擊者控制。然後，攻擊者可以在同一持久連接中發出另一個請求，並欺騙接收者（包括中介）相信第二個回應是對第二個請求的回應。

3. 請求走私

請求走私是一種利用不同類型伺服器處理請求的差異來隱藏附加到原始請求的看似無害的請求的技術。

讓我們考慮以下範例：

假設 POST 請求標頭中包含兩個具有兩個不同值的「Content-length」欄位。某些伺服器會拒絕此請求（IIS 和 Apache），但其他伺服器不會。例如，SunONE W/S 6.1 首先使用 Content-length 字段，而 sunONE Proxy 3.6 其次使用 Content-length 字段。

假設 SITE 是 SunONE W/S 的 DNS，位於 SunONE 代理程式後面，則 SunONE W/S 上有一個poison.html 檔案。以下是如何利用基於兩個伺服器之間處理不一致的 HTTP 請求提示：

[請注意，每行都以 CRLF (“”) 結尾，第 10 行除外]

讓我們考慮一下當請求透過代理伺服器傳送到 W/S 時會發生什麼。首先，代理將分析第 1 行到第 7 行（藍色）的請求，並遇到兩個 Content-Length 欄位。如上所述，它將忽略第一個欄位並理解請求正文的長度為 44 個位元組。因此，它將第8行到第10行的資料視為第一個請求正文（從第8行到第10行，資料正好是44位元組長）。然後代理將分析第 11 至 14 行（紅色）作為客戶端的第二個請求。

現在讓我們看看 W/S 如何解釋上面的數據，因為它是從代理轉發的。與代理程式不同，W/S 將使用第一個Content-Length 欄位並將其解釋如下：第一個請求沒有正文，第二個請求從第8 行開始（請注意，W/S 將從第11 行開始解析為值Bla 場）。

接下來我們來看看回應是如何傳回給客戶端的。 W/S 理解的請求是「POST /foobar.html」（來自第1 行）和「GET /poison.html」（來自第8 行），因此它將向客戶端2 發送帶有foobar 頁面內容的回應。html 和poison.html。代理知道這 2 個回應對應於 2 個請求：「POST /foobar.html」（來自第 1 行）和「GET /page_to_poison.html」（第 11 行）。代理程式會快取「page_to_poison.html」URL對應的poison.html頁面的內容（快取中毒）。從那裡，當客戶端請求“page_to_poison.html”時，它將收到poison.html頁面的內容。

4.基於檔案路徑的攻擊

Web 伺服器經常使用其本機檔案系統來管理 URI 中的檔案名稱到伺服器上實際資源的對應。大多數檔案系統並非旨在防範惡意檔案路徑。因此，伺服器需要避免存取重要的系統檔案。

例如，UNIX、Microsoft Windows 和其他幾種作業系統使用「..」作為路徑元素來表示目前檔案/目錄的上一層目錄。如果沒有適當的輸入控制和授權，系統的敏感檔案/資料夾可以透過輸入指向這些檔案/資料夾的路徑來存取。

5. 攻擊類型：命令注入、程式碼注入、查詢注入

[Web 伺服器經常使用 URI 中的參數作為輸入來執行系統指令和資料庫查詢。然而，請求中收到的數據並不總是可信的。攻擊者可以建立和修改請求中的元件（例如方法、標頭中的欄位、正文...）、執行系統命令、查詢資料庫...

例如，SQL 注入是一種常見的攻擊，其中 Web 伺服器接收作為 SQL 查詢一部分的 URI 中的參數。因此，攻擊者可以欺騙 Web 伺服器執行非法 SQL 查詢，從而竊取或破壞資料庫。
一般來說，使用者提交的資料不應該直接用於在伺服器上執行操作。這些資料需要經過過濾器，定義什麼是有效的，什麼是無效的，從而消除不需要的資料。

6. 洩漏個人訊息

客戶端通常包含大量的個人訊息，包括使用者提供的與伺服器互動的資訊（例如使用者名稱、密碼、位置、電子郵件地址等）以及使用者的網頁瀏覽活動資訊（歷史記錄、書籤、 ETC。）。實施時應注意防止可能洩漏這些私人資訊的點。

7. 洩漏 URI 中的敏感訊息

URI 根據設計，旨在與所有用戶共享，並且不保證安全。 URI 通常顯示在網站的原始程式碼中，並儲存在沒有保護機制的書籤中。因此，如果URI中包含敏感資訊、個人資訊等，就會不安全。

避免使用 GET 方法將個人資訊傳送到伺服器，因為它將顯示在 URI 中。請改用 POST 方法。

8. 揭示所使用的軟體訊息

標頭中的 User-Agent、Via、Server 欄位通常提供有關發送者所使用的軟體的資訊。從理論上講，這使得攻擊者能夠更輕鬆地利用這些軟體中的已知漏洞。