ASP.NET MVC防范CSRF最佳实践

XSS与CSRF

哈哈，有点标题党，但我保证这篇文章跟别的不太一样。

我认为，网站安全的基础有三块：

• 防范中间人攻击
• 防范XSS
• 防范CSRF

注意，我讲的是基础，如果更高级点的话可以考虑防范机器人刷单，再高级点就防范DDoS攻击，不过我们还是回到“基础”这个话题上吧，对于中间人攻击，使用HTTPS是正确且唯一的做法，其它都是歪门邪道，最好还要购买各个浏览器都承认的SSL证书；防范XSS，关键点在于将用户提交数据呈现在页面上的时候，需要使用Html Encode，或在处理带HTML格式的用户表单数据时，进行“消毒”(Sanitize)处理，关于这个，我前一篇文章《让ASP.NET接受有“潜在危险”的提交》已经讲述了应该怎么做；剩下了这个CSRF是本文要讲的，我认为防范CSRF的前提是必须先做好XSS的防范工作，因为：CSRF防的是别的网站，如果自己的网站本身有XSS漏洞，被别人注入了有害脚本，那么就变成了“家贼难防”了。

至于什么是CSRF，如何让ASP.NET防范CSRF，这种文章很多的，比如博客园里这篇就可以：《ASP.NET MVC 防止 CSRF 的方法》，我总结一下一般的做法，也就这两点：

• 在cshtml页面的form标签里加上@Html.AntiForgeryToken()
• 在Controller需要防范CSRF的Action上加上[ValidateAntiForgeryToken]注解

Done！

原理

为啥这样就行了呢？我简单说说原理：@Html.AntiForgeryToken()的作用是在页面上插入一个type为hidden的input标签，它的name固定是__RequestVerificationToken，value则是一长串密文，这是真的密文，是经过加密的，那明文是什么？是随机生成的128位数字，跟GUID差不多的东西，我们叫它“随机明文”吧，再附带一点额外的信息(忽略这个吧)，然后加密，加密器是这个玩意儿：System.Web.Security.MachineKey，我这里写个简单的Example，大家可以弄个HelloWorld程序看看运行效果。

byte[] plainText = Encoding.UTF8.GetBytes("123456");
string[] purposes = { "blah blah blah" };
byte[] cypherText = MachineKey.Protect(plainText, purposes);
Console.WriteLine(Convert.ToBase64String(cypherText));
plainText = MachineKey.Unprotect(cypherText, purposes);
Console.WriteLine(Encoding.UTF8.GetString(plainText));

多运行几次，每次都能解出正确的明文，但是密文每次都不一样，所以大家在不断刷新页面的时候，发现每次生成的value也不一样，但没事，它们的“随机明文”是一样的。除了生成这个input标签之外，@Html.AntiForgeryToken()还做了个额外的动作，那就是生成一个同样名字(也叫__RequestVerificationToken)的Cookie，内容差不多，在我们看来也是一长串密文。所以总结回来@Html.AntiForgeryToken()就做了这两件事：

• 页面上加上一个像这样的标签<input name="__RequestVerificationToken" type="hidden" value="(一长串密文)" />
• 生成一个名为__RequestVerificationToken的Cookie，值为“一长串密文”

接下来轮到ValidateAntiForgeryToken过滤器，它收到了请求，就尝试解出请求中的Cookie的“一长串密文”和请求中的Form的“一长串密文”，解密后比对两者的“随机明文”，如果一致，则通过，(其实作为高级用法你还可以自定义一些额外的规则，不过这不在本文讲述范围内)否则抛出HttpAntiForgeryException异常。

为什么只需要检验下Cookie和Form的“随机明文”就可以防范CSRF了呢？其实理解起来并不难，前面说了CSRF防的是别的网站，别的网站伪造了请求，利用访问者的浏览器对目标网站发送了这个请求，但伪造者并不清楚目标网站的访问者的__RequestVerificationToken这个Cookie的值，因此表单中的__RequestVerificationToken的值也就无法伪造，这个请求会被ValidateAntiForgeryToken过滤器拦截下来。

特点与局限性

知道了原理，就来分析下它的特点与局限性，首先很容易想到的就是：

• 浏览器必须要支持Cookie
• 只能验证POST请求(因为需要Form)

