【第三篇】ASP.NET MVC快速入門之安全性原則（MVC5+EF6）

標籤：val   boot   .config   web伺服器   方式   物理   標籤   empty   blog   

【第一篇】ASP.NET MVC快速入門之資料庫操作（MVC5+EF6）

【第二篇】ASP.NET MVC快速入門之資料註解（MVC5+EF6）

【第三篇】ASP.NET MVC快速入門之安全性原則（MVC5+EF6）

【第四篇】ASP.NET MVC快速入門之完整樣本（MVC5+EF6）

【番外篇】ASP.NET MVC快速入門之免費jQuery控制項陳列庫（MVC5+EF6）

 

請關注三石的部落格：http://cnblogs.com/sanshi

 

表單身分識別驗證（Forms Authentication）WebForms中的表單身分識別驗證

在講解MVC提供的安全性原則之前，還是先看下WebForms中常見的表單身分識別驗證（Forms Authentication），這種身分識別驗證的過程也很簡單：

1. 使用者提供登入資訊（比如使用者名稱和密碼）。
2. 登入資訊驗證通過後，會建立一個包含使用者名稱的FormsAuthenticationTicket對象。
3. 對此Ticket對象進行加密，並將加密結果以字串的形式儲存到瀏覽器Cookie中。

 

後會的所有HTTP請求，都會帶上這個Cookie並由WebForms進行比對，同時對外公開如下兩個屬性：

1. HttpContext.User.Identity.IsAuthenticated
2. HttpContext.User.Identity.Name

 

在Web.config中，我們一般需要配置登入頁面（loginUrl）、登入後的跳轉頁面（defaultUrl），

登入後的保持時間（timeout）等資訊：

 

<system.web><authentication mode="Forms">      <forms loginUrl="~/default.aspx" timeout="120"defaultUrl="~/main.aspx" protection="All" path="/" /></authentication><authorization>      <deny users="?" /></authorization></system.web>

 

 

上面這個配置拒絕了所有使用者的匿名訪問，當然我們在<system.web>節的外面更改指定目錄的存取權限，比如：

 

<location path="res">       <system.web>         <authorization>              <allow users="*" />         </authorization>       </system.web></location>

 

 

這個配置允許匿名使用者對res目錄的訪問（一般是靜態資源）。

 

MVC中的表單身分識別驗證

MVC對驗證模型進行了重寫，但是基本的原理沒有變化，我們更關注的是不同點：

1. WebForms中基於目錄進行許可權控制。
2. MVC中對控制器或者控制器的方法進行許可權控制。

 

理解這一點也不難，因為MVC中沒有和物理目錄對應的URL，並且同一個控制器方法可能會對應多個訪問URL，這一過程是由路由引擎配置的，在第一篇文章中有簡單介紹。

 

Authorize註解

在MVC中，我們要保護的資源不是檔案夾目錄，而是控制器和控制器方法，所以MVC提供了授權過濾器（Authorize Filter）對此進行保護，它是以資料註解的形式提供的。

[Authorize]public class StudentsController : Controller{       ...}

 

這裡是對整個控制器進行了保護，防止匿名使用者存取，這時訪問會得到一個錯誤的頁面：

 

 

配置表單身分識別驗證

現在添加配置資訊：

<system.web><authentication mode="Forms">  <forms loginUrl="~/Home/Login" defaultUrl="~/Students" timeout="120" protection="All" path="/" /></authentication></system.web>

 

 

指定了登入頁面~/Home/Login，登入後的頁面是~/Students，現在再來瀏覽頁面：

http://localhost:55654/Students

 

 

 

這次訪問有兩個HTTP請求，並且瀏覽器地址欄的URL改變了：

http://localhost:55654/Home/Login?ReturnUrl=%2fStudents

 

這樣的地方我們很熟悉，ReturnUrl參數指定了登入成功後需要調整的頁面，而~/Home/Login則是我們剛剛在Web.config中配置的登入頁面。

 

兩個HTTP請求中的第一個，響應碼是302，這是一個重新導向響應，瀏覽器會自動識別302響應並跳轉到回應標頭中Location指定的網址。所以第二個請求是由瀏覽器發起的，但是我們尚未定義Login頁面，所以返回404未找到。

 

建立登入頁面

定義Home/Login控制器方法：

 

public class HomeController : Controller{       public ActionResult Login()       {              return View();       }}

 

 

 

在操作方法內部點擊右鍵，選擇[添加視圖…]功能表項目：

 

 

在彈出的嚮導對話方塊中，選擇[Empty(without Model)]，我們來手工建立視圖內容：

 

 

完成的視圖頁面：

 

