CSRF漏洞的實例分析

今天就跟大家聊聊有關CSRF漏洞的實例分析，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

CSRF漏洞

CSRF（Cross-site request forgery）跨站請求偽造，也被稱為One Click Attack 或者Session Riding，通?？s寫為CSRF或者XSRF，是一種對網站的惡意利用。盡管聽起來像跨站腳本（XSS），但它與XSS非常 不同，XSS利用站點內的信任用戶，而CSRF則通過偽裝來自受信任用戶的請求來利用受信任的網站。與XSS攻擊相比，CSRF攻擊性往往不大流行（因此對其進行防范的資源也相對少）和難以防范，所以被認為比XSS更具危險性。

漏洞簡介

跨站請求攻擊，簡單地說，是攻擊者通過一些技術手段欺騙用戶的瀏覽器去訪問一個自己曾經認證過的網站并執行一些操作（如發郵件、發消息、甚至財產操作：轉賬、購買商品等）。由于瀏覽器曾經認證過，所以被訪問的網站會認為是真正的用戶操作而去執行。這利用了web中用戶身份認證的一個漏洞：簡單的身份驗證只能保證請求發自某個用戶的瀏覽器，卻不能保證請求本身是用戶自愿發出的。

CSRF攻擊原理及過程：

1.用戶C打開瀏覽器，訪問受信任網站A，輸入用戶名和密碼請求登錄網站A；

2.在用戶信息用過驗證后，網站A產生Cookie信息并返回給瀏覽器，此時用戶登錄網站A成功，可以正常發送請求到網站A；

3.用戶未退出網站A之前，在同一瀏覽器中打開一個TAB頁訪問網站B；

4.網站B接受到用戶請求后，返回一些攻擊性代碼，并發出一個請求要求訪問第三方站點A；

5.瀏覽器在接收到這些攻擊性代碼后，根據網站B的請求，在用戶不知情的情況下攜帶Cookie信息，向網站A發出請求。網站A并不知道該請求其實是由B發起的，所以會根據用戶C的Cookie信息以C的權限處理該請求，導致來自網站B的惡意代碼被執行。

CSRF攻擊實例

受害者 Bob 在銀行有一筆存款，通過對銀行的網站發送請求http://bank.example/withdraw?account=bob&amount=1000000&for=bob2可以使Bob把1000000 的存款轉到bob2的賬號下。通常情況下，該請求發送到網站后，服務器會先驗證該請求是否來自一個合法的 session，并且該session 的用戶Bob已經成功登陸。

黑客 Mallory 自己在該銀行也有賬戶，他知道上文中的 URL 可以把錢進行轉帳操作。Mallory 可以自己發送一個請求給銀行：http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory。但是這個請求來自 Mallory 而非 Bob，他不能通過安全認證，因此該請求不會起作用。

這時，Mallory 想到使用CSRF的攻擊方式，他先自己做一個網站，在網站中放入如下代碼： src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory”，并且通過廣告等誘使 Bob 來訪問他的網站。當 Bob 訪問該網站時，上述 url 就會從Bob的瀏覽器發向銀行，而這個請求會附帶Bob瀏覽器中的cookie一起發向銀行服務器。大多數情況下，該請求會失敗，因為他要求Bob的認證信息。但是，如果Bob當時恰巧剛訪問他的銀行后不久，他的瀏覽器與銀行網站之間的session尚未過期，瀏覽器的cookie之中含有Bob的認證信息。這時，悲劇發生了，這個url請求就會得到響應，錢將從Bob的賬號轉移到Mallory的賬號，而Bob當時毫不知情。等以后Bob發現賬戶錢少了，即使他去銀行查詢日志，他也只能發現確實有一個來自于他本人的合法請求轉移了資金，沒有任何被攻擊的痕跡。而Mallory則可以拿到錢后逍遙法外。

CSRF漏洞檢測

1.檢測CSRF漏洞是一項比較繁瑣的工作，最簡單的方法就是抓取一個正常請求的數據包，去掉Referer字段后再重新提交，如果該提交還有效，那么基本上可以確定存在CSRF漏洞。

2.隨著對CSRF漏洞研究的不斷深入，不斷涌現出一些專門針對CSRF漏洞檢測的工具，若CSRFTester，CSRF Request Builder等。

漏洞危害

修改用戶信息

執行惡意操作

防御CSRF攻擊

目前防御CSRF攻擊主要有三種策略：

1.驗證HTTP Referer字段；

2.在請求地址中添加token并驗證；

3.在HTTP頭中自定義屬性并驗證。

CSRF與XSS的區別：最大的區別就是CSRF沒有盜取用戶的Cookie，而是直接的利用了瀏覽器的Cookie讓用戶去執行某個動作。

CSRF挖掘技巧

漏洞條件

1.被害用戶已經完成身份認證

2.新請求的提交不需要重新身份認證或確認機制

3.攻擊者必須了解Web APP請求的參數構造

4.引誘用戶觸發攻擊的指令（社工）

各種功能點

密碼修改處

點贊

轉賬

注銷

刪除

看完上述內容，你們對CSRF漏洞的實例分析有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。