詳解 HTTP Host 頭攻擊
在公眾號后臺回復(fù):JGNB,可獲取杰哥原創(chuàng)的 PDF 手冊。
1. HTTP Host頭攻擊
從HTTP / 1.1開始,HTTP Host標頭是必需的請求標頭。它指定客戶端要訪問的域名。例如,當用戶訪問https://example.net/web-security時,其瀏覽器將組成一個包含Host標頭的請求,如下所示:
GET?/web-security?HTTP/1.1
Host:?example.net
在某些情況下,例如當請求由代理轉(zhuǎn)發(fā)時,Host值可能會在到達預(yù)期的后端組件之前進行更改。也就發(fā)生了Host頭攻擊。

2. HTTP Host頭的作用
HTTP Host頭的目的是幫助識別客戶端要與之通信的后端組件。如果請求不包含Host頭或者格式不正確,則在將傳入請求的應(yīng)用程序時可能會導(dǎo)致問題。
從歷史上看,這種漏洞并不存在太大問題,因為每個IP地址只會被用于單個域的內(nèi)容。如今,很大程度上是由于同一個IP上存在多個Web應(yīng)用程序(不同端口,不同域名解析等),通常可以在同一IP地址訪問多個網(wǎng)站和應(yīng)用程序。這種方法的普及也部分是由于IPv4地址耗盡所致。
當可以通過同一IP地址訪問多個應(yīng)用程序時,最常見的原因是以下情況之一:
虛擬主機
單個Web服務(wù)器托管多個網(wǎng)站或應(yīng)用程序。這可能是具有單個所有者的多個網(wǎng)站,但是也可能是不同所有者的網(wǎng)站托管在同一個共享平臺上。它們都與服務(wù)器共享一個公共IP地址。
通過代理路由流量
網(wǎng)站托管在不同的后端服務(wù)器上,但是客戶端和服務(wù)器之間的所有流量都通過代理系統(tǒng)進行路由。這可能是一個簡單的負載平衡設(shè)備或某種反向代理服務(wù)器。在客戶通過內(nèi)容分發(fā)網(wǎng)絡(luò)(CDN)訪問網(wǎng)站的情況下,這種設(shè)置尤其普遍。
在上面兩種種情況下,即使網(wǎng)站托管在單獨的后端服務(wù)器上,它們的所有域名也都解析為中間組件的單個IP地址。這帶來了與虛擬主機相同的問題,因為反向代理或負載平衡需要知道每個請求到的哪個后端上。
HTTP Host頭的作用就在于,指定請求應(yīng)該發(fā)送到那個應(yīng)用程序的后端服務(wù)器上。打個比方,一封信需要送到居住在公寓樓中的某人手中,整個公寓有許多房間,每個房間都可以接受信件,通過指定房間號和收件人(也就是HTTP Host頭)來將信封送到指定的人手中。
3. 什么是HTTP Host頭攻擊
一些網(wǎng)站以不安全的方式處理Host頭的值。如果服務(wù)器直接信任Host頭,未校驗它的合法性,則攻擊者可能能夠使用此可控變量來注入Host,以操縱服務(wù)器端的行為。
現(xiàn)成的Web應(yīng)用程序通常不知道將它們部署在哪個域上,除非在安裝過程中在配置文件中手動指定了該域。例如,當他們需要知道當前域以生成電子郵件中包含的絕對URL時,他們可能依賴于Host頭中的值:
<a?href="https://_SERVER['HOST']/support">聯(lián)系支持a>
Host頭值還可以用于不同網(wǎng)站系統(tǒng)之間的各種交互。
由于Host頭實際上是用戶可控制的,因此這種做法可能導(dǎo)致許多問題。如果未校驗或者直接使用Host頭,則Host頭可以與一系列其他漏洞“組合拳”攻擊,比如:
緩存投毒
特殊業(yè)務(wù)功能的邏輯漏洞
基于路由的SSRF
經(jīng)典服務(wù)端漏洞,如SQL注入(當Host被用于SQL語句時)等
4. 如何發(fā)掘HTTP Host頭攻擊
首先要判斷服務(wù)端是否檢測Host頭?檢測完了是否還使用Host頭的值?
通過修改Host的值,如果服務(wù)端返回錯誤信息:

