DVWA系列之18 CSRF漏洞分析

下面我們來查看一下low級別的CSRF源碼：

代碼中在獲取了$pass_new和$pass_conf這兩個變量之后，利用mysql_real_escape_string()函數進行了過濾，這樣雖然可以防止SQL注入，但卻無法阻止CSRF***，之后這兩個變量便被直接代入UPDATE語句中執行了數據庫更新操作。

下面再來分析一下medium級別的代碼：

可以看到這里在獲取$pass_new和$pass_conf這兩個變量之前，先利用一個if語句來判斷“$_SERVER['HTTP_REFERER']”的值是否是127.0.0.1。這是一種基本的防御CSRF***的方法：驗證HTTP Referer字段。我們可以再次使用之前的方法來實施CSRF***，可以發現已經不起作用了。下面就來解釋一下這種防御方法的原理。

根據HTTP協議，在HTTP頭中有一個字段叫Referer，它記錄了該HTTP請求的來源地址。比如下面這個利用Burpsuite攔截到的數據包，數據要提交到的頁面是upfile_Other.asp，而我們是通過Referer字段后的http://192168.80.131/upload_Other.asp這個頁面發起的請求。

在通常情況下，訪問一個安全受限頁面的請求應來自于同一個網站，比如需要訪問 http://bank.example/withdraw?account=bob&amount=1000000&for=Mallor，用戶必須先登陸 bank.example，然后通過點擊頁面上的按鈕來觸發轉賬事件。這時，該轉帳請求的Referer值就會是轉賬按鈕所在的頁面的URL，通常是以bank.example域名開頭的地址。而如果***要對銀行網站實施CSRF***，他只能在他自己的網站構造請求，當用戶通過***的網站發送請求到銀行時，該請求的Referer是指向***自己的網站。因此，要防御CSRF***，銀行網站只需要對于每一個轉賬請求驗證其Referer值，如果是以bank.example開頭的域名，則說明該請求是來自銀行網站自己的請求，是合法的。如果Referer是其他網站的話，則有可能是***的CSRF***，拒絕該請求。

在DVWA中，管理員是通過本地地址127.0.0.1來訪問密碼修改頁面的，因而對于任何一個修改密碼的請求，如果其Referer不是127.0.0.1，那么就判斷為CSRF***，而予以拒絕。

然而這種方法并非萬無一失，由于Referer的值是由瀏覽器提供的，對于某些瀏覽器，可以利用一些方法來篡改Referer值。所以***完全可以把用戶瀏覽器的Referer值修改為需要的地址，這樣就可以通過驗證，從而進行 CSRF ***。

另外即使***無法篡改Referer值，這種方法也仍然存在問題。因為Referer值會記錄下用戶的訪問來源，有些用戶認為這樣會侵犯到他們自己的隱私權，特別是有些組織擔心Referer值會把組織內網中的某些信息泄露到外網中。因此，用戶自己可以設置瀏覽器使其在發送請求時不再提供 Referer。當他們正常訪問銀行網站時，網站會因為請求沒有 Referer 值而認為是 CSRF ***，拒絕合法用戶的訪問。

總之，通過驗證HTTP Referer字段來防止CSRF***是不可靠的，這也是為什么DVWA的medium級別采用這種防御方法的原因。但是如何修改用戶端瀏覽器的Referer值來繞過防御，我暫時還沒有查到相關資料，這個問題就暫且擱置，待以后再補上。

最后再來分析一下high級別，首先在界面上就可以看到不同：這里需要管理員首先輸入當前密碼，然后才能重新設置密碼。這就是目前非常有效的一種防御CSRF***的方法：二次確認。

所謂二次確認，就是在調用某些功能時進行二次驗證，如：刪除用戶時，產生一個提示對話框，提示“確定刪除用戶嗎？”。轉賬操作時，要求用戶輸入二次密碼。另外，設置驗證碼也可以起到相同的效果。

當二次驗證后，即使用戶打開漏洞CSRF***頁面，也不會直接去執行，而需要用戶再次輸入才可以完成***。這樣，當用戶突然收到提示后，可能會心存懷疑，就不會再乖乖地中招。