第七章 成員資格、授權(quán)和安全性

1、第七章 成員資格、授權(quán)和安全性7.1 安全性ASP.NET MVC 提供了許多內(nèi)置的保護(hù)機(jī)制（默認(rèn)利用 HTML 輔助方法和Razor 語法進(jìn)行 HTML編碼以及請求驗證等功能特性，以及通過基架構(gòu)建的控制器白名單表單元素來防止重復(fù)提交攻擊）永遠(yuǎn)不要相信用戶提交的任何數(shù)據(jù)。實際的例子每次渲染用戶提交的數(shù)據(jù)的時候?qū)ζ溥M(jìn)行編碼?？紤]好網(wǎng)站哪些部分允許用戶匿名訪問，哪些部分需要認(rèn)證訪問。不要試圖自己凈化用戶的HTML 輸入，否則就會失敗。在不需要通過客戶端腳本訪問cookie時，使用HTTP-only cookie請記住外部輸入不只是顯式的表單域。建議使用AntiXSS 編碼器。黑 客、解密高手、垃圾

2、郵件發(fā)送者、病毒、惡意軟件它們都想進(jìn)入計算讀查看里面的數(shù)據(jù)。在閱讀本段內(nèi)容時，我們的電子郵箱很可能已經(jīng)轉(zhuǎn)發(fā)了很多封電子郵 件。我們的端口遭到了掃描，而一個自動化的蠕蟲病毒很有可能正在嘗試通過多種操作系統(tǒng)漏洞找到進(jìn)入PC的途徑。由于這些攻擊都是自動的，因此它們在不斷地 探索，尋找一個開放的系統(tǒng)。應(yīng)用程序的構(gòu)建基于這樣一種假設(shè)，即只有特定用戶才能執(zhí)行某些操作，而其它用戶則不能執(zhí)行這些操作。7.2 使用Authorize 特性登錄        保護(hù)應(yīng)用程序安全的第一步，同時也是最簡單的一步，就是要求用戶只有登錄系統(tǒng)才能訪問應(yīng)用程

3、序的特定部分。         Authorize Attribute 是ASP.NET MVC 自帶的默認(rèn)授權(quán)過濾器，可用來限制用戶對操作方法的訪問。    Tips:身份驗證和授權(quán)身份驗證是指通過某種形式的登錄機(jī)制(包括用戶名/密碼、OpenID、OAuth 等說明自已身份的項)來核實用戶身份。授權(quán)驗證是用來核實登錄站點的用戶是否在他們的權(quán)限內(nèi)執(zhí)行操作。這通常使用一些基于聲明的系統(tǒng)來實現(xiàn)。Authorize 特性不帶任何參數(shù)，只要求用戶以某種角色登錄網(wǎng)站。它禁止匿名訪問。

