常見的Web漏洞——CSRF

目錄

CSRF簡介

CSRF原理

CSRF攻擊實例

防禦措施

總結


CSRF簡介

CSRF是跨站請求僞造(Cross-site request forgery)的縮寫,和《三十六計》中的“借刀殺人”一樣,只不過是攻擊者借了受害者的“刀”將受害者“殺”了,簡單來講就是攻擊者盜用受害者的身份,以受害者的身份去做自己想要的操作,如發郵件,修改密碼,非法轉賬,獲取隱私數據等。

CSRF原理

當用戶訪問一個存在CSRF漏洞的網站A,並登錄該網站時,瀏覽器會生成一個Cookie,此時攻擊者通過社會工程學或其他手段誘騙用戶在登錄網站A的瀏覽器訪問含有惡意操作(如只允許授權用戶修改密碼,轉賬,對網站或數據庫的增、刪、改、查等操作)的網站B時,用戶在毫不知情的情況下幫助攻擊者完成了修改密碼,轉賬等攻擊者想執行的操作。

CSRF攻擊實例

以DVWA中的CSRF爲例,登錄DVWA,設置安全等級爲Low,然後點擊CSRF,如圖:

可以看到沒有輸入舊密碼的輸入框,簡單嘗試修改密碼發現如果兩個框中輸入的字符串相同就可以修改密碼,如果不相同就無法修改。然後查看源代碼,如圖:

 可以看到客戶端使用GET提交參數後服務器端接收到用戶提交的password_new和password_conf參數之後直接驗證兩者的值是否相同,如果相同就將新密碼的MD5值插入數據庫中,舊密碼的MD5值。因此,直接構造payload:http://192.168.204.133/dvwa/vulnerabilities/csrf/?password_new=abc&password_conf=abc&Change=Change,然後發送給用戶,當用戶在新標籤頁中打開時,如圖:

密碼已被修改爲abc ,而用戶卻毫不知情。當然,這樣的鏈接可以騙過普通人,但是對於瞭解過互聯網或信息安全相關知識的人來說這樣的鏈接目的太明顯。可以通過將鏈接隱藏在網頁源碼中,或將上述payload映射爲短鏈接等來解決這個問題。也可以使用BurpSuite構造Poc然後進行驗證,打開BurpSuite,然後設置瀏覽器代理,使用瀏覽器訪問網站並登錄,然後查看Proxy下HTTP history中的修改密碼的請求,右鍵,如圖:

 然後修改數據爲我們想要的數據,然後點擊Regenerate,如圖:

 然後點擊Test in browser,點擊Copy,如圖:

接着在瀏覽器中打開剛剛copy的url,如圖:

點擊按鈕,成功利用CSRF修改密碼,如圖:

 

設置安全等級爲Medium,查看源代碼,如圖:

可以看到和Low級別的代碼不同之處在於新增了判斷HTTP請求頭中Referer參數的值中是否包含Host參數的值。因此,可以通過創建包含主機IP地址的目錄或文件進行繞過,新建一個文件名爲上述DVWA服務器IP地址的html文件,內容如下:

<html>
<head>
<meta charset="UTF-8"/>
<title>中獎了</title>
</head>
<body>
<h1>恭喜你!中獎了!</h1>
<a href="http://192.168.204.133/dvwa/vulnerabilities/csrf/?password_new=admin&password_conf=admin&Change=Change">領取獎勵</a>
</body>
</html>

 將該文件複製到web服務目錄,然後發送鏈接給用戶,當用戶打開時,如圖:

當用戶點擊領取獎勵時,使用BurpSuite攔截數據包查看,如圖:

可以看到Referer參數的值中包含Host參數中的值,點擊forward即可成功修改密碼。 同理,將上述html文件改爲index.html,放在文件夾192.168.204.133下同樣可以繞過檢測。

設置安全等級爲High,查看源代碼,如圖:

 可以看到當用戶提交參數後,首先會檢查user_token是否正確,只有正確的時候纔可以修改密碼。因此需要提交正確的user_token纔可以利用CSRF修改密碼。

查看網頁源代碼,發現user_token的值,如圖:

 因此可以通過實時獲取user_token的值,然後進行CSRF,由於該token直接寫在了html中,不是標準的json格式,所以即便通過跨域請求訪問來獲取token也行不通,況且現在的瀏覽器安全性很高了,通過JavaScript、iframe等進行跨域請求也無法獲取到該頁面的token。目前還沒找到有效利用的方法,除非讓用戶使用攻擊者設計的瀏覽器或者自己用前端語言去實現一個可以跨域請求http並解析html的代碼。看到很多結合XSS漏洞的,既然用XSS可以獲取到有Cookie了還有必要在發送欺騙連接給用戶讓他點擊嗎?雖然不能有效利用,但是可以使用BurpSuite的CSRF Token Tracker插件驗證該漏洞是否確實存在,設置插件參數,如圖:

然後刷新瀏覽器頁面, 在Repeater模塊發送數據包可以看到每次都可以成功修改密碼,如圖:

 也可以生成Poc然後在瀏覽器新標籤頁中打開,點擊Submit request按鈕,同樣可以成功修改代碼。CSRF Token Tracker插件會刷新頁面獲取最新的user_token的值,然後在提交修改密碼請求的時候替換原來的值。這就是爲什麼讓用戶使用攻擊者設計的瀏覽器就可以成功利用的原因。

查看Impossible級別的源碼,如圖:

可以看到新增了一個password_current參數,需要輸入現在的密碼 ,並且會在驗證當前密碼正確之後才能繼續修改密碼。

防禦措施

  • 設置較嚴格的Referer頭驗證策略
  • 使用Token進行驗證請求是否合法
  • 設置自定義HTTP頭進行驗證

總結

 本文講解了CSRF漏洞的原理,使用DVWA環境從代碼審計層面分析了漏洞形成原因,並結合BurpSuite演示了漏洞驗證的方法。近年來隨着人們安全意識的提高,CSRF漏洞越來越少了,不知道在不久的將來會不會退出TOP10,即使如此還是需要掌握其原理及利用方法。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章