簡介
場景
某程序員大神God在某在線銀行Online Bank給他的朋友Friend轉賬。
轉賬后，出於好奇，大神God查看了網站的源文件，以及捕獲到轉賬的請求。
大神God發現，這個網站沒有做防止CSRF的措施，而且他自己也有一個有一定訪問量的網站，於是，他計划在自己的網站上內嵌一個隱藏的Iframe偽造請求（每10s發送一次），來等待魚兒Fish上鈎，給自己轉賬。
網站源碼：
<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=gb2312" /> <title></title> </head> <body> <div> 我是一個內容豐富的網站，你不會關閉我！ </div> <iframe name="frame" src="invalid.html" sandbox="allow-same-origin allow-scripts allow-forms" style="display: none; width: 800px; height: 1000px;"> </iframe> <script type="text/javascript"> setTimeout("self.location.reload();", 10000); </script> </body> </html>
偽造請求源碼：
<html> <head> <title></title> </head> <body> <form id="theForm" action="http://localhost:22699/Home/Transfer" method="post"> <input class="form-control" id="TargetUser" name="TargetUser" placeholder="用戶名" type="text" value="God" /> <input class="form-control" id="Amount" name="Amount" placeholder="轉賬金額" type="text" value="100" /> </form> <script type="text/javascript"> document.getElementById('theForm').submit(); </script> </body> </html>
魚兒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代碼：
$(function () { var token = $('@Html.AntiForgeryToken()').val(); $('#btnSubmit').click(function () { var targetUser = $('#TargetUser').val(); var amount = $('#Amount').val(); var data = { 'targetUser': targetUser, 'amount': amount }; return $.ajax({ url: '@Url.Action("Transfer2", "Home")', type: 'POST', data: JSON.stringify(data), contentType: 'application/json', dataType: 'json', traditional: 'true', beforeSend: function (xhr) { xhr.setRequestHeader('__RequestVerificationToken', token); }, success:function() { window.location = '@Url.Action("Index", "Home")'; } }); }); });
在服務端，參考ValidateAntiForgeryTokenAttribute，編寫一個AjaxValidateAntiForgeryTokenAttribute：
[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method)] public class AjaxValidateAntiForgeryTokenAttribute : FilterAttribute, IAuthorizationFilter { public void OnAuthorization(AuthorizationContext filterContext) { if (filterContext == null) { throw new ArgumentNullException("filterContext"); } var request = filterContext.HttpContext.Request; var antiForgeryCookie = request.Cookies[AntiForgeryConfig.CookieName]; var cookieValue = antiForgeryCookie != null ? antiForgeryCookie.Value : null; var formToken = request.Headers["__RequestVerificationToken"]; AntiForgery.Validate(cookieValue, formToken); } }
然后調用時把ValidateAntiForgeryToken替換成AjaxValidateAntiForgeryToken。
大功告成，好有成就感！
全局處理
如果所有的操作請求都要加一個ValidateAntiForgeryToken或者AjaxValidateAntiForgeryToken，不是挺麻煩嗎？可以在某個地方統一處理嗎？答案是闊儀的。
ValidateAntiForgeryTokenAttribute繼承IAuthorizationFilter，那就在AuthorizeAttribute里做統一處理吧。
ExtendedAuthorizeAttribute：
public class ExtendedAuthorizeAttribute : AuthorizeAttribute { public override void OnAuthorization(AuthorizationContext filterContext) { PreventCsrf(filterContext); base.OnAuthorization(filterContext); GenerateUserContext(filterContext); } /// <summary> /// http://www.asp.net/mvc/overview/security/xsrfcsrf-prevention-in-aspnet-mvc-and-web-pages /// </summary> private static void PreventCsrf(AuthorizationContext filterContext) { var request = filterContext.HttpContext.Request; if (request.HttpMethod.ToUpper() != "POST") { return; } var allowAnonymous = HasAttribute(filterContext, typeof(AllowAnonymousAttribute)); if (allowAnonymous) { return; } var bypass = HasAttribute(filterContext, typeof(BypassCsrfValidationAttribute)); if (bypass) { return; } if (filterContext.HttpContext.Request.IsAjaxRequest()) { var antiForgeryCookie = request.Cookies[AntiForgeryConfig.CookieName]; var cookieValue = antiForgeryCookie != null ? antiForgeryCookie.Value : null; var formToken = request.Headers["__RequestVerificationToken"]; AntiForgery.Validate(cookieValue, formToken); } else { AntiForgery.Validate(); } } private static bool HasAttribute(AuthorizationContext filterContext, Type attributeType) { return filterContext.ActionDescriptor.IsDefined(attributeType, true) || filterContext.ActionDescriptor.ControllerDescriptor.IsDefined(attributeType, true); } private static void GenerateUserContext(AuthorizationContext filterContext) { var formsIdentity = filterContext.HttpContext.User.Identity as FormsIdentity; if (formsIdentity == null || string.IsNullOrWhiteSpace(formsIdentity.Name)) { UserContext.Current = null; return; } UserContext.Current = new WebUserContext(formsIdentity.Name); } }
然后在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，會沖突嗎？
不會沖突，只是驗證會做兩次。
源碼下載
為了方便使用，我沒有使用任何數據庫，而是用了一個文件來存儲數據。代碼下載后可以直接運行，無需配置。