XSS與CSRF

哈哈，有點標題黨，但我保證這篇文章跟別的不太一樣。

我認為，網站安全的基礎有三塊：

• 防範中間人攻擊
• 防範XSS
• 防範CSRF

注意，我講的是基礎，如果更高階點的話可以考慮防範機器人刷單，再高階點就防範DDoS攻擊，不過我們還是回到“基礎”這個話題上吧，對於中間人攻擊，使用HTTPS是正確且唯一的做法，其它都是歪門邪道，最好還要購買各個瀏覽器都承認的SSL證書；防範XSS，關鍵點在於將使用者提交資料呈現在頁面上的時候，需要使用Html Encode，或在處理帶HTML格式的使用者表單資料時，進行“消毒”(Sanitize)處理，關於這個，我前一篇文章《讓ASP.NET接受有“潛在危險”的提交

至於什麼是CSRF，如何讓ASP.NET防範CSRF，這種文章很多的，比如部落格園裡這篇就可以：《ASP.NET MVC 防止 CSRF 的方法》，我總結一下一般的做法，也就這兩點：

• 在cshtml頁面的form標籤里加上@Html.AntiForgeryToken()
• 在Controller需要防範CSRF的Action上加上[ValidateAntiForgeryToken]註解

Done！

原理

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));
 

• 頁面上加上一個像這樣的標籤<input name="__RequestVerificationToken" type="hidden" value="(一長串密文)" />

接下來輪到ValidateAntiForgeryToken過濾器，它收到了請求，就嘗試解出請求中的Cookie的“一長串密文”和請求中的Form的“一長串密文”，解密後比對兩者的“隨機明文”，如果一致，則通過，(其實作為高階用法你還可以自定義一些額外的規則，不過這不在本文講述範圍內)否則丟擲HttpAntiForgeryException異常。

特點與侷限性

知道了原理，就來分析下它的特點與侷限性，首先很容易想到的就是：

• 瀏覽器必須要支援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”，一搜一大堆，或者，等我有空了再寫一篇這個主題的“最佳實踐”？