【第三篇】ASP.NET MVC快速入門之安全策略(MVC5+EF6)

三生石上(FineUI控制元件)發表於2016-12-27

目錄

【第一篇】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請求中,我們多次在ViewController中看下如下程式碼:

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標籤,並在裡面放置了駭客自己的銀行賬號和轉賬金額,在頁面開啟時提交表單(bodyonload屬性)。

 

現在駭客把這兩個頁面放到公網:

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伺服器來說都是全新的,伺服器不知道之前請求的任何狀態,而身份驗證需要我們在第二次訪問時知道是否登入的狀態(不可能每次請求都驗證賬號密碼),這本身就是一種矛盾!

 

解決這個矛盾的辦法就是CookieCookie可以在瀏覽器中儲存少量資訊,所以Forms Authentication就用Cookie來儲存加密過的身份資訊。而Cookie中儲存的全部值在每次HTTP請求中(不管是GET還是POST,也不管是靜態資源還是動態資源)都會被髮送到伺服器,這也就給CSRF以可乘之機。

 

所以,CSRF的根源在於伺服器可以從Cookie中獲知身份驗證資訊,而無法得知本次HTTP請求是否真的是使用者發起的。

 

Referer驗證

RefererHTTP請求頭資訊中的一部分,每當瀏覽器向伺服器傳送請求時,都會附帶上Referer資訊,表明當前發起請求的頁面地址。

 

一個正常的轉賬請求,我們可以看到Referer和瀏覽器位址列是一致的:

 

我們再來看下剛才的駭客頁面:

 

可以看到Referer的內容和當前發起請求的頁面地址一樣,注意對比:

1.     瀏覽器網址:click_me_please.html

2.     HTTP請求地址:Home/TransferMoney

3.     Refererclick_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】更新==========================================


 

 

小結

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

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

下載示例原始碼

 

 

 

相關文章