.NET Core實戰項目之CMS 第十四章 開發篇-防止跨站請求僞造（XSRF/CSRF）攻擊處理

經過 ASP.NET Core，開發者可輕鬆配置和管理其應用的安全性。 ASP.NET Core 中包含管理身份驗證、受權、數據保護、SSL 強制、應用機密、請求防僞保護及 CORS 管理等等安全方面的處理。 經過這些安全功能，能夠生成安全可靠的 ASP.NET Core 應用。而咱們這一章就來講道說道如何在ASP.NET Core中處理「跨站請求僞造（XSRF/CSRF）攻擊」的，但願對你們有所幫助！

本文已收錄至《.NET Core實戰項目之CMS 第一章 入門篇-開篇及整體規劃》
做者：依樂祝
原文地址：https://www.cnblogs.com/yilezhu/p/10229954.html

寫在前面

上篇文章發出來後不少人就去GitHub上下載了源碼，而後就來問我說爲何登陸功能都沒有啊？還有不少菜單點着沒反應。這裏統一說明一下，是由於個人代碼是跟着博客的進度在逐步完善的，等這個系列寫完的時候才表明這個CMS系統的完成！所以，如今這個CMS系統仍是一個半成品，不過我會盡快來完成的！廢話很少說，下面咱們先介紹一下跨站請求僞造（XSRF/CSRF）攻擊」的概念，而後再來講到一下ASP.NET Core中是如何進行處理的吧！

什麼是跨站請求僞造（XSRF/CSRF）

在繼續以前若是不給你講一下什麼是跨站請求僞造（XSRF/CSRF）的話可能你會很懵逼，我爲何要了解這個，不處理又有什麼問題呢？
CSRF（Cross-site request forgery跨站請求僞造，也被稱爲「One Click Attack」或者Session Riding，一般縮寫爲CSRF或者XSRF，是一種對網站的惡意利用。儘管聽起來像跨站腳本（XSS），但它與XSS很是不一樣，而且攻擊方式幾乎相左。XSS利用站點內的信任用戶，而CSRF則經過假裝來自受信任用戶的請求來利用受信任的網站。與XSS攻擊相比，CSRF攻擊每每不大流行（所以對其進行防範的資源也至關稀少）和難以防範，因此被認爲比XSS更具危險性。
CSRF在 2007 年的時候曾被列爲互聯網 20 大安全隱患之一。其餘安全隱患，好比 SQL 腳本注入，跨站域腳本攻擊等在近年來已經逐漸爲衆人熟知，不少網站也都針對他們進行了防護。然而，對於大多數人來講，CSRF 卻依然是一個陌生的概念。即使是大名鼎鼎的 Gmail, 在 2007 年末也存在着 CSRF 漏洞，從而被黑客攻擊而使 Gmail 的用戶形成巨大的損失。

跨站請求僞造（XSRF/CSRF）的場景

這裏爲了加深你們對「跨站請求僞造（XSRF/CSRF）」的理解能夠看以下所示的圖：

如上圖所示：

1. 用戶瀏覽位於目標服務器 A 的網站。並經過登陸驗證。

2. 獲取到 cookie_session_id，保存到瀏覽器 cookie 中。

3. 在未登出服務器 A ，並在 session_id 失效前用戶瀏覽位於 hacked server B 上的網站。

4. server B 網站中的<img src = "http://www.cnblog.com/yilezhu?creditAccount=1001160141&transferAmount=1000">嵌入資源起了做用，迫使用戶訪問目標服務器 A

5. 因爲用戶未登出服務器 A 而且 sessionId 未失效，請求經過驗證，非法請求被執行。

試想一下若是這個非法請求是一個轉帳的操做會有多恐怖！

跨站請求僞造（XSRF/CSRF）怎麼處理？

既然跨站請求僞造（XSRF/CSRF）有這麼大的危害，那麼咱們如何在ASP.NET Core中進行處理呢？
其實說白了CSRF可以成功也是由於同一個瀏覽器會共享Cookies，也就是說，經過權限認證和驗證是沒法防止CSRF的。那麼應該怎樣防止CSRF呢？其實防止CSRF的方法很簡單，只要確保請求是本身的站點發出的就能夠了。那怎麼確保請求是發自於本身的站點呢？ASP.NET Core中是以Token的形式來判斷請求。咱們須要在咱們的頁面生成一個Token，發請求的時候把Token帶上。處理請求的時候須要驗證Cookies+Token。這樣就能夠有效的進行驗證了！
其實說到這裏可能有部分童鞋已經想到了，@Html.AntiForgeryToken() 沒錯就是它，在.NET Core中起着防止 跨站請求僞造（XSRF/CSRF）的做用，想必大夥都會使用！下面咱們再一塊兒看看ASP.NET Core的使用方式吧。