則說明服務(wù)端檢測了Host的內(nèi)容。至于有沒有使用Host頭的值,有以下幾種方法去發(fā)掘:
修改Host值
簡單的來說,可以修改HTTP頭中的Host值,如果觀察到響應(yīng)包中含有修改后的值,說明存在漏洞。
但有時候篡改Host頭的值會導(dǎo)致無法訪問Web應(yīng)用程序,從而導(dǎo)致“無效主機頭”的錯誤信息,特別是通過CDN訪問目標時會發(fā)生這種情況。
添加重復(fù)的Host頭
添加重復(fù)的Host頭,通常兩個Host頭之中有一個是有效的,可以理解為一個是確保請求正確地發(fā)送到目標服務(wù)器上;另一個則是傳遞payload到后端服務(wù)器中。
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
有時候也可以嘗試不同的協(xié)議,如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
諸如此類,還有其他的字段:
X-Host
X-Forwarded-Server
X-HTTP-Host-Override
Forwarded
忽略端口僅校驗域名
當修改、添加重復(fù)Host頭被攔截的時候,可以嘗試了解Web應(yīng)用程序是怎樣解析Host頭的。
比如,一些解析算法會忽略Host頭中的端口值,僅僅校驗域名。這時候可以將Host修改為如下形式:
GET?/example?HTTP/1.1
Host:?vulnerable-website.com:attack-stuff
保持域名不變,修改端口值為非端口號的其他值(非數(shù)字), 將Host頭攻擊的payload放在端口值處,同樣能進行Host頭攻擊。
5. HTTP Host頭攻擊漏洞示例
5.1 密碼重置中毒
根據(jù)HTTP Host頭攻擊的攻擊特點,它被廣泛應(yīng)用于密碼重置中毒:攻擊者可以操縱網(wǎng)站在重置密碼情況下生成的密碼重置鏈接,使其發(fā)送攻擊者指定的域下,利用此來竊取重置任意用戶密碼的令牌。

一個重設(shè)密碼(忘記密碼)功能的大致流程如下:
1. 用戶輸入其用戶名或電子郵件地址,然后提交密碼重置請求。
2. 該網(wǎng)站檢查該用戶是否存在,然后生成一個臨時的、唯一的、復(fù)雜的令牌,該令牌與后端的用戶帳戶相關(guān)聯(lián)。
3. 該網(wǎng)站向用戶發(fā)送一封電子郵件,其中包含用于重置其密碼的鏈接。重置令牌的參數(shù)包含在相應(yīng)的URL中:
https://normal-website.com/reset?token=0a1b2c3d4e5f6g7h8i9j
4. 當用戶訪問此URL時,網(wǎng)站將檢查提供的令牌是否有效,并使用它來確定要重置哪個帳戶。如果一切都符合,則可以進入用戶重置密碼步驟。最后,令牌被銷毀。
以上步驟的安全性依賴于:只有目標用戶才能訪問其電子郵件,從而可以訪問其唯一的令牌。
密碼重置中毒是竊取此令牌以更改另一個用戶密碼的一種漏洞。
如果網(wǎng)站重置密碼的流程完全依賴用戶的可控輸入(如HTTP Host頭),這可能導(dǎo)致密碼重置中毒:
1. 攻擊者獲取受害者的用戶名或者電子郵件,作為提交重置密碼的請求,攻擊者會攔截請求并修改HTTP Host頭為其指定的域,如evil-user.net
2. 受害者會收到一封重置密碼的郵件,但由于攻擊者修改了Host頭,而web程序生成重置鏈接又完全依賴于Host頭,導(dǎo)致生成以下URL:
https://evil-user.net/reset?token=0a1b2c3d4e5f6g7h8i9j
3. 如果受害者點擊了該鏈接,重置密碼的令牌就會發(fā)送到攻擊者的服務(wù)器 evil-user.net 上
4. 當攻擊者獲取到蟲子密碼的令牌之后,就會進行相應(yīng)的構(gòu)造訪問真實重置密碼的URL進行密碼重置。
5.1.1 密碼重置中毒—基礎(chǔ)
詳細了解了上面的密碼重置中毒的流程和原理之后,這里通過HTTP Host頭攻擊導(dǎo)致的基礎(chǔ)的密碼重置中毒來演示。
首先輸入用戶名或者用戶的電子郵箱來重置指定用戶的密碼:

