ASP.NET MVC 防止跨站請求僞造（CSRF）攻擊的方法

時間 2019-11-09

標籤 asp.net asp mvc 防止請求僞造 csrf 攻擊方法欄目 ASP 简体版

原文原文鏈接

在HTTP POST請求中，咱們屢次在View和Controller中看下以下代碼：html

View中調用了Html.AntiForgeryToken()。
Controller中的方法添加了[ValidateAntiForgeryToken]註解。

這樣看似一對的寫法實際上是爲了不引入跨站請求僞造（CSRF）攻擊。瀏覽器

這種攻擊形式大概在2001年才爲人們所認知，2006年美國在線影片租賃網站Netflix爆出多個CSRF漏洞，2008年流行的視頻網址YouTube受到CSRF攻擊，同年墨西哥一家銀行客戶受到CSRF攻擊，殺毒廠商McAfee也曾爆出CSRF攻擊（引自wikipedia）。安全

之因此不少大型網址也遭遇CSRF攻擊，是由於CSRF攻擊自己的流程就比較長，不少開發人員可能在幾年的時間都沒遇到CSRF攻擊，所以對CSRF的認知比較模糊，沒有引發足夠的重視。服務器

CSRF攻擊的模擬示例

咱們這裏將經過一個模擬的示例，講解CSRF的攻擊原理，而後再回過頭來看下MVC提供的安全策略。mvc

看似安全的銀行轉帳頁面

假設咱們是銀行的Web開發人員，如今須要編寫一個轉帳頁面，客戶登陸後在此輸入對方的帳號和轉出的金額，便可實現轉帳：函數

[Authorize]
public ActionResult TransferMoney()
{
       return View();
}

[HttpPost]
[Authorize]
public ActionResult TransferMoney(string ToAccount, int Money)
{
       // 這裏放置轉帳業務代碼

       ViewBag.ToAccount = ToAccount;
       ViewBag.Money = Money;
       return View();
}

因爲這個過程須要身份驗證，因此咱們爲TransferMoney的兩個操做方法都加上了註解[Authorize]，以阻止匿名用戶的訪問。網站

若是直接訪問http://localhost:55654/Home/TransferMoney，會跳轉到登陸頁面：ui

登陸後，來到轉帳頁面，咱們看下轉帳的視圖代碼：加密

@{
    ViewBag.Title = "Transfer Money";
}
 
<h2>Transfer Money</h2>
 
@if (ViewBag.ToAccount == null)
{
    using (Html.BeginForm())
    {
        <input type="text" name="ToAccount" />
        <input type="text" name="Money" />
        <input type="submit" value="轉帳" />
    }
}
else
{
    @:您已經向帳號 [@ViewBag.ToAccount] 轉入 [@ViewBag.Money] 元！
}

視圖代碼中有一個邏輯判斷，根據ViewBag.ToAccount是否爲空來顯示不一樣內容：spa

ViewBag.ToAccount爲空，則代表是頁面訪問。
ViewBag.ToAccount不爲空，則爲轉帳成功，須要顯示轉帳成功的提示信息。

來看下頁面運行效果：

功能完成！看起來沒有任何問題，可是這裏卻又一個CSRF漏洞，隱蔽而難於發現。

我是黑客，Show me the money

這裏就有兩個角色，銀行的某個客戶A，黑客B。

黑客B發現了銀行的這個漏洞，就寫了兩個簡單的頁面，頁面一（click_me_please.html）：

<!DOCTYPE html>
<html>
<head>
    <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
</head>
<body>
      
       哈哈，逗你玩的！
      
       <iframe frameborder="0"
style="display:none;" src="./click_me_please_iframe.html"></iframe>
 
</body>
</html>

第一個頁面僅包含了一個隱藏的iframe標籤，指向第二個頁面（click_me_please_iframe.html）：

<!DOCTYPE html>
<html>
<head>
    <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
</head>
<body onload="document.getElementById('myform1').submit();">
 
      
       <form method="POST" id="myform1"
action="http://localhost:55654/Home/TransferMoney">
              <input type="hidden" name="ToAccount" value="999999999">
              <input type="hidden" name="Money" value="3000">
       </form>
 
</body>
</html>

第二個頁面放置了一個form標籤，並在裏面放置了黑客本身的銀行帳號和轉帳金額，在頁面打開時提交表單（body的onload屬性）。

如今黑客把這兩個頁面放到公網：

http://fineui.com/demo_mvc/csrf/click_me_please.html

而後批量向用戶發送帶有攻擊連接的郵件，而銀行的客戶A恰好登陸了銀行系統，而且手賤點擊了這個連接：

而後你將看到這個頁面：

