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響應頭中。（XSS一般輸出在主體中）
所以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 首部字段。
作者：安全小白團
鏈接：https://www.jianshu.com/p/2f2e311e797b
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯系作者獲得授權並注明出處。