@{    ViewBag.Title = "Login";}<h2>Login</h2>@using (Html.BeginForm()){    @Html.AntiForgeryToken()
    <input type="text" name="UserName" />    <input type="password" name="Password" />    <input type="submit" value="登入" />}

 

 

 

點擊[登入]按鈕，表單會通過POST請求提交到Login方法：

 

[HttpPost][ValidateAntiForgeryToken]public ActionResult Login(string UserName, string Password){       if(UserName == "sanshi" && Password == "pass")       {              FormsAuthentication.RedirectFromLoginPage("sanshi", false);       }       return View();}

 

 

 

這裡寫入程式碼了管理員的使用者名稱和密碼，在實際應用中可能需要從資料庫中讀取。

 

在布局中顯示登入狀態

接下來，我們需要在布局頁面（Shared/_Layout.cshtml）中放置登入後的資訊以及[退出系統]按鈕：

 

@if (User.Identity.IsAuthenticated){       using (Html.BeginForm("Logout", "Home", FormMethod.Post, new { id = "logoutForm" }))       {              @Html.AntiForgeryToken()              <ul class="nav navbar-nav navbar-right">                     <li><a href="javascript:;">Hello, @User.Identity.Name</a></li>                     <li><a href="javascript:;" id="logout">退出系統</a></li>              </ul>       }}else{       <ul class="nav navbar-nav navbar-right">              <li>@Html.ActionLink("登入", "Login", "Home")</li>       </ul>}

 

 

這段代碼有兩層邏輯：

1. 如果使用者已經驗證過身份，則顯示一個表單，裡面放置[Hello, sanshi]以及一個登入按鈕。受限於Bootstrap的內建樣式，這裡只能通過a標籤來取代input標籤，在頁面底部還會註冊指令碼來處理按鈕點擊事件。
2. 如果是匿名使用者，則顯示[登入]的超連結。

 

實現[退出系統]功能

註冊[退出系統]按鈕的用戶端處理指令碼，由於在產生表單標籤時（Html.BeginForm），我們設定了表單標籤的id屬性，所以點擊[退出系統]按鈕時簡單提交表單即可：

 

