.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）”的理解可以看如下所示的圖：
如上圖所示：
用戶瀏覽位于目標服務器 A 的網站。并通過登錄驗證。
獲取到 cookie_session_id，保存到瀏覽器 cookie 中。
在未登出服務器 A ，并在 session_id 失效前用戶瀏覽位于 hacked server B 上的網站。
server B 網站中的<img src = "http://www.cnblog.com/yilezhu?creditAccount=1001160141&transferAmount=1000">嵌入資源起了作用，迫使用戶訪問目標服務器 A
由于用戶未登出服務器 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，例如
通過使用標簽幫助器! 禁用語法，從標簽幫助器轉化為表單元素。
在視圖中移除FormTagHelper，您可以在Razor視圖中添加以下指令移除FormTagHelper：
提示：
Razor頁面會自動受到XSRF/CSRF的保護。您不必編寫任何其他代碼，有關詳細信息，請參閱XSRF/CSRF和Razor頁面。
為抵御 CSRF 攻擊最常用的方法是使用同步器標記模式(STP)。 當用戶請求的頁面包含窗體數據使用 STP:
服務器發送到客戶端的當前用戶的標識相關聯的令牌。
客戶端返回將令牌發送到服務器進行驗證。
如果服務器收到與經過身份驗證的用戶的標識不匹配的令牌，將拒絕請求。
該令牌唯一且不可預測。 該令牌還可用于確保正確序列化的一系列的請求 (例如，確保請求序列的： 第 1 頁–第 2 頁–第 3 頁)。所有在ASP.NET Core MVC 和 Razor 頁模板中的表單都會生成 antiforgery 令牌。 以下兩個視圖生成防偽令牌的示例：
CSHTML復制
顯式添加到防偽令牌<form>而無需使用標記幫助程序與 HTML 幫助程序元素@Html.AntiForgeryToken:
CSHTML復制
在每個前面的情況下，ASP.NET Core 添加類似于以下一個隱藏的表單字段：
CSHTML復制
ASP.NET Core 包括三個篩選器來處理 antiforgery 令牌：
ValidateAntiForgeryToken
AutoValidateAntiforgeryToken
IgnoreAntiforgeryToken
防偽選項
自定義防偽選項中Startup.ConfigureServices:
設置防偽Cookie屬性使用的屬性CookieBuilder類。
| Cookie | 確定用于創建防偽 cookie 的設置。 |
| FormFieldName | 防偽系統用于呈現防偽令牌在視圖中的隱藏的窗體字段的名稱。 |
| HeaderName | 防偽系統使用的標頭的名稱。 如果null，系統會認為只有窗體數據。 |
| SuppressXFrameOptionsHeader | 指定是否禁止顯示生成X-Frame-Options標頭。 默認情況下，值為"SAMEORIGIN"生成標頭。 默認為?false。 |
有關詳細信息，請參閱CookieAuthenticationOptions。
在我們的CMS系統中的Ajax請求就是使用的自定義HeaderName的方式進行驗證的，不知道大家有沒有注意到！
需要防偽驗證
ValidateAntiForgeryToken實質上是一個過濾器，可應用到單個操作，控制器或全局范圍內。除了具有IgnoreAntiforgeryToken屬性的操作，否則所有應用了這個屬性的Action都會進行防偽驗證。如下所示：
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里面。相信看了我的源碼的童鞋一定對這些不會陌生！
如下代碼所示：
如上代碼所示我是先獲取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討論。
相關文章：
.NET Core實戰項目之CMS 第一章 入門篇-開篇及總體規劃
.NET Core實戰項目之CMS 第二章 入門篇-快速入門ASP.NET Core看這篇就夠了
.NET Core實戰項目之CMS 第三章 入門篇-源碼解析配置文件及依賴注入
.NET Core實戰項目之CMS 第四章 入門篇-Git的快速入門及實戰演練
.NET Core實戰項目之CMS 第五章 入門篇-Dapper的快速入門看這篇就夠了
.NET Core實戰項目之CMS 第六章 入門篇-Vue的快速入門及其使用
.NET Core實戰項目之CMS 第七章 設計篇-用戶權限極簡設計全過程
.NET Core實戰項目之CMS 第八章 設計篇-內容管理極簡設計全過程
.NET Core實戰項目之CMS 第九章 設計篇-白話架構設計
.NET Core實戰項目之CMS 第十章 設計篇-系統開發框架設計
.NET Core實戰項目之CMS 第十一章 開發篇-數據庫生成及實體代碼生成器開發
.NET Core實戰項目之CMS 第十二章 開發篇-Dapper封裝GURD及倉儲代碼生成器實現
.NET Core實戰項目之CMS 第十三章 開發篇-在MVC項目結構介紹及應用第三方UI
原文地址:https://www.cnblogs.com/yilezhu/p/10229954.html
.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com
總結
以上是生活随笔為你收集整理的.NET Core实战项目之CMS 第十四章 开发篇-防止跨站请求伪造（XSRF/CSRF）攻击处理...的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 领域驱动设计，让程序员心中有码（五）
- 下一篇： 在.Net Core WebAPI下给S