1. 程式人生 > >新浪某站CRLF Injection導致的安全問題

新浪某站CRLF Injection導致的安全問題

study 安全 div 閱讀 並且執行 comm 說明 ref 六月

CRLF攻擊的一篇科普:新浪某站CRLF Injection導致的安全問題(轉)

轉:https://www.leavesongs.com/PENETRATION/Sina-CRLF-Injection.html

新浪某站CRLF Injection導致的安全問題

PHITHON 2014 六月 30 06:45 閱讀:3714 網絡安全 HRS, CRLF, xss

CRLF Injection很少遇見,這次被我逮住了。我看zone中(http://zone.wooyun.org/content/13323)還有一些同學對於這個漏洞不甚了解,甚至分不清它與CSRF,我詳細說一下吧。

CRLF是”回車 + 換行”(\r\n)的簡稱。在HTTP協議中,HTTP Header與HTTP Body是用兩個CRLF分隔的,瀏覽器就是根據這兩個CRLF來取出HTTP 內容並顯示出來。所以,一旦我們能夠控制HTTP 消息頭中的字符,註入一些惡意的換行,這樣我們就能註入一些會話Cookie或者HTML代碼,所以CRLF Injection又叫HTTP Response Splitting,簡稱HRS。

HRS是比XSS危害更大的安全問題,具體是為什麽,我們往下看。

對於HRS最簡單的利用方式是註入兩個\r\n,之後在寫入XSS代碼,來構造一個xss。

舉個例子,一般網站會在HTTP頭中用Location: http://baidu.com這種方式來進行302跳轉,所以我們能控制的內容就是Location:後面的XXX某個網址。

所以一個正常的302跳轉包是這樣:

HTTP/1.1 302 Moved Temporarily 
Date: Fri, 27 Jun 2014 17:52:17 GMT 
Content-Type: text/html 
Content-Length: 154 
Connection: close 
Location: http://www.sina.com.cn

但如果我們輸入的是

http://www.sina.com.cn%0aSet-cookie:JSPSESSID%3Dwooyun

註入了一個換行,此時的返回包就會變成這樣:

HTTP/1.1 302 Moved Temporarily 
Date: Fri, 27 Jun 2014 17:52:17 GMT 
Content-Type: text/html 
Content-Length: 154 
Connection: close 
Location: http://www.sina.com.cn 
Set-cookie: JSPSESSID=wooyun

這個時候這樣我們就給訪問者設置了一個SESSION,造成一個“會話固定漏洞”。

當然,HRS並不僅限於會話固定,通過註入兩個CRLF就能造成一個無視瀏覽器Filter的反射型XSS。

比如一個網站接受url參數http://test.sina.com.cn/?url=xxx,xxx放在Location後面作為一個跳轉。如果我們輸入的是:

http://test.sina.com.cn/?url=%0d%0a%0d%0a<img src=1 onerror=alert(/xss/)>

我們的返回包就會變成這樣:

HTTP/1.1 302 Moved Temporarily 
Date: Fri, 27 Jun 2014 17:52:17 GMT 
Content-Type: text/html 
Content-Length: 154 
Connection: close 
Location:

<img src=1 onerror=alert(/xss/)>

之前說了瀏覽器會根據第一個CRLF把HTTP包分成頭和體,然後將體顯示出來。於是我們這裏<img>這個標簽就會顯示出來,造成一個XSS。

為什麽說是無視瀏覽器filter的,這裏涉及到另一個問題。

瀏覽器的Filter是瀏覽器應對一些反射型XSS做的保護策略,當url中含有XSS相關特征的時候就會過濾掉不顯示在頁面中,所以不能觸發XSS。

怎樣才能關掉filter?一般來說用戶這邊是不行的,只有數據包中http頭含有X-XSS-Protection並且值為0的時候,瀏覽器才不會開啟filter。

說到這裏應該就很清楚了,HRS不正是註入HTTP頭的一個漏洞嗎,我們可以將X-XSS-Protection:0註入到數據包中,再用兩個CRLF來註入XSS代碼,這樣就成功地繞過了瀏覽器filter,並且執行我們的反射型XSS。

所以說HRS的危害大於XSS,因為它能繞過一般XSS所繞不過的filter,並能產生會話固定漏洞。

我們來一個真實案例吧。

新浪某分站含有一個url跳轉漏洞,危害並不大,於是我就想到了CRLF Injection,當我測試

http://xxx.sina.com.cn/?url=%0a%0d%0a%0d%3Cimg%20src=1%3E

的時候,發現圖片已經輸出在頁面中了,說明CRLF註入成功了:

那麽我們試試XSS看看:

技術分享

看控制臺,果然被XSS Filter攔截了。

那麽我們就註入一個X-XSS-Protection:0到數據包中,看看什麽效果:

@mramydnei 還想到了一個利用字符編碼來繞過XSS Filter的方法,當編碼是is-2022-kr時瀏覽器會忽略%0f,這樣我們在onerror後面加個%0f就能繞過filter,前提是註入一個<meta charset=ISO-2022-KR>

當然,在Location:這裏註入只有webkit內核瀏覽器才能夠利用,其他瀏覽器可能會跳轉、出錯。不過對於chrome的使用量來說,危害已經足夠了。

如何修復HRS漏洞,當然是過濾\r 、\n之類的換行符,避免輸入的數據汙染到其他HTTP頭。

新浪某站CRLF Injection導致的安全問題