HTTP Spliting(拆分)
HTTP Spliting攻擊講解
之所以會出現http拆分是因爲客戶端和服務器端每一次交互的結束標誌、存在重定向和對於服務器端響應的消息在客戶端是以消息隊列的方式存在的。當客戶端向服務器發出一個請求的時候，有時候這個請求要求服務器給我們重定向到其他的地址，這是服務器會返回給客戶端一個302的重定向信息，並以Location標籤給出重定向之後的訪問地址，客戶端收到服務器端的重定向數據後會向Location所指的地址發送訪問請求。
在http響應中，瀏覽器會根據content-length:0向下尋找到換行爲止作爲一個響應的結束，然後將所有的響應以消息隊列的形式存起來。如果我們可以構造特殊的參數使得瀏覽器收到重定向消息的時候，將收到的一個響應當做兩個響應，那麼我們的第二個響應就會被存入消息響應隊列中，接着瀏覽器就會根據Location的地址，進行重定向的請求，這時候由於我們構造的第二個響應已經存在於消息隊列，則瀏覽器會直接把它拿來當做我們重定向請求後得到的響應。這樣我們就可以用自己構造的頁面替代用戶訪問的頁面，進而施行釣魚攻擊等。
如表1所示的內容，瀏覽器在收到服務器端的響應之後首先根據Content-length: 0 加換行將消息分爲兩個響應並加入消息隊列，其次取出第一個響應的消息發現是一個302的重定向，則會向Location的地址發送請求，這是瀏覽器檢測到自己的消息隊列中由內容存在，也就是我們第一次請求得到的第二個響應消息，它會直接把這個響應消息當做重定向請求得到的響應。（在下面我們以不同顏色標出了兩次響應消息）
|
HTTP/1.1 302 Moved Temporarily Server: Apache-Coyote/1.1 Location: http://localhost/WebGoat/attack?Screen=3&menu=100&fromRedirect=yes&language=hahaha Content-Type: text/html;charset=ISO-8859-1 Content-length: 0
HTTP/1.1 200 OK Content-tpye:Content-Type: text/html;charset=ISO-8859-1 Content-length:19 <html>hacked</html> Date: Sat, 02 Jan 2016 11:12:55 GMT X-RevealHidden: possibly modified |
表 1
HTTP Spliting攻擊
HTTP Spliting攻擊就是基於這個簡單的原理，我們可以通過添加CR和LF（換行）對響應消息進行拆分，在WebGoat Http Spliting攻擊中“hahaha”是我們輸入的參數，現在我們需要利用換行將我們的參數變成之前我們參數那行後面所有的數據，然後在輸入框中輸入。即表2的內容（記得需要進行UrlEncod轉碼）
|
hahaha Content-Type: text/html;charset=ISO-8859-1 Content-length: 0
HTTP/1.1 200 OK Content-tpye:text/html;charset=ISO-8859-1 Last-Modified: Thu, 01 Jan 2099 12:00:00 GMT Content-length:19 <html>hacked</html> Date: Sat, 02 Jan 2016 11:12:55 GMT X-RevealHidden: possibly modified |
表 2
轉碼後內容見表3，將表3的內容輸入我們的輸入框進行提交則會發現重定向成功。
|
hahaha%0d%0aContent-Type%3a+text%2fhtml%3bcharset%3dISO-8859-1%0d%0aContent-length%3a+0%0d%0a%0d%0aHTTP%2f1.1+200+OK%0d%0aContent-tpye%3atext%2fhtml%3bcharset%3dISO-8859-1%0d%0aContent-length%3a19%0d%0a%26lt%3bhtml%26gt%3bhacked%26lt%3b%2fhtml%26gt%3b%0d%0aDate%3a+Sat%2c+02+Jan+2016+11%3a12%3a55+GMT%0d%0aX-RevealHidden%3a+possibly+modified |
表 3
圖1是我們提交數據之後，Webscarab截獲的客戶端請求數據。
圖 1
HTTP Spliting攻擊和緩衝區中毒
當然，到此爲止，你可能會有疑問，這一系列操作不是在黑自己嗎？誰那麼傻，還給自己重定向。是的，我起初剛學的時候也是這麼想的。但是當你接着往下做的時候你會發現HTTP拆分攻擊其實是需要配合緩存中毒一起使用的。緩衝區中毒攻擊的目標是使緩存中毒，欺騙緩存，使其相信HTTP拆分的頁面是一個很正常的頁面，是一個服務器的副本。
換句話說吧，當我們通過代理服務器去訪問外網的時候，代理服務器並不是每一次都會請求新的頁面它和瀏覽器一樣都會有緩存，首先它會根據時間判斷緩存是否過期，是否需要向外面請求，這時就會用到一個標籤Last-modified，服務器會判斷在這個時間之後你所訪問的頁面是否被修改過，如果沒有被修改則從本地緩存中取出，否則向外部請求頁面，如果我們將Last-modified這個標籤的內容指定到未來的一個時間，則在現在看來這個頁面在這個時間之後是不可能被修改的，也就是會從緩衝區取出這個頁面，這是其他用戶訪問這個頁面的時候，由於我們對這個頁面的Last-modified標籤設置了一個未來的時間，則他們拿到的實際上是我們僞造的頁面。
既然他們訪問的頁面是我們僞造的，那我們豈不是想幹什麼就幹什麼了嗎，哈哈哈，對的我們就可以利用這一點對其進行釣魚攻擊，進而獲取用戶的信息。
那接下來我們進行304攻擊，即剛剛我們提到的“沒有修改”攻擊。這是我們只需在我們上一步的那個僞造輸入參數的第二個響應中加入如下信息：
Last-Modified: Thu, 01 Jan 2100 12:00:00 GMT
這個時間的格式規定的，最後的那個GMT指的的格林尼治時間，然後我們再對其進行URLEncode編碼得到如表4所示數據，在輸入框中輸入之後我們就會發現304響應出現了，即我們將HTTP拆分和緩衝區中毒成功的用在了一起。
|
hahaha%0d%0aContent-Type%3a+text%2fhtml%3bcharset%3dISO-8859-1%0d%0aContent-length%3a+0%0d%0a%0d%0aHTTP%2f1.1+200+OK%0d%0aContent-tpye%3atext%2fhtml%3bcharset%3dISO-8859-1%0d%0aLast-Modified%3a+Thu%2c+01+Jan+2099+12%3a00%3a00+GMT%0d%0aContent-length%3a19%0d%0a%26lt%3bhtml%26gt%3bhacked%26lt%3b%2fhtml%26gt%3b%0d%0aDate%3a+Sat%2c+02+Jan+2016+11%3a12%3a55+GMT%0d%0aX-RevealHidden%3a+possibly+modified |
表 4
HTTP Spliting攻擊防禦
（1）首先我們知道，之所以存在HTTP拆分攻擊是由於重定向的時候沒有做好響應結束符的控制，即CR和LF的控制，則我們可以對CR和LF換行符進行過濾或者編碼處理；
（2）還有一點我們不容忽視的就是客戶端接受服務器端響應消息的行爲，我們可以一次接受所有的消息而不是分開接受，或者說將多餘的消息拋掉，這樣也可以有效避免HTTP拆分攻擊；
（3）緩衝區中毒是由於Last-modified所指時間是一個未來的時間，我們可以根據判斷所指時間是否合法來控制緩衝區中毒現象；
然而現在的主流Web服務器比如IIS，Apache HTTP Server以及WebGoat使用的Tomcat等等都已經對這個問題作過了改進，服務器會對即將發送出去的HTTP響應頭裏面每一項的值都會做一定的編碼或者轉換，以避免這個問題。比如Tomcat就響應頭中的每一項的值都做過了URLEncode，從而保證即使Web應用存在HTTP應答拆分的漏洞，Web服務器上也從底層平臺的角度保證了儘可能避免HTTP應答拆分漏洞帶來的威脅。所以如果想要在自己的實驗室環境中重現對HTTP應答拆分漏洞的成功利用，可以嘗試安裝比較老的Web服務器版本，比如Tomcat 4.1.24之前的版本。另外客戶端也會有些關係，因爲客戶端可能會在每次請求後完全收取服務器響應回來的數據，並且把超出範圍的多餘數據丟棄，這樣也可以避免HTTP應答拆分攻擊可能造成的影響。