提交之后,會發(fā)送一封重置密碼的電子郵件到wiener用戶的郵箱中(數(shù)據(jù)包如右圖):

注意重置密碼的鏈接,可能是受Host頭的值的影響?
我們來驗證一下是否存在HTTP Host頭攻擊,修改Host頭的值為 baidu.com:

發(fā)現(xiàn)請求是可以被后端服務(wù)器接收的,所以是存在HTTP Host頭攻擊的。
這里就輸入受害用戶carlos進行重置密碼,然后抓包將Host頭的值改為我們自己的服務(wù)器:

隨即進入輸入新密碼的界面,密碼重置中毒成功。
5.1.2 密碼重置中毒—注入覆蓋Host頭的字段
有時候直接修改Host頭、添加重復(fù)Host頭的值以及混淆Host頭都不行:

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

實際上他能夠被 X-Forwarded-Host 字段影響,導(dǎo)致Host頭攻擊,當同時添加多個字段使請求被攔截時,可以嘗試類似排除法、二分法來排查哪個字段有效。
對受害用戶carlos進行密碼重置投毒:

然后構(gòu)造鏈接即可:
https://acf11f4e1f164378800b165b00bb007d.web-security-academy.net/forgot-password?temp-forgot-password-token=o8gD3Le1K0YQcb2AaASgiI8F2eVI5m3h

5.1.3 重置密碼中毒—Dangling Markup技術(shù)
首先簡單介紹一下 Dangling Markup技術(shù):
Dangling markup技術(shù)
Dangling markup技術(shù), 是一種無需腳本即可竊取頁面內(nèi)容的技術(shù),它使用圖像等資源(結(jié)合CSP運行的策略)將數(shù)據(jù)發(fā)送到攻擊者控制的遠程位置。當反射型XSS不工作或被內(nèi)容安全策略(CSP)阻止時,它非常有用。其思想是插入一些未完成狀態(tài)的部分HTML,例如圖像標記的src屬性,頁面上的其余標記關(guān)閉該屬性,但同時將兩者之間的數(shù)據(jù)(包含竊取頁面的內(nèi)容)發(fā)送到遠程服務(wù)器。
例如,我們在反射型XSS注入點上注入這樣一個img標簽:
則注入點和下一個雙引號的代碼將會發(fā)送到攻擊者的 https://evilserver 服務(wù)器, 其中被發(fā)送的代碼或者內(nèi)容可能包含一些敏感信息, 例如CSRF Token等, 配合反射型XSS以完成CSRF的利用。關(guān)于 Dangling Markup技術(shù) 的實戰(zhàn)意義可以參考博主之前的文章:繞過CSP之Dangling markup技術(shù)
(https://blog.csdn.net/angry_program/article/details/106441323)
什么時候可以使用 Dangling Markup技術(shù) 呢?與我們這篇文章的主題有什么關(guān)系呢?
我們直接進入主題,當輸入需要重置密碼的用戶名后,該用戶的郵箱內(nèi)會收到如下郵箱:

有一個跳轉(zhuǎn)到登錄界面的鏈接,后面緊接著重置之后的隨機密碼。
此時考慮一下,該鏈接是否是從Host頭取值而來?只要這個值可控,那么就可以利用Host頭攻擊實施 Dangling Markup攻擊,包含住鏈接后面緊跟著的密碼,再結(jié)合Host頭攻擊將請求指定到攻擊者服務(wù)器上。一個漫天過海的竊取行為就完成了。
第一步,尋找Host頭攻擊點:
通過Fuzz,可發(fā)現(xiàn)Host頭攻擊類型為 忽略端口僅校驗域名。即服務(wù)端在校驗Host域的時候,僅校驗了域名,忽略了后面的端口號,造成端口值可控(可以是數(shù)字或字符):


通過在Host頭的端口中注入payload,依舊可以實現(xiàn)Host頭攻擊。
第二步,借助可控變量 Host:ip:port 來實施 Dangling Markup技術(shù),從而將后面的密碼外帶到攻擊者服務(wù)器上:
注意,需要閉合此處的雙引號出去,經(jīng)過嘗試,輸入單引號時,服務(wù)端會自動轉(zhuǎn)為雙引號,故這里通過單引號將雙引號閉合,然后添加自定的標簽將密碼外帶:

原本的正常HTML是這樣的:

通過 ?Dangling Markup技術(shù) 在標簽的鏈接中注入? 符,使得后面的值在雙引號閉合之前全部被當做URL參數(shù)請求到攻擊者服務(wù)器上:

這也是 Dangling Markup技術(shù) 的精髓所在,該技術(shù)的核心點在于:
可控變量后面是否接著需要竊取的關(guān)鍵數(shù)據(jù)(包括Token、密碼等)
在攻擊者服務(wù)器上可以看到被Host頭攻擊轉(zhuǎn)發(fā)上來的請求,里面成功竊取了受害者重置后的密碼:

5.2 Host頭攻擊+緩存投毒
當存在Host頭攻擊的web站點不存在密碼重置的功能的時候,此時該漏洞就顯得沒有影響,因為不可能驅(qū)使用戶去抓包修改Host頭,輔助攻擊者完成一系列的攻擊。
但是,如果目標站點使用Web緩存,則可以通過緩存投毒給其他用戶提供帶有病毒的緩存響應(yīng)。此時的Host頭攻擊漏洞轉(zhuǎn)變?yōu)轭愃芚SS存儲型類的漏洞。要構(gòu)造Web緩存投毒攻擊:
1. 需要尋找映射到其他用戶請求的緩存鍵;
2. 下一步則是緩存此惡意響應(yīng);
3. 然后,此惡意緩存將提供給嘗試訪問受影響頁面的所有用戶。
第一步,尋找Host頭攻擊點:
通過對站點的主頁添加重復(fù)的Host值,可以達到覆蓋的效果,并驗證存在Host頭攻擊:

