白帽子挖洞—跨站請求偽造（CSRF）篇

0x00介紹

CSRF（Cross-site

request forgery）跨站請求偽造，也被稱為「One Click Attack」或者Session Riding，通常縮寫為CSRF或者XSRF，是一種對網站的惡意利用。儘管聽起來像跨站腳本（XSS），但它與XSS非常不同，XSS利用站點內的信任用戶，而CSRF則通過偽裝來自受信任用戶的請求來利用受信任的網站。主要利用受害者尚未失效的身份認證信息（cookie、會話等），誘騙其點擊惡意鏈接或者訪問包含攻擊代碼的頁面，在受害人不知情的情況下以受害者的身份向（身份認證信息所對應的）伺服器發送請求，從而完成非法操作（如轉賬、改密等）。CSRF與XSS最大的區別就在於，CSRF並沒有盜取cookie而是直接利用

對於初學者而言，找漏洞最好是基於白盒審計進行，所謂白盒審計可以簡單地理解為就是看著代碼找漏洞，那麼在正式挖洞前，我們先看看開源的DVWA給出的四種級別的CSRF的源代碼。

0x01 基於dvwa的代碼審計

DVWA 的代碼分為四種安全級別：Low，Medium，High，Impossible。初學者可以通過比較四種級別的代碼，接觸到入門級別的代碼審計的內容。

DWVA使用界面

跨站請求偽造（CSRF）

在左下角的DVWA Security可以調節難度係數，即low,medium,high,impossible選中後點擊submit提交即可。

點擊左下角view source可以看到源代碼，方便進行代碼審計

我們可以看到四種級別的代碼分別如下所示：

Low級別代碼：

分析關鍵代碼：

可以看到：

伺服器只檢查參數password_new與password_conf是否相同，如果相同，就可以進行修改密碼的操作，整個過程中並沒有任何的防CSRF機制（cookie、會話等）

medium級別代碼：

分析關鍵代碼：

可以看到：

Medium級別的代碼引入了eregi函數，Eregi函數的原理是用來檢驗第二個參數中是否含有第一個參數，並且Eregi不區分大小寫，在此處的代碼中，該函數起到的作用為檢查HTTP_REFERER中是否包含SERVER_NAME，如果包含，則符合條件，繼續進行接下來的操作。代碼希望通過這種機制來抵禦CSRF攻擊。

High級別代碼：

分析：

關鍵代碼：

可以看到：

High級別的帶入引入了Anti-CSRF

token,每次修改密碼伺服器會通過generateSessionToken()隨機生成一個token，只有客戶端提交的token參數與伺服器端一致時，伺服器端才會處理客戶端的響應。

Impossible代碼

分析：

關鍵代碼：

可以看到：

Impossible級別的代碼在medium、high級別的基礎上引入了PDO，同時需要客戶端在修改密碼時必須正確輸入原密碼才能進行修改操作。如果不知道原密碼，則無法進行CSRF攻擊。

0x02挖掘漏洞

註：下文的提到的漏洞均已獲授權進行測試，並交由廠商修復。

先來一枚最簡單的CSRF的漏洞（很多師傅在挖洞的過程中總是會天馬行空地秀很多花樣姿勢，在這枚漏洞中，本來漏洞本身的危害是非常小的，但是結合蠕蟲，就會導致一定的危害）

這次介紹的漏洞就是大部分學校要求大一新生強制安裝的XX產品

在XX產品的發送動態處抓包

可以看到post包中沒有加token，也沒有驗證refer，可以引發CSRF

開始構造我們的POC

該poc執行會自動發送一條動態，內容為：班上的成績已經出來了，沒想到我會進步這麼多。成績表：http://dwz.cn/1u18Ys

效果如圖

實際上，當不明真相的吃瓜群眾點擊鏈接時，其實就觸發了我們構造的POC，此時，群眾們的帳號就會不知不覺間發出同樣內容的動態。

這樣子，就形成了可以廣泛傳播的蠕蟲

總結：這個危害並不是很大，而且早已被修復，該漏洞的難度類似於DVWA中的低級別漏洞

第二枚漏洞：

某網站查看個人已發表的評論處如圖：

同樣，我們還是構造一個POC

Html關鍵代碼如下：

其中，我們使用了<img>標籤，地址為刪除文章的鏈接

如果正常用戶訪問此頁面，將會得到如下頁面

圖片無法訪問，不過img中的地址鏈接還是正常執行了，此時如果用戶回到個人中心，會發現，自己發表的東西已被刪除

總結：這個漏洞涉及的代碼層次也是屬於DVWA的low級別的

再來枚類似的漏洞，通過這枚漏洞我們可以修改收貨地址

