最近我跟一个漏洞还有一群阿三干起来了……
背景：
我的客户是一个世界知名的药企，最近这个客户上台了一位阿三管理者，这个货上线第一个事儿就是要把现有的软件供应商重新洗牌一遍。由于我们的客户关系维护的非常好，直接对口人提前透露给我们这个管理者就是想让一个阿三公司垄断他们的软件供应，并且表示了非常鄙视。我们表示了理解，毕竟任意一家公司只要进去一个阿三，慢慢的。。。慢慢的。。。就变成满屋都是阿三。。。
然后某一家阿三公司就暗地里中标了，然后我们就面临KT。由于我们维护着12个高活跃系统，所以KT的工作量也是非常的大。
BUT！ 阿三的牛逼之处就在这时候体现出来了，他会从各个维度找你的事儿，其中一个就是找漏洞（自己找了一家阿三的漏洞检测公司免费做）报给客户并威胁说解决不完不接手，用以拉长KT的周期（本来KT只有三周时间）。
然后客户的阿三头头就同意了。。。
这个漏洞本来就有，客户一直表示不想处理，因为大多数网站太老旧了，很多都不是我们一手开发的。
但是这回看来是不干不行了，还好客户表示会付费，行吧。。。 那就整
现在有请漏洞登场！
大家好！我叫CSRF，全名是 Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
（Google Translate 了解一下）
这个玩意说白了就是一个伪装攻击，伪装工具是Cookie。
这个玩意是这样运作的：
（请不要在意这个丑逼的图。。。）
简单描述就是
其他网站用你的身份（Cookie）假装是你干了你不知道的事儿，这时候请想想你在网上银行转账的时候
那么这里面就出现一个重大的疑点：
为啥WebSiteB发过来的请求WebSiteA会收到呢？ IIS吃了脏东西不管事儿了？
因为我们的网站支持跨域请求!（是不是看着贼扎眼！画重点了啊）
现在毛病基本OK了，剩的就是出方案。
对与CSRF这个东西知名度还是很高的，网上一搜一大把
.NET MVC就自带了解决方案，此方案只针对常规的MVC项目，前后端分离的绕行，以后我要是解决了我再回来写。。。
解决方案也很粗暴，一句话来说就是：
我们的服务器只接收来自我们自己页面发过来的请求
放到实现上就是：每个页面都按照一定规则生成一个Token，然后再发请求的时候带过去，服务器先看Token再干别的
这时候有人说了：要是别的网站伪造Token怎么办？
有道是孔子曰：不怕贼偷就怕贼惦记，他要是就想搞你，你早晚是防不住的啊，兄die
下面介绍关键代码：
1@Html.AntiForgeryToken()
这个是cshtml的页面的代码，aspx的差不多
这东西的作用是会在页面上生成一个 Hidden，Value就是Token
最后变成Html长介样儿：
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 = "
// 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请求是怎么回事儿
行了。。。 我去帮客户干仗了。。。
想想跟印度人、韩国人、澳大利亚人加上我一个中国人开英语的会我就脑仁儿疼。。。。。。
