【51CTO.com獨(dú)家特稿】在本文中，我們將詳細(xì)為讀者介紹針對(duì)HTTP截?cái)嗪虷TTP走私攻擊的安全測(cè)試技術(shù)。我們將通過(guò)實(shí)例演示如何利用HTTP協(xié)議的某些特性，或者利用Web應(yīng)用程序的弱點(diǎn)或者不同代理對(duì)HTTP消息的解釋也不相同的特點(diǎn)來(lái)發(fā)動(dòng)這兩種攻擊。

一、HTTP截?cái)?走私漏洞概述

本文遏制，我們將分析針對(duì)特定的HTTP報(bào)頭的兩種不同的攻擊技術(shù)：HTTP截?cái)嗪虷TTP走私攻擊。對(duì)于HTTP截?cái)喙舳裕抢昧巳狈斎胂敬胧┑穆┒?，該漏洞允許入侵者向應(yīng)用程序響應(yīng)的頭部插入CR和LF字符，從而將響應(yīng)分割為兩個(gè)不同的HTTP消息。該攻擊的目標(biāo)既不同于緩存投毒，也區(qū)別于跨站腳本攻擊。對(duì)于第二種攻擊方法，攻擊者利用了這樣的一個(gè)事實(shí)，即一些專門精心制作的HTTP消息可能會(huì)隨著接收它們的代理的不同，而作不同的解析和解釋。HTTP走私技術(shù)要求對(duì)處理HTTP消息的各種代理相當(dāng)熟悉，否則無(wú)法發(fā)動(dòng)這種攻擊。

下面我們介紹這些漏洞的黑盒測(cè)試和灰盒測(cè)試技術(shù)。

二、HTTP截?cái)喙艉诤袦y(cè)試

一些web應(yīng)用程序會(huì)使用部分用戶輸入來(lái)生成它們的響應(yīng)頭部的某些值，這方面最簡(jiǎn)單的例子就是重定向了，因?yàn)槟繕?biāo)URL依賴于用戶提交的某些值。舉例來(lái)說(shuō)，假如用戶被要求在標(biāo)準(zhǔn)web接口和高級(jí)web接口之間做出選擇，然后，選擇的結(jié)果將作為一個(gè)參數(shù)傳遞，并且這個(gè)參數(shù)將用于觸發(fā)重定向到相應(yīng)的頁(yè)面的應(yīng)答頭中。更確切地說(shuō)，如果該參數(shù)interface的值是advanced，那么應(yīng)用程序?qū)㈨憫?yīng)下列內(nèi)容：

圖1

收到這個(gè)消息后，瀏覽器會(huì)把用戶引向Location頭部規(guī)定的頁(yè)面。然而，如果應(yīng)用程序沒(méi)有對(duì)用戶輸入進(jìn)行過(guò)濾的話，攻擊者就可以在參數(shù)interface中插入序列%0d%0a，而該序列代表的則是用于分割各行的CRLF（回車換行）序列。這樣一來(lái)，攻擊者將能夠觸發(fā)一個(gè)響應(yīng)，重要的是任何解析器（例如介于用戶和Web應(yīng)用之間的web緩存）都會(huì)把這個(gè)響應(yīng)會(huì)被解釋為兩個(gè)不同的響應(yīng)。所以，攻擊者就可以通過(guò)給這個(gè)web緩存“投毒”以使它為后續(xù)的請(qǐng)求中提供虛假的內(nèi)容。例如，在我們前面的例子中，假設(shè)攻擊者將下列內(nèi)容作為參數(shù)interface進(jìn)行傳遞：

圖2

從存在漏洞的軟件（也就是沒(méi)有對(duì)用戶輸入進(jìn)行嚴(yán)格消毒的應(yīng)用程序）中得到的響應(yīng)將是下面的內(nèi)容：

圖3

Web緩存將看到兩個(gè)不同的響應(yīng)，因此如果攻擊者發(fā)送第一個(gè)請(qǐng)求之后立即發(fā)送對(duì)/index.html頁(yè)面的請(qǐng)求的話，web緩存會(huì)認(rèn)為這個(gè)請(qǐng)求與第二個(gè)響應(yīng)相匹配，并緩存它的內(nèi)容，這樣一來(lái)后面經(jīng)由web緩存的所有指向victim.com/index.html的請(qǐng)求都會(huì)收到系統(tǒng)故障消息，即“system down”。通過(guò)這種方式，一個(gè)攻擊者將能有效涂改站點(diǎn)在使用web緩存的用戶心中的形象，如果該web緩存是該Web應(yīng)用程序的一個(gè)反向代理的話，那么這個(gè)Web應(yīng)用程序在整個(gè)因特網(wǎng)中的用戶都會(huì)受到影響。另外，攻擊者還可以向這些用戶傳輸發(fā)動(dòng)跨站腳本攻擊攻擊的JavaScript代碼片斷，例如竊取cookies等。需要注意的是，雖然該安全漏洞位于應(yīng)用程序中，但是攻擊針對(duì)的對(duì)象卻是使用該應(yīng)用程序的用戶。