此漏洞存在於某音樂播放器的PC端

我們在修改地址的部分抓包

注意到此處我們post時沒喲token或referer

這就好辦了，我們構造一個form表單

接下來登陸收貨地址的頁面

可以看到我們POC中的內容成功地被修改在了收貨地址處

總結：此漏洞的強度也近似於DVWA的low級別

0x03資源推薦

代碼審計方面可以使用法師尹毅（Seay）的源代碼審計系統

DVWA方面的實際操作可以登陸合天網安實驗室進行練習，連接如下：

http://www.hetianlab.com/cour.do?w=1&c=C172.19.104.182015061009315500001

抓包改包看參數的神器burpsuite在合天網安實驗也有相應課程，連接如下：

http://www.hetianlab.com/cour.do?w=1&c=C172.19.104.182014112610353900001

0x04經驗心得

CSRF漏洞的分類及檢測挖掘方法主要有三種：

第一種：

請求直接是個GET請求，然後請求中沒有token驗證參數，然後還有一個固定的變數可以被控制。這種是比較常見的一種CSRF漏洞。

檢測方法：

網頁操作某功能，抓包後，如果發現滿足上麵條件，然後再去頁面測試下，基本就可以確定存在不存在CSRF漏洞了。

第二種：

請求是個POST請求，post請求中沒有token參數，然後請求也沒有驗證referer信息。這種是存在CSRF情況最多的一種。

檢測方法：

網頁操作某功能，抓包後，如果發現沒有token等參數，然後就將referer信息設置為空，再次發包請求，如果請求成功了，就說明這裡有CSRF漏洞。如果有token等參數，可以嘗試將token去掉，然後再將referer也去掉，進行驗證。這種CSRF漏洞的利用，是需要在自己伺服器構造一個form表單的，然後將伺服器form表單的URL作為CSRF攻擊進行利用的，或者用js代碼生成form表單，或者用ajax實現。

第三種：

請求是POST，post請求中沒有token參數，但是驗證了referer信息。然而可以將post請求改寫為get請求，然後通過第一種情況下的那個方法利用。

檢測方法：

就是先執行了第二種的驗證後，發現有對CSRF進行防禦。然後將post請求改寫為GET請求，發現仍然可以成功執行。漏洞成因是因為伺服器端接收請求參數的時候，沒有嚴格的用$_POST 而是用的類似於 $_REQUEST這種post，get請求的參數都可以接收的寫法。

以上為作者結合自身經驗及參考其他師傅的想法總結出來的，歡迎大家留言討論其他想法、姿勢。

0x05防護措施

主要可以應用以下介紹的幾種方法：

限制驗證cookie的到期時間：

這些cookie的合法時間越短，黑客利用你的Web應用程序的機會就越小。不過，這個時間越短，用戶就越不方便。因此，你需要在安全性和方便性之間進行平衡。

執行重要業務之前，要求用戶提交額外的信息：

要求用戶在進行重要業務前輸入口令，這可以防止黑客發動CSRF攻擊（只要瀏覽器中沒有包含口令），因為這種重要信息無法預測或輕易獲得。

使用秘密的無法預測的驗證符號：

當保存在用戶瀏覽器中的cookie僅由一次會話確認時，CSRF攻擊才會有效。所以在每次HTTP請求（當然攻擊者無法提前知道）中都有附加的特定會話的信息，這樣就可以挫敗CSRF攻擊。不過，如果這種應用程序存在跨站腳本漏洞，黑客就有可能訪問這種驗證符號。

使用定製的HTTP報頭：

如果執行交易的所有請求都使用XMLHttpRequest並附加一個定製的HTTP報頭，同時拒絕缺少定製報頭的任何請求，就可以用XMLHttpRequest

API來防禦CSRF攻擊。由於瀏覽器通常僅准許站點將定製的HTTP報頭髮送給相同站點，從而了防止由CSRF攻擊的源站點所發起的交易。

檢查訪問源的報頭：

在瀏覽者發送HTTP請求時，它通常會包含源自訪問源報頭的URL。理論上講，你可以使用這些信息來阻止源自其它任何站點（而不是來自Web應用程序自身）的請求。不過，訪問源報頭並不總是可用的，（例如，有些單位由於私密性的緣故而將它剝離了），或者這個報頭容易被欺騙，所以說，這條措施並不真正有效。

0x06聲明

本系列文章旨在普及網路安全知識，提高小夥伴的安全意識的同時介紹常見漏洞的特徵、挖掘技巧等。若讀者因此做出危害網路安全的行為後果自負，與合天智匯無關，特此聲明。

更多乾貨關注「合天智匯」微信公眾號學習喲！

推薦閱讀：