你可能會在內心想，誰這麼無聊，而後鬱悶的關閉了這個頁面。以後客戶A會更加鬱悶，由於黑客B的銀行帳號[999999999]已經成功多了3000塊錢！

到底怎麼轉帳的，不是有身份驗證嗎

是的。轉帳的確是須要身份驗證，如今的問題是你登陸了銀行系統，已經完成了身份驗證，而且在瀏覽器新的Tab中打開了黑客的連接，咱們來看下到底發生了什麼：

這裏有三個HTTP請求，第一個就是[逗你玩]頁面，第二個是裏面的IFrame頁面，第三個是IFrame加載完畢後發起的POST請求，也就是具體的轉帳頁面。由於IFrame是隱藏的，因此用戶並不知道發生了什麼。

咱們來具體看下第三個請求：

明顯此次轉帳是成功的，而且Cookie中帶上了用戶身份驗證信息，全部後臺根本不知道此次請求是來自黑客的頁面，轉帳成功的返回內容：

如何阻止CSRF攻擊

從上面的實例咱們能夠看出，CSRF源於表單身份驗證的實現機制。

因爲HTTP自己是無狀態的，也就是說每一次請求對於Web服務器來講都是全新的，服務器不知道以前請求的任何狀態，而身份驗證須要咱們在第二次訪問時知道是否登陸的狀態（不可能每次請求都驗證帳號密碼），這自己就是一種矛盾！

解決這個矛盾的辦法就是Cookie，Cookie能夠在瀏覽器中保存少許信息，因此Forms Authentication就用Cookie來保存加密過的身份信息。而Cookie中保存的所有值在每次HTTP請求中（不論是GET仍是POST，也不論是靜態資源仍是動態資源）都會被髮送到服務器，這也就給CSRF以可乘之機。

因此，CSRF的根源在於服務器能夠從Cookie中獲知身份驗證信息，而沒法得知本次HTTP請求是否真的是用戶發起的。

Referer驗證

Referer是HTTP請求頭信息中的一部分，每當瀏覽器向服務器發送請求時，都會附帶上Referer信息，代表當前發起請求的頁面地址。

一個正常的轉帳請求，咱們能夠看到Referer和瀏覽器地址欄是一致的：

咱們再來看下剛纔的黑客頁面：

能夠看到Referer的內容和當前發起請求的頁面地址同樣，注意對比：

瀏覽器網址：click_me_please.html
HTTP請求地址：Home/TransferMoney
Referer：click_me_please_iframe.html，注意這個是發起請求的頁面，而不必定就是瀏覽器地址欄顯示的網址。

基於這個原理，咱們能夠簡單的對轉帳的POST請求進行Referer驗證：

[HttpPost]
[Authorize]
public ActionResult TransferMoney(string ToAccount, int Money)
{
       if(Request.Url.Host != Request.UrlReferrer.Host)
       {
              throw new Exception("Referrer validate fail!");
       }
 
       // 這裏放置轉帳業務代碼
 
       ViewBag.ToAccount = ToAccount;
       ViewBag.Money = Money;
       return View();
}

此時訪問http://fineui.com/demo_mvc/csrf/click_me_please.html，惡意轉帳失敗：

MVC默認支持的CSRF驗證

MVC默認提供的CSRF驗證方式更加完全，它經過驗證當前請求是否真的來自用戶的操做。

在視圖頁面，表單內部增長對Html.AntiForgeryToken函數的調用：

@if (ViewBag.ToAccount == null)
{
    using (Html.BeginForm())
    {
        @Html.AntiForgeryToken()

        <input type="text" name="ToAccount" />
        <input type="text" name="Money" />
        <input type="submit" value="轉帳" />
    }
}
else
{
    @:您已經向帳號 [@ViewBag.ToAccount] 轉入 [@ViewBag.Money] 元！
}

這會在表單標籤裏面和Cookie中分別生成一個名爲__RequestVerificationToken 的Token：

而後添加[ValidateAntiForgeryToken]註解到控制器方法中：

[HttpPost]
[Authorize]
[ValidateAntiForgeryToken]
public ActionResult TransferMoney(string ToAccount, int Money)
{
       // 這裏放置轉帳業務代碼

       ViewBag.ToAccount = ToAccount;
       ViewBag.Money = Money;
       return View();
}

在服務器端，會驗證這兩個Token是否一致（不是相等），若是不一致就會報錯。

下面手工修改表單中這個隱藏字段的值，來看下錯誤提示：

相似的道理，運行黑客頁面http://fineui.com/demo_mvc/csrf/click_me_please.html，惡意轉帳失敗：

此時，雖然Cookie中的__RequestVerificationToken提交到了後臺，可是黑客沒法得知表單字段中的__RequestVerificationToken值，因此轉帳失敗。