因此，為了查找這個(gè)安全漏洞，滲透測(cè)試人員需要識(shí)別所有能夠影響響應(yīng)的一個(gè)或多個(gè)頭部的用戶輸入，并檢查用戶是否能夠在其中注入一個(gè)CR+LF序列。與這個(gè)攻擊關(guān)系最密切的兩個(gè)頭部是：

Location
 
Set-Cookie 

需要注意的是，現(xiàn)實(shí)中要想成功利用這個(gè)安全漏洞可能是件非常復(fù)雜的事情，因?yàn)橛卸喾N因素必須考慮到：

1.攻擊者要想讓偽造的響應(yīng)被緩存的話，必須正確設(shè)置其中的各個(gè)頭部，例如Last-Modified頭部的值必須設(shè)為將來(lái)的一個(gè)時(shí)間。此外，攻擊者還必須破壞目標(biāo)頁(yè)面先前的緩存版本，方法是提交一個(gè)請(qǐng)求頭部中帶有“Pragma: no-cache”的前導(dǎo)請(qǐng)求來(lái)防止頁(yè)面被緩存。 

2. 即使應(yīng)用程序沒(méi)有過(guò)濾CR+LF序列，但是仍可能過(guò)濾了發(fā)動(dòng)該攻擊所需的其他字符，例如字符<和>等。這時(shí)候，攻擊者可以嘗試使用其他編碼，例如UTF-7編碼等。  

3. 某些攻擊目標(biāo)（例如ASP）會(huì)對(duì)Location頭部（例如www.victim.com/redirect.asp ）中的路徑部分進(jìn)行URL編碼處理，這樣就使得CRLF序列不起作用了。然而，它們卻不能對(duì)查詢部分（例如?interface=advanced）進(jìn)行這樣的編碼處理，這意味著放置一個(gè)前導(dǎo)問(wèn)號(hào)就能夠繞過(guò)這種過(guò)濾技術(shù)。 #p#

三、HTTP截?cái)喙艋液袦y(cè)試

對(duì)于Web應(yīng)用程序即攻擊目標(biāo)的深入了解，在發(fā)動(dòng)HTTP截?cái)喙魰r(shí)是極其有幫助的。例如，不同的攻擊目標(biāo)可能使用不同的方法來(lái)判定第一個(gè)HTTP消息在何時(shí)終止，第二個(gè)HTTP消息從什么時(shí)候開(kāi)始。當(dāng)然，有時(shí)候可以使用消息邊界來(lái)進(jìn)行判定，如上面的例子就是這樣。但是，其他的攻擊目標(biāo)可能使用不同的數(shù)據(jù)包來(lái)攜帶不同的消息。此外，有些目標(biāo)會(huì)為每個(gè)消息分配指定組塊的數(shù)量，這種情況下，第二個(gè)消息必須從特定的塊開(kāi)始，這就要求攻擊者在兩個(gè)消息之間填充必要的塊。不過(guò)，當(dāng)時(shí)有URL發(fā)送有弱點(diǎn)的參數(shù)的時(shí)候，這么做可能會(huì)引起一些麻煩，因?yàn)檫^(guò)長(zhǎng)的URL很可能被截?cái)嗷蛘哌^(guò)濾掉?；液袦y(cè)試可以幫助攻擊者找到解決辦法：一些應(yīng)用程序服務(wù)器允許使用POST而非GET來(lái)發(fā)送請(qǐng)求。

四、HTTP走私攻擊灰盒測(cè)試

之前講過(guò)，HTTP走私攻擊所利用的漏洞是，某些精心構(gòu)造的HTTP消息會(huì)隨不同的代理（瀏覽器、web緩存、應(yīng)用程序防火墻）而做不同的解釋。 這種攻擊方法是由Chaim Linhart、Amit Klein、Ronen Heled和Steve Orrin于2005年發(fā)現(xiàn)的。這種攻擊有多種用途，我們這里僅介紹最雷人的一種：繞過(guò)應(yīng)用程序防火墻。