<script>       $(function () {              $(‘#logout‘).click(function () {                     $(‘#logoutForm‘).submit();              });       });</script>

 

 

 

[退出系統]按鈕的後台邏輯，需要先清空用戶端Cookie，然後執行用戶端跳轉：

 

[HttpPost][ValidateAntiForgeryToken]public ActionResult Logout(){       FormsAuthentication.SignOut();       return RedirectToAction("Index", "Home");}

 

 

運行效果

來看下頁面運行效果，首先是登入頁面：

 

登入成功後，直接跳轉到~/Students頁面：

 

 

跨站請求偽造（CSRF）

在前面的HTTP POST請求中，我們多次在View和Controller中看下如下代碼：

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

 

這樣看似一對的寫法其實是為了避免引入跨站請求偽造（CSRF）攻擊。

 

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

 

之所以很多大型網址也遭遇CSRF攻擊，是因為CSRF攻擊本身的流程就比較長，很多開發人員可能在幾年的時間都沒遇到CSRF攻擊，因此對CSRF的認知比較模糊，沒有引起足夠的重視。

 

CSRF攻擊的類比樣本

我們這裡將通過一個類比的樣本，講解CSRF的攻擊原理，然後再回過頭來看下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，會跳轉到登入頁面：

 

 

登入後，來到轉賬頁面，我們看下轉賬的視圖代碼：

 

@{    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是否為空白來顯示不同內容：

1. ViewBag.ToAccount為空白，則表明是頁面訪問。
2. 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的內容和當前發起請求的頁面地址一樣，注意對比：

1. 瀏覽器網址：click_me_please.html
2. HTTP請求地址：Home/TransferMoney
3. 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值，所以轉賬失敗。

 

過多提交攻擊（Over-Posting）

在編輯Student的控制器方法中，有一個Bind特性註解，我們來回顧一下：

 

[HttpPost][ValidateAntiForgeryToken]public ActionResult Edit([Bind(Include = "ID,Name,Gender,Major,EntranceDate")] Student student){       if (ModelState.IsValid)       {              db.Entry(student).State = EntityState.Modified;              db.SaveChanges();              return RedirectToAction("Index");       }       return View(student);}

 

 

 

這是為了防止Over-Posting攻擊，這個理解起來相對簡單一點，Bind特性的Include屬性用來指定一個白名單，所有在白名單中的屬性都會參與模型繫結。

 

假設在Student模型中增加一個[職務]的欄位：

public string Job {get; set;}

 

 

如果沒有Bind特性，那麼在更新Student資訊時，惡意使用者可以通過類比POST請求（第二篇文章有介紹）來提交Job的值，從而導致資料庫中使用者的Job改變。而Bind特性就是為了避免這種情況的發生。

 

Bind特性還提供了黑名單的設定方式，類似如下所示：

[Bind(Exclude = "Job")]

 

 

但是，一般我們推薦使用白名單，這樣即使模型發生改變，也不會影響到現有的功能。

 

=========【2017-01-07】更新==========================================

上面模型繫結時，通過Bind屬性指定了需要綁定的屬性列表，沒有指定Job屬性，所以模型繫結後Job=NULL

如果之前設定過Job="工程師"，那麼通過如下代碼：

db.Entry(student).State = EntityState.Modified;db.SaveChanges();

之後，這個Job就會被設為NULL，執行的SQL語句：

exec sp_executesql N‘UPDATE [dbo].[Students]SET [Name] = @0, [Gender] = @1, [Major] = @2, [Job] = NULL, [EntranceDate] = @3WHERE ([ID] = @4)‘,N‘@0 nvarchar(200),@1 int,@2 nvarchar(200),@3 datetime2(7),@4 int‘,@0=N‘張三石8‘,@1=1,@2=N‘材料科學與工程系‘,@3=‘2000-09-01 00:00:00‘,@4=1go

可見，雖然我僅僅更改了Name欄位，但是全部欄位都會被更新到資料，並且Job被覆蓋為NULL。

 

這是我們不希望看到的結果。

 

解決方案一：

我們可以通過設定Job屬性未改變，來不更新Job欄位：

db.Entry(student).State = EntityState.Modified;db.Entry(student).Property(s => s.Job).IsModified = false;db.SaveChanges();

此時的SQL語句：

exec sp_executesql N‘UPDATE [dbo].[Students]SET [Name] = @0, [Gender] = @1, [Major] = @2, [EntranceDate] = @3WHERE ([ID] = @4)‘,N‘@0 nvarchar(200),@1 int,@2 nvarchar(200),@3 datetime2(7),@4 int‘,@0=N‘張三石9‘,@1=1,@2=N‘材料科學與工程系‘,@3=‘2000-09-01 00:00:00‘,@4=1go

 

解決方案二：

我們也可以先從資料庫擷取Student對象，然後更新部分欄位：

 

var _student = db.Students.Find(student.ID);_student.Name = student.Name;_student.Gender = student.Gender;_student.Major = student.Major;_student.EntranceDate = student.EntranceDate;

db.SaveChanges();

 

 

此時會有兩個SQL查詢，第一個是按照ID檢索，第二個是更新：

 

exec sp_executesql N‘SELECT TOP (2)     [Extent1].[ID] AS [ID],     [Extent1].[Name] AS [Name],     [Extent1].[Gender] AS [Gender],     [Extent1].[Major] AS [Major],     [Extent1].[Job] AS [Job],     [Extent1].[EntranceDate] AS [EntranceDate]    FROM [dbo].[Students] AS [Extent1]    WHERE [Extent1].[ID] = @p0‘,N‘@p0 int‘,@p0=1goexec sp_executesql N‘UPDATE [dbo].[Students]SET [Name] = @0WHERE ([ID] = @1)‘,N‘@0 nvarchar(200),@1 int‘,@0=N‘張三石10‘,@1=1go

 

 

特別注意：此時的SQL更新語句，不再是全部更新，而是僅僅更新變化的資料（因為通過第一次的查詢，EF知道資料庫的欄位值，從而可以得知那些需要更新）。

 

 =========【2017-01-07】更新==========================================

 

 

小結

本篇文章首先介紹了MVC下Forms Authentication的實現方式以及與WebForms下表單身分識別驗證的區別。然後重點講解了跨站請求偽造攻擊（CSRF），由於這種攻擊流程比較長，理解起來比較晦澀，我們特地製作了一個攻擊案例，希望能夠引起開發人員的重視。Over-Posting攻擊相對比較簡單，但是需要我們在實際編碼中嚴格遵守安全指引，不能存在僥倖心裡。當然還有其他類型的攻擊，比如跨站指令碼攻擊（XSS），Cookie盜取，開放重新導向攻擊等等，限於篇幅原因就不一一介紹。

從下一篇文章開始，我們將逐漸豐富樣本的功能，先為表格頁面增加一個搜尋表單，可以根據不同的查詢條件顯示表格式資料。

下載樣本原始碼

 

【第三篇】ASP.NET MVC快速入門之安全性原則（MVC5+EF6）