【第三篇】ASP.NET MVC快速入門之安全策略（MVC5+EF6）
【第一篇】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），這種身份驗證的過程也很簡單：
- 用戶提供登錄信息（比如用戶名和密碼）。
- 登錄信息驗證通過後，會創建一個包含用戶名的FormsAuthenticationTicket對象。
- 對此Ticket對象進行加密，並將加密結果以字符串的形式保存到瀏覽器Cookie中。
後會的所有HTTP請求，都會帶上這個Cookie並由WebForms進行比對，同時對外公開如下兩個屬性：
- HttpContext.User.Identity.IsAuthenticated
- 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對驗證模型進行了重寫，但是基本的原理沒有變化，我們更關註的是不同點：
- WebForms中基於目錄進行權限控制。
- 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>
}
這段代碼有兩層邏輯：
- 如果用戶已經驗證過身份，則顯示一個表單，裏面放置[Hello, sanshi]以及一個登錄按鈕。受限於Bootstrap的內置樣式，這裏只能通過a標簽來取代input標簽，在頁面底部還會註冊腳本來處理按鈕點擊事件。
- 如果是匿名用戶，則顯示[登錄]的超鏈接。
實現[退出系統]功能
註冊[退出系統]按鈕的客戶端處理腳本，由於在生成表單標簽時（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中看下如下代碼：
- View中調用了Html.AntiForgeryToken()。
- 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是否為空來顯示不同內容：
- 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值，所以轉賬失敗。
過多提交攻擊（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] = @3 WHERE ([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=1 go
可見，雖然我僅僅更改了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] = @3 WHERE ([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=1 go
解決方法二：
我們也可以先從數據庫獲取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=1
go
exec sp_executesql N‘UPDATE [dbo].[Students]
SET [Name] = @0
WHERE ([ID] = @1)
‘,N‘@0 nvarchar(200),@1 int‘,@0=N‘張三石10‘,@1=1
go
特別註意：此時的SQL更新語句，不再是全部更新，而是僅僅更新變化的數據（因為通過第一次的查詢，EF知道數據庫的字段值，從而可以得知那些需要更新）。
=========【2017-01-07】更新==========================================
小結
本篇文章首先介紹了MVC下Forms Authentication的實現方式以及與WebForms下表單身份驗證的區別。然後重點講解了跨站請求偽造攻擊（CSRF），由於這種攻擊流程比較長，理解起來比較晦澀，我們特地制作了一個攻擊案例，希望能夠引起開發人員的重視。Over-Posting攻擊相對比較簡單，但是需要我們在實際編碼中嚴格遵守安全指引，不能存在僥幸心裏。當然還有其他類型的攻擊，比如跨站腳本攻擊（XSS），Cookie盜取，開放重定向攻擊等等，限於篇幅原因就不一一介紹。
從下一篇文章開始，我們將逐漸豐富示例的功能，先為表格頁面增加一個搜索表單，可以根據不同的查詢條件顯示表格數據。
下載示例源代碼
【第三篇】ASP.NET MVC快速入門之安全策略（MVC5+EF6）