下面，我們?cè)敿?xì)介紹利用HTTP走私攻擊繞過(guò)應(yīng)用程序防火墻的詳細(xì)方法。有許多應(yīng)用防火墻都能根據(jù)一些已知的嵌入請(qǐng)求的惡意模式來(lái)檢測(cè)和阻止懷有惡意的web請(qǐng)求。舉例來(lái)說(shuō)，針對(duì)IIS服務(wù)器的Unicode目錄遍歷攻擊能夠通過(guò)提交一個(gè)類似下面所示的一個(gè)請(qǐng)求發(fā)動(dòng)攻擊：

圖4

當(dāng)然，通過(guò)檢查URL是否存在類似“..”和“cmd.exe”的字符串可以很容易地檢測(cè)和過(guò)濾掉這種攻擊。然而，IIS 5.0對(duì)于POST請(qǐng)求主體的長(zhǎng)度是有要求的，最多為48K字節(jié)——當(dāng)Content-Type頭部不同于application/x-www-form-urlencoded時(shí)，超出該限制的部分會(huì)被全部截?cái)?。攻擊者可以利用這一點(diǎn)來(lái)創(chuàng)建一個(gè)很大的請(qǐng)求，如下所示：

圖5

這里，Request #1由49223字節(jié)內(nèi)容組成，所以Request #1還包含了Request #2的幾行內(nèi)容。因此，防火墻(或者其他任何代理)會(huì)看到Request #1，但是卻無(wú)法看到Request #2(它的數(shù)據(jù)正好是#1請(qǐng)求的一部分），能夠看到Request #3卻會(huì)遺漏Request #4(因?yàn)樵揚(yáng)OST正好是偽造的頭部xxxx部分）?，F(xiàn)在，IIS 5.0將會(huì)發(fā)生什么情況？它將在49152字節(jié)無(wú)用信息之后停止對(duì)Request #1的解析，因?yàn)檫@已經(jīng)達(dá)到了48K=49152字節(jié)的限制，并將Request #2解析為一個(gè)新的、單獨(dú)的請(qǐng)求。Request #2聲稱它的內(nèi)容為33字節(jié)，包括xxxx :之前的所有內(nèi)容，這使得IIS會(huì)漏掉Request #3，因?yàn)镽equest #3被解釋為Request #2的一部分，但是IIS會(huì)認(rèn)出Request #4，因?yàn)樗腜OST是從Request #2的第33個(gè)字節(jié)之后開(kāi)始的。當(dāng)然，這看起來(lái)有些復(fù)雜，但是卻很好的解釋了為什么該攻擊性URL不會(huì)被防火墻發(fā)現(xiàn)，卻能被IIS正確解析和執(zhí)行的原因所在。

在上面的情形中，雖然我們利用的是web服務(wù)器中的安全漏洞，但是在其他情形中，我們可以通過(guò)利用各種支持HTTP的設(shè)備在解析不兼容1005 RFC的消息時(shí)所采取的方式各不相同來(lái)發(fā)動(dòng)攻擊。舉例來(lái)說(shuō)，HTTP協(xié)議只允許一個(gè)Content-Length頭部，但是卻沒(méi)有規(guī)定如何處理具有兩個(gè)Content-Length頭部的消息。一些實(shí)現(xiàn)將使用第一個(gè)，而另一些實(shí)現(xiàn)則使用第二個(gè)，這種情況下就很容易遭到HTTP走私的攻擊。另一個(gè)例子是GET消息中Content-Length頭部的使用。

五、小結(jié)

在本文中，我們?cè)敿?xì)為讀者介紹了針對(duì)HTTP截?cái)嗪虷TTP走私攻擊的安全測(cè)試技術(shù)。我們通過(guò)實(shí)例演示了如何利用HTTP協(xié)議的某些特性，或者利用Web應(yīng)用程序的弱點(diǎn)或者不同代理對(duì)HTTP消息的解釋也不相同的特點(diǎn)來(lái)發(fā)動(dòng)這兩種攻擊。希望本文對(duì)讀者的安全測(cè)試工作有所幫助。

【51CTO.COM 獨(dú)家特稿，轉(zhuǎn)載請(qǐng)注明出處及作者！】

【編輯推薦】

1. 企業(yè)級(jí)Web安全滲透測(cè)試之SSL篇
2. Web安全測(cè)試之跨站請(qǐng)求偽造（CSRF）篇