ASP.NET Core MVC是如何處理跨站請求僞造（XSRF/CSRF）的？

警告：
ASP.NET Core使用 ASP.NET Core data protection stack 來實現防請求僞造。若是在服務器集羣中需配置 ASP.NET Core Data Protection，有關詳細信息，請參閱 Configuring data protection。

在ASP.NET Core MVC 2.0或更高版本中，FormTagHelper爲HTML表單元素注入防僞造令牌。例如，Razor文件中的如下標記將自動生成防僞令牌：

<form method="post">
            ···
        </form>

相似地， IHtmlHelper.BeginForm默認狀況下生成防僞令牌，固然窗體的方法不是 GET。（你懂的）

當Html表單包含method="post"而且下面條件之一 成立是會自動生成防僞令牌。

• action屬性爲空( action="") 或者
• 未提供action屬性(<form method="post">)。

固然您也能夠經過如下方式禁用自動生成HTML表單元素的防僞令牌：

• 明確禁止asp-antiforgery，例如

<form method="post" asp-antiforgery="false">
    ...
</form>

• 經過使用標籤幫助器! 禁用語法，從標籤幫助器轉化爲表單元素。

<!form method="post">
    ...
</!form>

• 在視圖中移除FormTagHelper，您能夠在Razor視圖中添加如下指令移除FormTagHelper：

@removeTagHelper Microsoft.AspNetCore.Mvc.TagHelpers.FormTagHelper, Microsoft.AspNetCore.Mvc.TagHelpers

提示：
Razor頁面會自動受到XSRF/CSRF的保護。您沒必要編寫任何其餘代碼，有關詳細信息，請參閱XSRF/CSRF和Razor頁面。

爲抵禦 CSRF 攻擊最經常使用的方法是使用同步器標記模式(STP)。 當用戶請求的頁面包含窗體數據使用 STP:

1. 服務器發送到客戶端的當前用戶的標識相關聯的令牌。
2. 客戶端返回將令牌發送到服務器進行驗證。
3. 若是服務器收到與通過身份驗證的用戶的標識不匹配的令牌，將拒絕請求。

該令牌惟一且不可預測。 該令牌還可用於確保正確序列化的一系列的請求 (例如，確保請求序列的： 第 1 頁–第 2 頁–第 3 頁)。全部在ASP.NET Core MVC 和 Razor 頁模板中的表單都會生成 antiforgery 令牌。 如下兩個視圖生成防僞令牌的示例：

CSHTML複製

<form asp-controller="Manage" asp-action="ChangePassword" method="post">
    ...
</form>

@using (Html.BeginForm("ChangePassword", "Manage"))
{
    ...
}

顯式添加到防僞令牌<form>而無需使用標記幫助程序與 HTML 幫助程序元素@Html.AntiForgeryToken:

CSHTML複製

<form action="/" method="post">
    @Html.AntiForgeryToken()
</form>

在每一個前面的狀況下，ASP.NET Core 添加相似於如下一個隱藏的表單字段：

CSHTML複製

<input name="__RequestVerificationToken" type="hidden" value="CfDJ8NrAkS ... s2-m9Yw">

ASP.NET Core 包括三個篩選器來處理 antiforgery 令牌：

• ValidateAntiForgeryToken
• AutoValidateAntiforgeryToken
• IgnoreAntiforgeryToken

防僞選項

自定義防僞選項中Startup.ConfigureServices:

C#複製

services.AddAntiforgery(options => 
{
    // Set Cookie properties using CookieBuilder properties†.
    options.FormFieldName = "AntiforgeryFieldname";
    options.HeaderName = "X-CSRF-TOKEN-yilezhu";
    options.SuppressXFrameOptionsHeader = false;
});

†設置防僞Cookie屬性使用的屬性CookieBuilder類。

選項	描述
Cookie	肯定用於建立防僞 cookie 的設置。
FormFieldName	防僞系統用於呈現防僞令牌在視圖中的隱藏的窗體字段的名稱。
HeaderName	防僞系統使用的標頭的名稱。 若是null，系統會認爲只有窗體數據。
SuppressXFrameOptionsHeader	指定是否禁止顯示生成X-Frame-Options標頭。 默認狀況下，值爲"SAMEORIGIN"生成標頭。 默認爲 false。