4、7.2.1 保護(hù)控制器操作實現(xiàn)安全性的一個好方法是，始終使安全性檢查盡可能的貼近要保護(hù)的對象?？赡苡衅渌邔拥臋z查，但始終都要確保實際資源的安全。7.2.2 Authorize 特性在表單身份驗證和AccountController 控制器中的用法基本驗證信息 IPrincipal user=httpContext.User; if(!user.Identity.IsAuthenticated) return false; if(_usersSplit.Length>0&&!_usersSplit.Contains(user.Identity.Name,StringCo

5、mparer.OrdinalIgnoreCase) return false; if(_rolesSplit.Length>0&&!_rolesSplit.Any(user.IsInRole) return false; return true; 如果用戶身份驗證失敗，就會返回一個HttpUnauthorizedResult 操作結(jié)果，它產(chǎn)生了一個 HTTP 401(未授權(quán))的狀態(tài)碼。7.2.3 Windows Authentication為使用Intranet 驗證選項，我們需要啟用Windows 驗證，禁用 Anonymous 驗證。使用全局授權(quán)過濾器保障整個應(yīng)用程序

6、安全MVC 4中新添加了AllowAnonymous 特性。如果把AuthorizeAttribute 注冊為全局過濾器，并且有些方法需要外部訪問，那么這些方法只需要使用4中新添加了AllowAnonymous 特性裝飾即可。AllowAnonymous 僅對標(biāo)準(zhǔn)的AuthorizeAttribute 有效；對于自定義的授權(quán)過濾器，則不一定起作用。全局授權(quán)僅對MVC 是全局的7.3 要求角色成員使用Authorize 特性Authorize 特性允許指定角色和用戶。Roles 參數(shù)可以有多個角色，我們用，分割：7.4 擴(kuò)展用戶身份7.4.1 存儲用戶額外的信息Code First 模式下只需要

7、在用戶類中添加屬性。7.5 通過OAuth 和 OpenID 的外部登錄OAuth 和 OpenID 是開放的標(biāo)準(zhǔn)。這些協(xié)議允許用戶使用他們已有的賬戶登錄我們的網(wǎng)站。配置網(wǎng)站以支持OAuth 和 OpenID是非常難以實現(xiàn)的，協(xié)議復(fù)雜，頂級提供器對這兩種協(xié)議的實現(xiàn)方式不一樣。MVC 通過在使用Individual User Accounts 身份驗證的項目模板中內(nèi)置支持OAuth 和 OpenID 極大的簡化了這一點。7.5.1 注冊外部登錄提供器使用OAuth 提供器的網(wǎng)站要求我們把網(wǎng)站注冊為一個應(yīng)用程序。這樣它們會提供給我們一個客戶端id 和一個口令。我們利用OAuth 提供器根據(jù)這些信息

8、就可以進(jìn)行驗證。7.5.2 配置OpenID提供器因為不用注冊，不用填寫參數(shù)，配置OAuth 提供器是非常簡單的。7.5.3 配置OAuth提供器7.5.4 外部登錄的安全性1,可信的外部登錄器2，要求SSL 登錄從外部提供器到我們網(wǎng)站的回調(diào)中包含擁有用戶信息的安全令牌，這些令牌允許訪問我們的網(wǎng)站。當(dāng)令牌在Internet 中傳遞時，使用HTTPS 傳輸是非常重要的，因為這樣可以訪問信息攔截。為訪問AccountController 的Login Get 方法并執(zhí)行HTTPS,支持外部登錄的應(yīng)用程序應(yīng)該使用 RequireHttps 特性來使用HTTPS / /GET:/Accoun

9、t/login RequireHttps AllowAnonymous pulic ActionResult Login(string returnUrl) ViewBag.ReturnUrl=returnUrl; return View(); 7.6 Web 應(yīng)用程序中安全向量因為Web 應(yīng)用程序運(yùn)行在標(biāo)準(zhǔn)的、基于文本的協(xié)議（像HTTP和HTML）之上，所以它們特別容易受到自動攻擊的傷害。7.6.1 威脅：跨站腳本(XSS)1,威脅概述有 兩種方法可以實現(xiàn)XSS，一種方法是通過用戶將惡意腳本輸入到網(wǎng)站中，而這些網(wǎng)站又可以接收“不干凈”（unsanitized）的用戶輸入。另一種方法 是通過直

10、接在頁面上顯示用戶的輸入。第一種情況被稱為“被動注入”(Passive Injection)。用戶把“不干凈的”的        內(nèi)容輸入到文本框，并把這些數(shù)據(jù)保存在數(shù)據(jù)庫中，以后再重新在頁面上顯示。第二種方法稱為“主動注入”，涉及用戶直接把“不干凈”的內(nèi)容輸入到文本框中， 這些輸入的內(nèi)容會立刻被顯示出來。2，被動注入eg: "></a><script src="hackScript.js"></script><a href=" 3，主動

11、注入eg: ?Search=<form action=""><input type="text" name="name" /><input type="password" name="password" /><input type="submit" value="登錄" /> 4，阻止 XSS1）對所有內(nèi)容進(jìn)行HTML 編碼頁面上每一個輸出都應(yīng)該是經(jīng)過HTML 編碼或HTML 特性編碼。2）Html.Attr

12、ibuteEncode 和 Url.Encode謹(jǐn)記：永遠(yuǎn)不要信任用戶能夠接觸到或者使用的一切數(shù)據(jù)，其中包括所有的表單值、URL、cookie或來自第三方源（如OpenID）的個人信息。此外網(wǎng)站所訪問的數(shù)據(jù)庫或服務(wù)可能沒有經(jīng)過編碼，所以不要輕易相信輸入應(yīng)用程序的任何數(shù)據(jù)，要盡可能的對其編碼。3）JavaScript 編碼黑客可以很隨意的利用十六進(jìn)制轉(zhuǎn)義碼隨意的向輸入內(nèi)容中插入JavaScript 腳本代碼4）將AntiXSS 庫作為ASP.NET 的默認(rèn)編碼器AntiXSS 使用的是一個信任字符的白名單，ASP.NET 默認(rèn)實現(xiàn)一個有限的不信任字符的黑名單。AntiXSS 的重點是阻止應(yīng)用程序

13、的漏洞，ASP.NET 關(guān)注的是防止HTML 頁面顯示不被破壞。在.NET 4.5及更高版本包含 MicroSoft WPL(Web Protection Library)的AntiXSS 編碼器。要使用AntiXSS 庫需要在 Web.config 的 httpRunTime 中添加以下代碼：< httpRuntime . encoderType="System.Web.Security.AntiXss.AntiXssEncoder,System.Web,Version=,Culture=neutral,PublicKeyToken=b03f5f7f11d59a

14、3a"/>7.6.2 威脅：跨站請求偽造跨站請求偽造（Cross-Site Request Forgery,CSRF,有時也寫作XSRF 表示）要比簡單的跨站腳本攻擊更具有危險性。1，威脅概述eg:用戶退出登錄方法為：/account/Logout用戶將評論中提交這樣一個標(biāo)簽<img src="瀏覽器將自動向該地址發(fā)送Get 請求。2,阻止 CSRF 攻擊ASP.NET MVC 提供了阻止 CSRF 攻擊的方法。1)令牌驗證Html.AntiForgeryToken 輔助方法會生成一個加密值作為隱藏的輸入元素。該值會與作為會話cookie 存儲在用戶瀏覽器的另一

15、個值相匹配。在提交表單時，ActionFilter 會驗證這兩個值是否相匹配。這種方法可以阻止大部分的CSRF 攻擊。2)冪等的GET 請求一個冪等操作的特點是執(zhí)行一次和執(zhí)行多次的效果是一樣的。一般來說，僅通過POST 修改數(shù)據(jù)庫中或網(wǎng)站上的內(nèi)容可以有效防御全部的CSRF 攻擊。3) HttpReferrer 驗證HttpReferrer 驗證通過使用ActionFilter 處理。這種情況下可以查看提交表單值的客戶段是否在目標(biāo)站點上。7.6.3 威脅：cookie 盜竊如果能夠竊取某人在一個網(wǎng)站上的身份驗證Cookie,就可以在該網(wǎng)站上冒充他，執(zhí)行他權(quán)限內(nèi)的所有操作。這種攻擊依賴于 XSS

