跨站請求偽造

標籤：

簡介　　CSRF（Cross-site request forgery跨站請求偽造，也被稱為“One Click Attack”或者Session Riding，通常縮寫為CSRF或者XSRF，是一種對網站的惡意利用。儘管聽起來像跨站指令碼（XSS），但它與XSS非常不同，並且攻擊方式幾乎相左。XSS利用網站內的信任使用者，而CSRF則通過偽裝來自受信任使用者的請求來利用受信任的網站。與XSS攻擊相比，CSRF攻擊往往不大流行（因此對其進行防範的資源也相當稀少）和難以防範，所以被認為比XSS更具危險性。 情境

      某程式員大神God在某線上銀行Online Bank給他的朋友Friend轉賬。

 

　　

　　轉賬後，出於好奇，大神God查看了網站的源檔案，以及捕獲到轉賬的請求。

 

 

 

　　大神God發現，這個網站沒有做防止CSRF的措施，而且他自己也有一個有一定訪問量的網站，於是，他計劃在自己的網站上內嵌一個隱藏的Iframe偽造請求（每10s發送一次），來等待魚兒Fish上鉤，給自己轉賬。

　　網站源碼：

 View Code

　   偽造請求源碼：

 View Code

 

 

　　魚兒Fish開啟了大神God的網站，在上面瀏覽豐富多彩的內容。此時偽造請求的結果是這樣的（為了示範效果，去掉了隱藏）：

　　

　　因為魚兒Fish沒有登陸，所以，偽造請求一直無法執行，一直跳回登入頁面。

　　然後魚兒Fish想起了要登入線上銀行Online Bank查詢內容，於是他登入了Online Bank。

　　此時偽造請求的結果是這樣的（為了示範效果，去掉了隱藏）：

 

 

　　魚兒Fish每10秒會給大神God轉賬100元。

　　

　　

防止CSRF

　　CSRF能成功是因為同一個瀏覽器會共用Cookies，也就是說，通過許可權認證和驗證是無法防止CSRF的。那麼應該怎樣防止CSRF呢？其實防止CSRF的方法很簡單，只要確保請求是自己的網站發出的就可以了。那怎麼確保請求是發自於自己的網站呢？ASP.NET以Token的形式來判斷請求。

　　我們需要在我們的頁面產生一個Token，發請求的時候把Token帶上。處理請求的時候需要驗證Cookies+Token。

　　

 

　　此時偽造請求的結果是這樣的（為了示範效果，去掉了隱藏）：

 

$.ajax

　　如果我的請求不是通過Form提交，而是通過Ajax來提交，會怎樣呢？結果是驗證不通過。

　　為什麼會這樣子？我們回頭看看加了@Html.AntiForgeryToken()後頁面和請求的變化。

　　1. 頁面多了一個隱藏欄位，name為__RequestVerificationToken。

　　2. 請求中也多了一個欄位__RequestVerificationToken。

　　

 

　　原來要加這麼個欄位，我也加一個不就可以了！

　　啊！為什麼還是不行...逼我放大招，研究源碼去！

　　

　　噢！原來token要從Form裡面取。但是ajax中，Form裡面並沒有東西。那token怎麼辦呢？我把token放到碗裡，不對，是放到header裡。

　　js代碼：

 View Code

 

　　在服務端，參考ValidateAntiForgeryTokenAttribute，編寫一個AjaxValidateAntiForgeryTokenAttribute：

 View Code

 

　　然後調用時把ValidateAntiForgeryToken替換成AjaxValidateAntiForgeryToken。

　　

　　大功告成，好有成就感！

 

全域處理

　　如果所有的操作請求都要加一個ValidateAntiForgeryToken或者AjaxValidateAntiForgeryToken，不是挺麻煩嗎？可以在某個地方統一處理嗎？答案是闊儀的。

　　ValidateAntiForgeryTokenAttribute繼承IAuthorizationFilter，那就在AuthorizeAttribute裡做統一處理吧。

　　ExtendedAuthorizeAttribute：

 View Code

 　　

　　然後在FilterConfig註冊一下。

　　

　　FAQ：

　　1. BypassCsrfValidationAttribute是什麼鬼？不是有個AllowAnonymousAttribute嗎？

　　如果有些操作你不需要做CSRF的處理，比如附件上傳，你可以在對應的Controller或Action上添加BypassCsrfValidationAttribute。

　　AllowAnonymousAttribute不僅會繞過CSRF的處理，還會繞過認證和驗證。BypassCsrfValidationAttribute繞過CSRF但不繞過認證和驗證，

也就是BypassCsrfValidationAttribute作用於那些登入或授權後的Action。

 

　　2. 為什麼只處理POST請求？

　　我開發的時候有一個原則，查詢都用GET，操作用POST，而對於查詢的請求沒有必要做CSRF的處理。大家可以按自己的需要去安排！

　　

　　3. 我做了全域處理，然後還在Controller或Action上加了ValidateAntiForgeryToken或者AjaxValidateAntiForgeryToken，會衝突嗎？

　　不會衝突，只是驗證會做兩次。

 

源碼下載

　　為了方便使用，我沒有使用任何資料庫，而是用了一個檔案來儲存資料。代碼下載後可以直接運行，無需配置。

　　：https://github.com/ErikXu/CSRF

 分類: Web安全相關

跨站請求偽造