.NET MVC CSRF/XSRF 漏洞
最近我跟一個漏洞還有一群阿三幹起來了……
背景：
我的客戶是一個世界知名的藥企，最近這個客戶上臺了一位阿三管理者，這個貨上線第一個事兒就是要把現有的軟件供應商重新洗牌一遍。由於我們的客戶關系維護的非常好，直接對口人提前透露給我們這個管理者就是想讓一個阿三公司壟斷他們的軟件供應，並且表示了非常鄙視。我們表示了理解，畢竟任意一家公司只要進去一個阿三，慢慢的。。。慢慢的。。。就變成滿屋都是阿三。。。
然後某一家阿三公司就暗地裏中標了，然後我們就面臨KT。由於我們維護著12個高活躍系統，所以KT的工作量也是非常的大。
BUT！ 阿三的牛逼之處就在這時候體現出來了，他會從各個維度找你的事兒，其中一個就是找漏洞（自己找了一家阿三的漏洞檢測公司免費做）報給客戶並威脅說解決不完不接手，用以拉長KT的周期（本來KT只有三周時間）。
然後客戶的阿三頭頭就同意了。。。
這個漏洞本來就有，客戶一直表示不想處理，因為大多數網站太老舊了，很多都不是我們一手開發的。
但是這回看來是不幹不行了，還好客戶表示會付費，行吧。。。 那就整
現在有請漏洞登場！
大家好！我叫CSRF，全名是 Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
這是我的簡歷：https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Viewstate_.28ASP.NET.29
（Google Translate 了解一下）
這個玩意說白了就是一個偽裝攻擊，偽裝工具是Cookie。
這個玩意是這樣運作的：
（請不要在意這個醜逼的圖。。。）
簡單描述就是
其他網站用你的身份（Cookie）假裝是你幹了你不知道的事兒，這時候請想想你在網上銀行轉賬的時候
那麽這裏面就出現一個重大的疑點：
為啥WebSiteB發過來的請求WebSiteA會收到呢？ IIS吃了臟東西不管事兒了？
因為我們的網站支持跨域請求!（是不是看著賊紮眼！畫重點了啊）
現在毛病基本OK了，剩的就是出方案。
對與CSRF這個東西知名度還是很高的，網上一搜一大把
.NET MVC就自帶了解決方案，此方案只針對常規的MVC項目，前後端分離的繞行，以後我要是解決了我再回來寫。。。
解決方案也很粗暴，一句話來說就是：
我們的服務器只接收來自我們自己頁面發過來的請求
放到實現上就是：每個頁面都按照一定規則生成一個Token，然後再發請求的時候帶過去，服務器先看Token再幹別的
這時候有人說了：要是別的網站偽造Token怎麽辦？
有道是孔子曰：不怕賊偷就怕賊惦記，他要是就想搞你，你早晚是防不住的啊，兄die
下面介紹關鍵代碼：
@Html.AntiForgeryToken()
這個是cshtml的頁面的代碼，aspx的差不多
這東西的作用是會在頁面上生成一個 Hidden，Value就是Token
最後變成Html長介樣兒：
<input name="__RequestVerificationToken" type="hidden" value="MbnNdB3T64quXYviXLsvoi_FlbM2SihwiiPCgSzaWAL0duMy7H6SbuF0lkUAxOD-DwF4P_4kxlyravohGXsQ_ERVPm5f3Oa3owG6LZ26WRw1" />
那一球亂糟糟的就是Token
那麽這玩意怎麽用呢？
Type 1，Form Request：
@using (Html.BeginForm("Action", "Controller", null, FormMethod.Post, new { id = "formId" }))
{
@Html.AntiForgeryToken();
Other Code......
}
Type 2，Ajax Request：
var token = $(‘@Html.AntiForgeryToken()‘).val();
var headers = {};
headers["__RequestVerificationToken"] = token;
$.ajax({
type: "post",
headers: headers,
url: "@Url.Action("Action","Controller")",
data: { },
dataType: "json",
success: function (response) {
}
});
說到底就是頁面上生成了Token之後，想盡一切辦法發到後臺去，不拘泥與形式
form就是直接包到裏面了，後臺直接用name拿就ok了，Ajax是放在header裏了。
接下來就是後臺驗證，由於絕大多數Action都需要堵這個漏洞，所以直接寫了一個Filter
using System.Net;
using System.Web.Helpers;
using System.Web.Mvc;
public class ExtendedValidateAntiForgeryToken : AuthorizeAttribute
{
public override void OnAuthorization(AuthorizationContext filterContext)
{
var request = filterContext.HttpContext.Request;
if (request.HttpMethod != WebRequestMethods.Http.Post) return;
if (request.IsAjaxRequest())
{
var antiForgeryCookie = request.Cookies[AntiForgeryConfig.CookieName];
var cookieValue = antiForgeryCookie != null ? antiForgeryCookie.Value : null;
//從cookies 和 Headers 中 驗證防偽標記
//這裏可以加try-catch
//try
//{
AntiForgery.Validate(cookieValue, request.Headers["__RequestVerificationToken"]);
//}
//catch (Exception e)
//{
// //filterContext.Result = new RedirectResult("/Account/Login?returnUrl=" +
// // HttpUtility.UrlEncode(filterContext.HttpContext.Request.Url.ToString()));
// ContentResult result = new ContentResult();
// result.Content = "<div style=‘text-align:center;padding:1em;‘ >當前已經處於退出狀態，請重新登錄</div>";
// filterContext.Result = result;
//}
}
else
{
//try
//{
new ValidateAntiForgeryTokenAttribute().OnAuthorization(filterContext);
//}
//catch (Exception ex)
//{
// //
//}
}
}
}
裏面代碼核心就是驗證Token的有效性，用的是官方API方法，但是要區別一個事兒，就是前文提到了咱們Ajax和Form帶Token的方式不一樣，所以需要判斷是不是AJAX Request，走兩個分支。
然後就是把Filter掛到Action上就行了。
好了，漏洞堵上了，用時2天，客戶賊開心，正在準備去找阿三幹仗的時候出岔子了。
細心的老鐵可能發現了，上面的解決方案都是POST請求啊，GET呢？
這個就是個事兒了，從網上調查的時候得知，這個CSRF全是針對POST的，壓根就不管GET。
比如這個文章：
https://stackoverflow.com/questions/35473856/asp-net-mvc-csrf-on-a-get-request
阿三哪個什麽漏洞檢測公司發回來一堆GET的URL。。。
在跟客戶說明原委之後，客戶炸了。。。 要幹阿三，然後就發了一系列言辭犀利的郵件，也CC了他們哪個阿三頭頭
最後阿三們看有點失控，一個是我們POST改的太快了（47處），第二個是，沒想到客戶的IT急眼了。。。
這時的阿三很尷尬，在郵件裏回：我們有很豐富的修改漏洞的經驗
WTF？！！
還沒等我們說話，客戶直接回了一句：好！我現在約一個會，你們說說GET請求是怎麽回事兒
行了。。。 我去幫客戶幹仗了。。。
想想跟印度人、韓國人、澳大利亞人加上我一個中國人開英語的會我就腦仁兒疼。。。。。。
另外附加一個連接：
https://weblogs.asp.net/dixin/anti-forgery-request-recipes-for-asp-net-mvc-and-ajax
.NET MVC CSRF/XSRF 漏洞