16、漏洞。攻擊者需要在目標(biāo)站點上注入一些腳本，才能竊取 CookieStackO 允許在評論中包含提交一定數(shù)量的HTML 標(biāo)記可以停止腳本對站點中cookie 的訪問，需要設(shè)置一個簡單的標(biāo)志：HttpOnly可以在 web.config 文件中對所有的Cookie 設(shè)置，也可以為編寫的每個Cookie 單獨(dú)設(shè)置。7.6.4 威脅：重復(fù)提交重復(fù)提交:惡意用戶向查詢字符串或提交的表單添加超出用戶最終操作權(quán)限的值。防御重復(fù)提交最簡單的一個方法是使用Bind 特性顯式的控制需要由模型綁定器綁定的屬性。也可以用 UpdateModel 或 TryUpdateModel 方法的一個重載版本接受一個綁定列表。7

17、.6.5 威脅：開放重定向1.威脅概述那些通過請求(如查詢字符串和表單數(shù)據(jù))指向重定向URL 的WEB 應(yīng)用程序可能被篡改，而把用戶重定向到外部的惡意URL。這種篡改就被稱為開放重定向攻擊（open redirection attack）。可以調(diào)用 IsLocalUrl()方法對 returnUrl 參數(shù)進(jìn)行驗證。7.7 適當(dāng)?shù)腻e誤報告和堆棧跟蹤customErrors 模式有3 個可選設(shè)置項，分別是：On:服務(wù)器開發(fā)最安全選項，因為它總是隱藏錯誤提示消息。RemoteOnly:向大多數(shù)用戶展示一般的錯誤信息，但向擁有服務(wù)器訪問權(quán)限的用戶展示完整的錯誤提示消息。Off:最容易受到攻擊的選項，它向每一個網(wǎng)站的訪問者展示詳細(xì)的錯誤處理。7.7.1 使用配置轉(zhuǎn)換使用Remote