另外思考一下如果一个页面中调用了多次@Html.AntiForgeryToken()，生成了多个input标签，会怎样呢？会不会生成了两个不同的Token，最后比对出错？其实不必担心，正儿八经的那个随机明文只会生成一次，Html.AntiForgeryToken()方法会检查你提交的Cookie，如果已存在__RequestVerificationToken，那么它就不会再生成一个新的随机数明文了。否则如果每次都生成一个随机数明文，你的页面上如果有两个Form的话，其中一个肯定没法正常提交，更不用说AJAX提交的情况。

AJAX POST

如果不是直接提交页面上的表单，而是AJAX POST，像这样：

$.ajax({
    type: "post",
    url: "/testurl",
    data: {test:'abc'},
    success: function (data) {
        //done!
    }
});

这可咋办？你必须想方设法在data中带上正确的__RequestVerificationToken啊！StackOverflow上有个解决方案，挺不错，大家参考下：Go to StackOverflow，简单地说就是写一个ASP.NET MVC的HTML生成帮助方法，用于生成那“一长串密文”，交给这个ajax的data。

但这可不是我想说的“最佳实践” ，再考虑一种情况：用js动态生成Form，然后Submit。嗯，我承认这个有点奇葩，但在我的项目中确实有不少地方是这么干的，你别问为什么了，反正就是有，遇到这种情况，咋办？看来还是得求助于js。下面我分享下我的做法：

我的“最佳实践”

首先我没有把@Html.AntiForgeryToken()放到每一个Form中，我只在一处地方用到了@Html.AntiForgeryToken()，那就是母版页！接下来把下面这段js放到common.js中(common.js是母版页引用的js，也就是说每个页面会引用到)：

    //处理form的submit事件，添加AntiForgeryToken到表单里
    $("body").on("submit", "form", function () {
        var theForm = $(this);
        if (theForm.find("input[name='__RequestVerificationToken']").length === 0) {
            var antiForgery = $("input[name='__RequestVerificationToken']:first").val();
            if (antiForgery) {
                var theAntiForgeryTokenInput = $('<input />').attr('type', 'hidden')
                    .attr('name', '__RequestVerificationToken')
                    .attr('value', antiForgery);
                $(this).prepend(theAntiForgeryTokenInput);
            }
        }
    });

这样一来，所有的form的submit动作就会在这里被处理一下，添加上了__RequestVerificationToken这个字段。接下来是AJAX POST的处理：

    data= {test:'abc'};

    var antiForgery = $("input[name='__RequestVerificationToken']:first").val();
    if (antiForgery) {
        if (!data.__RequestVerificationToken) {
            data.__RequestVerificationToken = antiForgery;
        }
    }

    $.ajax({
        type: "post",
        url: "/testurl",
        data: data,
        success: function (data) {
            //done!
        }
    });

嗯？你也许要问，每个用到AJAX POST的地方都加上这么一段代码岂不是很繁琐？是的，但在我的项目中，我用了几个公共的方法对AJAX POST进行了一些封装，所以只需要改好这几个地方即可，你可以根据自己的项目的实际情况进行优化处理。

还有一种情况是用AJAX来提交Form，而不是像上面这样的data：

    var form = $("#the-form-id");
    var dataToSubmit = form.serializeArray();
    var antiForgery = $("input[name='__RequestVerificationToken']:first").val();
    if (antiForgery) {
        var found = false;
        for (var i = 0; i < dataToSubmit.length; i++) {
            if (dataToSubmit[i].name === '__RequestVerificationToken') {
                found = true;
                break;
            }
        }
        if (!found) {
            dataToSubmit.push({ name: "__RequestVerificationToken", value: antiForgery });
        }
    }

    $.ajax({
        type: method,
        url: urlToSubmit,
        data: dataToSubmit,
        success: function (data) {
            //done!
        }
    });

照旧，根据你的项目的实际情况封装一下，其实真正要改动的地方不多，只要你框架搭好了。

总结一下，框架搭好了的前提下，为了防范CSRF，你所需要做的事情就仅剩下：给带[HttpPost]注解的Action添加[ValidateAntiForgeryToken]。

至于验证失败抛出HttpAntiForgeryException异常导致默认错误页面(我又叫它“死黄页”，该死的黄页的意思)出现的问题，你可以在Application_Error中处理一下啊，Google关键字“Application_Error”，一搜一大堆，或者，等我有空了再写一篇这个主题的“最佳实践”？