CSRF(Cross site request forgery)利用了web中用戶身份驗證的一個漏洞：簡單的身份驗證只能保證請求發自某個用戶的瀏覽器，卻不能保證請求本身是用戶自願發出的。 例子 在某個論壇管理頁面，管理員可以在list頁面執行刪除帖子操作，根據URL判斷刪除帖子的id，像這樣的一個U ...
CSRF(Cross-site request forgery)利用了web中用戶身份驗證的一個漏洞：簡單的身份驗證只能保證請求發自某個用戶的瀏覽器，卻不能保證請求本身是用戶自願發出的。
例子
在某個論壇管理頁面，管理員可以在list頁面執行刪除帖子操作，根據URL判斷刪除帖子的id，像這樣的一個URL
http://localhost/list?action=delete&id=12當惡意用戶向管理員發送包含CSRF的郵件，騙取管理員訪問http://test.com/csrf,在這個惡意網頁中只要包含這樣的html語句就可以利用讓管理員在不知情的情況下刪除帖子了
<img alt="" arc="http://localhost/list?action=delete&id=12"/>這種惡意的網址可以有很多種形式，藏身於網頁中的許多地方。此外，攻擊者也不需要控制放置惡意網址的網站。例如他可以將這種地址藏在論壇，博客等任何用戶生成內容的網站中。這意味著如果服務端沒有合適的防禦措施的話，用戶即使訪問熟悉的可信網站也有受攻擊的危險。
透過例子能夠看出，攻擊者並不能通過CSRF攻擊來直接獲取用戶的賬戶控制權，也不能直接竊取用戶的任何信息。他們能做到的，是欺騙用戶瀏覽器，讓其以用戶的名義運行操作。
解決方案
- 檢查Referer欄位
- 添加校驗token。使用攻擊者無法偽造的數據作為校驗
ASP.NET Core中提供了防偽造令牌，這樣的令牌需要從用戶應該使用的表單中創建，以輸入有效數據，併在接受數據時進行驗證。
<form asp-controller="Home" asp-action="Edit" method="post">
@Html.AntiForgeryToken()
<input type="text" />
<input type="text" />
<input type="submit" value="Submit" />
</form>運行應用程式時，可以看到一個隱藏的表單欄位，其中包含自動生成的令牌。當檢索這個數據時，使用ValidateAntiForgeryToken屬性對標記進行驗證。
[HttpPost]
[ValidateAntiForgeryToken]
public IActionResult Edit(EditModel model) => View("EditResult", model);