第二步,尋找是否使用了Web緩存?緩存鍵是什么?
從上圖中也可以發(fā)現(xiàn),站點使用了Wen緩存功能,并且配合Host頭攻擊,可以緩存 /resources/js/tracking.js 資源文件。
第三步,在攻擊者服務(wù)器上創(chuàng)建一個同名的 /resources/js/tracking.js 資源文件,內(nèi)容為:
alert(document.cookie);
然后通過Host頭注入攻擊者服務(wù)器域名,可以看到在響應(yīng)中正確地對應(yīng)了我們的 /resources/js/tracking.js 資源文件:

發(fā)送多次請求,使該請求的響應(yīng)變?yōu)榫彺妫?/p>

當其他用戶請求站點主頁時,服務(wù)端就會提供該惡意緩存給用戶,造成緩存投毒。
5.3 Host頭攻擊繞過訪問控制
出于安全考慮,通常網(wǎng)站對某些功能的訪問限制為內(nèi)部用戶使用。但是通過Host頭攻擊一定可能上可以繞過這些限制。
對于一個站點,從發(fā)現(xiàn)Host頭攻擊到利用,下面來展示一個完整的流程:
第一步,訪問主頁,隨意修改Host的值:

注意,這里的Host的值不會出現(xiàn)響應(yīng)包中,但是依然可能存在Host頭攻擊,因為響應(yīng)依然成功,說明服務(wù)端沒有對Host頭做驗證。
第二步,尋找敏感頁面,通過 /robots.txt 知道 /admin 為做了訪問控制的頁面:

可以錯誤信息提示,/admin 頁面只允許本地用戶訪問。
第三步,將Host改為服務(wù)端內(nèi)部地址,從而繞過IP訪問控制:

5.4 Host頭攻擊+SSRF
Host頭攻擊可能會導(dǎo)致基于路由的SSRF攻擊,稱為:Host SSRF Attack。
經(jīng)典的SSRF攻擊通?;赬XE或可利用的業(yè)務(wù)邏輯,將用戶可控的URL作為HTTP請求發(fā)送;而基于路由的SSRF依賴于云部署的體系結(jié)構(gòu)中,包括負載均衡和反向代理,這些中間件將請求分配發(fā)送到對應(yīng)的后端服務(wù)器處理,如果服務(wù)端未校驗Host頭轉(zhuǎn)發(fā)的請求,則攻擊者可能會將請求發(fā)送(重定向)到體系中的任意系統(tǒng)。
這可能需要知道內(nèi)部系統(tǒng)的IP地址(私有地址),一般可以通過信息收集或者Fuzz來判斷有效的私有IP地址(如枚舉192.168.1.1/16)。
5.4.1 基礎(chǔ)Host頭攻擊+SSRF
比如,普通方式訪問不到 /admin 頁面(404):

猜測 /admin 存在于內(nèi)網(wǎng)中,需要內(nèi)網(wǎng)機器才能訪問,但是配合Host頭攻擊+SSRF可以繞過并訪問。
第一步,判斷Host是否被使用,可用DNSLog外帶
這里我使用Burp自帶的 “Burp Collaborator client” ?來實現(xiàn)外帶:

說明服務(wù)端是根據(jù)Host頭的域名來請求資源的。
第二步,基于Host頭的SSRF探測內(nèi)網(wǎng)主機
假如一些敏感的頁面(比如管理頁面),深處于內(nèi)網(wǎng),外網(wǎng)無法訪問,但是通過Host頭攻擊+SSRF可達到繞過訪問控制,從而訪問內(nèi)網(wǎng)資產(chǎn),這里Fuzz內(nèi)網(wǎng)的IP的C段為192.168.0.0/24,直接利用Intruder枚舉:


得到內(nèi)網(wǎng)IP為192.168.0.240
第三步,訪問內(nèi)網(wǎng)資源
構(gòu)造 /admin 頁面,在Host處換位內(nèi)網(wǎng)IP:

5.4.2 Host頭攻擊+SSRF—使用絕對路徑的URL
有時候服務(wù)端會校驗Host頭的值,如果Host被修改,服務(wù)端會拒絕一切修改過后的請求:

普通請求通常在請求域上使用相對路徑,但是,服務(wù)端也同時可能配置了絕對URL的請求,采用如下形式可繞過對Host的驗證:
GET?http://acab1f4b1f3c7628805c2515009a00c9.web-security-academy.net/?HTTP/1.1

接著用 “Burp Collaborator client” 進行外帶:

外帶成功,說明Host頭被服務(wù)端使用來向指定域名請求資源,直接SSRF爆破內(nèi)網(wǎng):

訪問內(nèi)網(wǎng)頁面:

6. HTTP Host頭攻擊防護
最簡單的方法是避免在服務(wù)器端代碼中完全使用Host頭,可以只使用相對URL。
其他方法包括:
6.1 正確配置絕對域名URL
當必須使用絕對域名URL時,應(yīng)在配置文件中手動指定當前域的URL,并引用配置的值,而不是從HTTP的Host頭中獲取。這種方法可防止密碼重置的緩存投毒。
6.2 白名單校驗Host頭的域
如果必須使用Host頭,需要正確校驗它的合法性。這包括允許的域,并使用白名單校驗它,以及拒絕或重定向?qū)o法識別的主機請求。這包括但不僅限于單個web應(yīng)用程序、負載均衡以及反向代理設(shè)備上。
6.3 不支持主機頭覆蓋
確保不適用與Host頭功能相近的字段,如X-Forwarded-Host、X-Forwarded-For等,這些有時候是默認開啟的。
值得一提的是,不應(yīng)該將內(nèi)網(wǎng)使用的Host主機(不出網(wǎng))與公網(wǎng)的應(yīng)用程序托管在同一個服務(wù)器上,否則攻擊者可能會操縱Host頭來訪問內(nèi)部域。
作者:angry_program
來源:blog.csdn.net/angry_program/article/details/109034421
推薦閱讀
HTTPS 協(xié)議到底比 HTTP 協(xié)議多些什么?