有關詳細信息，請參閱CookieAuthenticationOptions。

在咱們的CMS系統中的Ajax請求就是使用的自定義HeaderName的方式進行驗證的，不知道你們有沒有注意到！

須要防僞驗證

ValidateAntiForgeryToken實質上是一個過濾器，可應用到單個操做，控制器或全局範圍內。除了具備IgnoreAntiforgeryToken屬性的操做，不然全部應用了這個屬性的Action都會進行防僞驗證。以下所示：

C#複製

[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> RemoveLogin(RemoveLoginViewModel account)
{
    ManageMessageId? message = ManageMessageId.Error;
    var user = await GetCurrentUserAsync();

    if (user != null)
    {
        var result = 
            await _userManager.RemoveLoginAsync(
                user, account.LoginProvider, account.ProviderKey);

        if (result.Succeeded)
        {
            await _signInManager.SignInAsync(user, isPersistent: false);
            message = ManageMessageId.RemoveLoginSuccess;
        }
    }

    return RedirectToAction(nameof(ManageLogins), new { Message = message });
}

ValidateAntiForgeryToken屬性所修飾的操做方法包括 HTTP GET 都須要一個Token進行驗證。 若是ValidateAntiForgeryToken特性應用於應用程序的控制器上，則能夠應用IgnoreAntiforgeryToken來對它進行重載以便忽略此驗證過程。

備註:ASP.NET Core 不支持自動將 antiforgery 令牌應用到GET 請求上。

ASP.NET Core MVC在Ajax中處理跨站請求僞造（XSRF/CSRF）的注意事項

ValidateAntiForgeryToken 在進行Token驗證的時候Token是從Form裏面取的。可是ajax中，Form裏面並無東西。那token怎麼辦呢？這時候咱們能夠把Token放在Header裏面。相信看了個人源碼的童鞋必定對這些不會陌生！
以下代碼所示：

$.ajax({
            type: 'POST',
            url: '/ManagerRole/AddOrModify/',
            data: {
                Id: $("#Id").val(),  //主鍵
                RoleName: $(".RoleName").val(),  //角色名稱
                RoleType: $(".RoleType").val(),  //角色類型
                IsSystem: $("input[name='IsSystem']:checked").val() === "0" ? false : true,  //是否系統默認
                Remark: $(".Remark").val()  //用戶簡介
            },
            dataType: "json",
            headers: {
                "X-CSRF-TOKEN-yilezhu": $("input[name='AntiforgeryKey_yilezhu']").val()
            },
            success: function (res) {//res爲相應體,function爲回調函數
                if (res.ResultCode === 0) {
                    var alertIndex = layer.alert(res.ResultMsg, { icon: 1 }, function () {
                        layer.closeAll("iframe");
                        //刷新父頁面
                        parent.location.reload();
                        top.layer.close(alertIndex);
                    });
                    //$("#res").click();//調用重置按鈕將表單數據清空
                } else if (res.ResultCode === 102) {
                    layer.alert(res.ResultMsg, { icon: 5 }, function () {
                        layer.closeAll("iframe");
                        //刷新父頁面
                        parent.location.reload();
                        top.layer.close(alertIndex);
                    });
                }
                else {
                    layer.alert(res.ResultMsg, { icon: 5 });
                }
            },
            error: function (XMLHttpRequest, textStatus, errorThrown) {
                layer.alert('操做失敗！！！' + XMLHttpRequest.status + "|" + XMLHttpRequest.readyState + "|" + textStatus, { icon: 5 });
            }
        });

如上代碼所示我是先獲取Token代碼而後把這些代碼放到ajax請求的Head裏面再進行post請求便可！

開源地址

這個系列教程的源碼我會開放在GitHub以及碼雲上，有興趣的朋友能夠下載查看！以爲不錯的歡迎Star

GitHub：https://github.com/yilezhu/Czar.Cms

碼雲：https://gitee.com/yilezhu/Czar.Cms

若是你以爲這個系列對您有所幫助的話，歡迎以各類方式進行贊助，固然給個Star支持下也是能夠滴！另一種最簡單粗暴的方式就是下面這種直接關注咱們的公衆號了：

總結

今天我先從跨站點請求僞造的概念以及原理入手，而後給你們講解了如何進行跨站點請求僞造的處理，後面引出了在ASP.NET Core中如何對其進行處理的！同時給你們說了在Ajax處理中的注意事項，但願能對大夥有所幫助！另外若是你有不一樣的見解歡迎留言，或者加入NET Core千人羣637326624討論。