01漏洞描述

在《HTTP | HTTP報文》一文中，我們介紹了HTTP報文的結構：狀態行和首部中的每行以CRLF結束，首部與主體之間由一空行分隔。或者理解為首部最後一個欄位有兩個CRLF，首部和主體由兩個CRLF分隔。

CRLF注入漏洞，是因為Web應用沒有對使用者輸入做嚴格驗證，導致攻擊者可以輸入一些惡意字元。攻擊者一旦向請求行或首部中的欄位注入惡意的CRLF，就能注入一些首部欄位或報文主體，並在響應中輸出，所以又稱為HTTP響應拆分漏洞（HTTP Response Splitting）。

02漏洞知識拓展

CRLF 指的是回車符(CR，ASCII 13，\r，%0d) 和換行符(LF，ASCII 10，\n，%0a)。

CRLF的概念源自打字機，表明行的結束，計算機出現後沿用了這個概念。

回車符：游標移到行首，

換行符：游標垂直移到下行。

鍵盤上的回車鍵(Enter)就可以執行該操作。但是不同的作業系統，行的結束符是不一樣的。

Windows：使用CRLF表示行的結束

Linux/Unix：使用LF表示行的結束

MacOS：早期使用CR表示，現在好像也用LF表示行的結束

所以同一檔案在不同作業系統中開啟，內容格式可能會出現差異，這是行結束符不一致導致的。

在HTTP規範中，行應該使用CRLF來結束。首部與主體由兩個CRLF分隔，瀏覽器根據這兩個CRLF來獲取HTTP內容並顯示。

03漏洞檢測

CRLF注入漏洞的本質和XSS有點相似，攻擊者將惡意資料傳送給易受攻擊的Web應用程式，Web應用程式將惡意資料輸出在HTTP響應頭

所以CRLF注入漏洞的檢測也和XSS漏洞的檢測差不多。通過修改HTTP引數或URL，注入惡意的CRLF，檢視構造的惡意資料是否在響應頭中輸出。

找到輸入點，構造惡意的CRLF字元

正常請求

抓包，在請求行的url引數中加入特殊構造的CRLF字元，如下圖示記所示。

檢視惡意資料是否在響應頭中輸出

將修改後的請求包提交給伺服器端，檢視伺服器端的響應。發現響應首部中多了個Set-Cookie欄位。這就證實了該系統存在CRLF注入漏洞，因為我們輸入的惡意資料，作為響應首部欄位返回給了客戶端。

很多人看到這裡可能就想不明白，我請求包寫入的惡意資料，怎麼就被當成響應首部欄位輸出了？下面我們來看看伺服器端原始碼。

這是其中一段程式碼，用PHP寫的，需要大家有一定的語言基礎。看不懂也沒關係，我後期會寫PHP系列文章。這段程式碼的意思是：當條件滿足時，將請求包中的url引數值拼接到Location字串中，並設定成響應頭髮送給客戶端。

此時伺服器端接收到的url引數值是我們修改後的：

http://itsecgames.blogspot.com%0d%0aSet-Cookie:crlf=true

在url引數值拼接到Location字串中，設定成響應頭後，響應包此時應該是下圖這樣的：

%0d和%0a分別是CR和LF的URL編碼。前面我們講到，HTTP規範中，行以CRLF結束。所以當檢測到%0d%0a後，就認為Location首部欄位這行結束了，Set-Cookie就會被認為是下一行，如下圖所示。

而我們構造的Set-Cookie字元在HTTP中是一個設定Cookie的首部欄位，這個時候就會將crlf=true設定成Cookie。

重新請求，抓包，發現Cookie中多了crlf=true。

測試的用例大家可能會覺得這漏洞沒什麼危害性，但試想一下：利用漏洞，注入一個CRLF控制使用者的Cookie，或者注入兩個CRLF，控制返回給客戶端的主體，該漏洞的危害不亞於XSS。

04漏洞修復

過濾 \r 、\n 之類的行結束符，避免輸入的資料汙染其他 HTTP 首部欄位。

-----------------------------------------------

慢慢的，你總會發現，你的努力沒有白費。