實戰Web安全測試之HTTP截斷(走私漏洞篇)
原創【51CTO.com獨家特稿】在本文中，我們將詳細為讀者介紹針對HTTP截斷和HTTP走私攻擊的安全測試技術。我們將通過實例演示如何利用HTTP協議的某些特性，或者利用Web應用程序的弱點或者不同代理對HTTP消息的解釋也不相同的特點來發動這兩種攻擊。
一、HTTP截斷/走私漏洞概述
本文遏制，我們將分析針對特定的HTTP報頭的兩種不同的攻擊技術：HTTP截斷和HTTP走私攻擊。對于HTTP截斷攻擊而言，它是利用了缺乏輸入消毒措施的漏洞，該漏洞允許入侵者向應用程序響應的頭部插入CR和LF字符，從而將響應分割為兩個不同的HTTP消息。該攻擊的目標既不同于緩存投毒，也區別于跨站腳本攻擊。對于第二種攻擊方法，攻擊者利用了這樣的一個事實，即一些專門精心制作的HTTP消息可能會隨著接收它們的代理的不同，而作不同的解析和解釋。HTTP走私技術要求對處理HTTP消息的各種代理相當熟悉，否則無法發動這種攻擊。
下面我們介紹這些漏洞的黑盒測試和灰盒測試技術。
二、HTTP截斷攻擊黑盒測試
一些web應用程序會使用部分用戶輸入來生成它們的響應頭部的某些值，這方面最簡單的例子就是重定向了，因為目標URL依賴于用戶提交的某些值。舉例來說，假如用戶被要求在標準web接口和高級web接口之間做出選擇，然后，選擇的結果將作為一個參數傳遞，并且這個參數將用于觸發重定向到相應的頁面的應答頭中。更確切地說，如果該參數interface的值是advanced，那么應用程序將響應下列內容：
 |
| 圖1 |
收到這個消息后，瀏覽器會把用戶引向Location頭部規定的頁面。然而，如果應用程序沒有對用戶輸入進行過濾的話，攻擊者就可以在參數interface中插入序列%0d%0a，而該序列代表的則是用于分割各行的CRLF（回車換行）序列。這樣一來，攻擊者將能夠觸發一個響應，重要的是任何解析器（例如介于用戶和Web應用之間的web緩存）都會把這個響應會被解釋為兩個不同的響應。所以，攻擊者就可以通過給這個web緩存“投毒”以使它為后續的請求中提供虛假的內容。例如，在我們前面的例子中，假設攻擊者將下列內容作為參數interface進行傳遞：
 |
| 圖2 |
從存在漏洞的軟件（也就是沒有對用戶輸入進行嚴格消毒的應用程序）中得到的響應將是下面的內容：
 |
