.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