| 圖3 |
Web緩存將看到兩個不同的響應，因此如果攻擊者發送第一個請求之后立即發送對/index.html頁面的請求的話，web緩存會認為這個請求與第二個響應相匹配，并緩存它的內容，這樣一來后面經由web緩存的所有指向victim.com/index.html的請求都會收到系統故障消息，即“system down”。通過這種方式，一個攻擊者將能有效涂改站點在使用web緩存的用戶心中的形象，如果該web緩存是該Web應用程序的一個反向代理的話，那么這個Web應用程序在整個因特網中的用戶都會受到影響。另外，攻擊者還可以向這些用戶傳輸發動跨站腳本攻擊攻擊的JavaScript代碼片斷，例如竊取cookies等。需要注意的是，雖然該安全漏洞位于應用程序中，但是攻擊針對的對象卻是使用該應用程序的用戶。
因此，為了查找這個安全漏洞，滲透測試人員需要識別所有能夠影響響應的一個或多個頭部的用戶輸入，并檢查用戶是否能夠在其中注入一個CR+LF序列。與這個攻擊關系最密切的兩個頭部是：
Location |
需要注意的是，現實中要想成功利用這個安全漏洞可能是件非常復雜的事情，因為有多種因素必須考慮到：
1.攻擊者要想讓偽造的響應被緩存的話，必須正確設置其中的各個頭部，例如Last-Modified頭部的值必須設為將來的一個時間。此外，攻擊者還必須破壞目標頁面先前的緩存版本，方法是提交一個請求頭部中帶有“Pragma: no-cache”的前導請求來防止頁面被緩存。
2. 即使應用程序沒有過濾CR+LF序列，但是仍可能過濾了發動該攻擊所需的其他字符，例如字符<和>等。這時候，攻擊者可以嘗試使用其他編碼，例如UTF-7編碼等。
3. 某些攻擊目標（例如ASP）會對Location頭部（例如www.victim.com/redirect.asp ）中的路徑部分進行URL編碼處理，這樣就使得CRLF序列不起作用了。然而，它們卻不能對查詢部分（例如?interface=advanced）進行這樣的編碼處理，這意味著放置一個前導問號就能夠繞過這種過濾技術。 #p#
三、HTTP截斷攻擊灰盒測試
對于Web應用程序即攻擊目標的深入了解，在發動HTTP截斷攻擊時是極其有幫助的。例如，不同的攻擊目標可能使用不同的方法來判定第一個HTTP消息在何時終止，第二個HTTP消息從什么時候開始。當然，有時候可以使用消息邊界來進行判定，如上面的例子就是這樣。但是，其他的攻擊目標可能使用不同的數據包來攜帶不同的消息。此外，有些目標會為每個消息分配指定組塊的數量，這種情況下，第二個消息必須從特定的塊開始，這就要求攻擊者在兩個消息之間填充必要的塊。不過，當時有URL發送有弱點的參數的時候，這么做可能會引起一些麻煩，因為過長的URL很可能被截斷或者過濾掉。灰盒測試可以幫助攻擊者找到解決辦法：一些應用程序服務器允許使用POST而非GET來發送請求。
四、HTTP走私攻擊灰盒測試
之前講過，HTTP走私攻擊所利用的漏洞是，某些精心構造的HTTP消息會隨不同的代理（瀏覽器、web緩存、應用程序防火墻）而做不同的解釋。 這種攻擊方法是由Chaim Linhart、Amit Klein、Ronen Heled和Steve Orrin于2005年發現的。這種攻擊有多種用途，我們這里僅介紹最雷人的一種：繞過應用程序防火墻。
下面，我們詳細介紹利用HTTP走私攻擊繞過應用程序防火墻的詳細方法。有許多應用防火墻都能根據一些已知的嵌入請求的惡意模式來檢測和阻止懷有惡意的web請求。舉例來說，針對IIS服務器的Unicode目錄遍歷攻擊能夠通過提交一個類似下面所示的一個請求發動攻擊：
 |
| 圖4 |
當然，通過檢查URL是否存在類似“..”和“cmd.exe”的字符串可以很容易地檢測和過濾掉這種攻擊。然而，IIS 5.0對于POST請求主體的長度是有要求的，最多為48K字節——當Content-Type頭部不同于application/x-www-form-urlencoded時，超出該限制的部分會被全部截斷。攻擊者可以利用這一點來創建一個很大的請求，如下所示：
 |
| 圖5 |
這里，Request #1由49223字節內容組成，所以Request #1還包含了Request #2的幾行內容。因此，防火墻(或者其他任何代理)會看到Request #1，但是卻無法看到Request #2(它的數據正好是#1請求的一部分），能夠看到Request #3卻會遺漏Request #4(因為該POST正好是偽造的頭部xxxx部分）。現在，IIS 5.0將會發生什么情況？它將在49152字節無用信息之后停止對Request #1的解析，因為這已經達到了48K=49152字節的限制，并將Request #2解析為一個新的、單獨的請求。Request #2聲稱它的內容為33字節，包括xxxx :之前的所有內容，這使得IIS會漏掉Request #3，因為Request #3被解釋為Request #2的一部分，但是IIS會認出Request #4，因為它的POST是從Request #2的第33個字節之后開始的。當然，這看起來有些復雜，但是卻很好的解釋了為什么該攻擊性URL不會被防火墻發現，卻能被IIS正確解析和執行的原因所在。
在上面的情形中，雖然我們利用的是web服務器中的安全漏洞，但是在其他情形中，我們可以通過利用各種支持HTTP的設備在解析不兼容1005 RFC的消息時所采取的方式各不相同來發動攻擊。舉例來說，HTTP協議只允許一個Content-Length頭部，但是卻沒有規定如何處理具有兩個Content-Length頭部的消息。一些實現將使用第一個，而另一些實現則使用第二個，這種情況下就很容易遭到HTTP走私的攻擊。另一個例子是GET消息中Content-Length頭部的使用。
五、小結
在本文中，我們詳細為讀者介紹了針對HTTP截斷和HTTP走私攻擊的安全測試技術。我們通過實例演示了如何利用HTTP協議的某些特性，或者利用Web應用程序的弱點或者不同代理對HTTP消息的解釋也不相同的特點來發動這兩種攻擊。希望本文對讀者的安全測試工作有所幫助。
【51CTO.COM 獨家特稿，轉載請注明出處及作者！】
【編輯推薦】
