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

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

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

3、帶的默認(rèn)授權(quán)過濾器，可用來限制用戶對操作方法的訪問。Tips:身份驗(yàn)證和授權(quán)身份驗(yàn)證是指通過某種形式的登錄機(jī)制(包括用戶名/密碼、OpenID、OAuth 等說明自已身份的項(xiàng))來核實(shí)用戶身份。授權(quán)驗(yàn)證是用來核實(shí)登錄站點(diǎn)的用戶是否在他們的權(quán)限內(nèi)執(zhí)行操作。這通常使用一些基于聲明的系統(tǒng)來實(shí)現(xiàn)。Authorize 特性不帶任何參數(shù)，只要求用戶以某種角色登錄網(wǎng)站。它禁止匿名訪問。7.2.1 保護(hù)控制器操作實(shí)現(xiàn)安全性的一個(gè)好方法是，始終使安全性檢查盡可能的貼近要保護(hù)的對象?？赡苡衅渌邔拥臋z查，但始終都要確保實(shí)際資源的安全。7.2.2 Authorize 特性在表單身份驗(yàn)證和AccountControl

4、ler 控制器中的用法基本驗(yàn)證信息 IPrincipal user=httpContext.User; if(!user.Identity.IsAuthenticated) return false; if(_usersSplit.Length0&!_usersSplit.Contains(user.Identity.Name,StringComparer.OrdinalIgnoreCase) return false; if(_rolesSplit.Length0&!_rolesSplit.Any(user.IsInRole) return false; return true; 如果用戶身

5、份驗(yàn)證失敗，就會(huì)返回一個(gè)HttpUnauthorizedResult 操作結(jié)果，它產(chǎn)生了一個(gè) HTTP 401(未授權(quán))的狀態(tài)碼。7.2.3 Windows Authentication為使用Intranet 驗(yàn)證選項(xiàng)，我們需要啟用Windows 驗(yàn)證，禁用 Anonymous 驗(yàn)證。使用全局授權(quán)過濾器保障整個(gè)應(yīng)用程序安全MVC 4中新添加了AllowAnonymous 特性。如果把AuthorizeAttribute 注冊為全局過濾器，并且有些方法需要外部訪問，那么這些方法只需要使用4中新添加了AllowAnonymous 特性裝飾即可。AllowAnonymous 僅對標(biāo)準(zhǔn)的Authori

6、zeAttribute 有效；對于自定義的授權(quán)過濾器，則不一定起作用。全局授權(quán)僅對MVC 是全局的7.3 要求角色成員使用Authorize 特性Authorize 特性允許指定角色和用戶。Roles 參數(shù)可以有多個(gè)角色，我們用，分割：7.4 擴(kuò)展用戶身份7.4.1 存儲(chǔ)用戶額外的信息Code First 模式下只需要在用戶類中添加屬性。7.5 通過OAuth 和 OpenID 的外部登錄OAuth 和 OpenID 是開放的標(biāo)準(zhǔn)。這些協(xié)議允許用戶使用他們已有的賬戶登錄我們的網(wǎng)站。配置網(wǎng)站以支持OAuth 和 OpenID是非常難以實(shí)現(xiàn)的，協(xié)議復(fù)雜，頂級提供器對這兩種協(xié)議的實(shí)現(xiàn)方式不一樣。MV

7、C 通過在使用Individual User Accounts 身份驗(yàn)證的項(xiàng)目模板中內(nèi)置支持OAuth 和 OpenID 極大的簡化了這一點(diǎn)。7.5.1 注冊外部登錄提供器使用OAuth 提供器的網(wǎng)站要求我們把網(wǎng)站注冊為一個(gè)應(yīng)用程序。這樣它們會(huì)提供給我們一個(gè)客戶端id 和一個(gè)口令。我們利用OAuth 提供器根據(jù)這些信息就可以進(jìn)行驗(yàn)證。7.5.2 配置OpenID提供器因?yàn)椴挥米?，不用填寫參?shù)，配置OAuth 提供器是非常簡單的。7.5.3 配置OAuth提供器7.5.4 外部登錄的安全性1,可信的外部登錄器2，要求SSL 登錄從外部提供器到我們網(wǎng)站的回調(diào)中包含擁有用戶信息的安全令牌，這些令牌

8、允許訪問我們的網(wǎng)站。當(dāng)令牌在Internet 中傳遞時(shí)，使用HTTPS 傳輸是非常重要的，因?yàn)檫@樣可以訪問信息攔截。為訪問AccountController 的Login Get 方法并執(zhí)行HTTPS,支持外部登錄的應(yīng)用程序應(yīng)該使用 RequireHttps 特性來使用HTTPS/ /GET:/Account/login RequireHttps AllowAnonymous pulic ActionResult Login(string returnUrl) ViewBag.ReturnUrl=returnUrl; return View(); 7.6 Web 應(yīng)用程序中安全向量因?yàn)閃eb

9、應(yīng)用程序運(yùn)行在標(biāo)準(zhǔn)的、基于文本的協(xié)議（像HTTP和HTML）之上，所以它們特別容易受到自動(dòng)攻擊的傷害。7.6.1 威脅：跨站腳本(XSS)1,威脅概述有 兩種方法可以實(shí)現(xiàn)XSS，一種方法是通過用戶將惡意腳本輸入到網(wǎng)站中，而這些網(wǎng)站又可以接收“不干凈”（unsanitized）的用戶輸入。另一種方法 是通過直接在頁面上顯示用戶的輸入。第一種情況被稱為“被動(dòng)注入”(Passive Injection)。用戶把“不干凈的”的 內(nèi)容輸入到文本框，并把這些數(shù)據(jù)保存在數(shù)據(jù)庫中，以后再重新在頁面上顯示。第二種方法稱為“主動(dòng)注入”，涉及用戶直接把“不干凈”的內(nèi)容輸入到文本框中， 這些輸入的內(nèi)容會(huì)立刻被顯示出來

10、。2，被動(dòng)注入eg: a href= 3，主動(dòng)注入eg: ?Search= 4，阻止 XSS1）對所有內(nèi)容進(jìn)行HTML 編碼頁面上每一個(gè)輸出都應(yīng)該是經(jīng)過HTML 編碼或HTML 特性編碼。2）Html.AttributeEncode 和 Url.Encode謹(jǐn)記：永遠(yuǎn)不要信任用戶能夠接觸到或者使用的一切數(shù)據(jù)，其中包括所有的表單值、URL、cookie或來自第三方源（如OpenID）的個(gè)人信息。此外網(wǎng)站所訪問的數(shù)據(jù)庫或服務(wù)可能沒有經(jīng)過編碼，所以不要輕易相信輸入應(yīng)用程序的任何數(shù)據(jù)，要盡可能的對其編碼。3）JavaScript 編碼黑客可以很隨意的利用十六進(jìn)制轉(zhuǎn)義碼隨意的向輸入內(nèi)容中插入JavaSc

11、ript 腳本代碼4）將AntiXSS 庫作為ASP.NET 的默認(rèn)編碼器AntiXSS 使用的是一個(gè)信任字符的白名單，ASP.NET 默認(rèn)實(shí)現(xiàn)一個(gè)有限的不信任字符的黑名單。AntiXSS 的重點(diǎn)是阻止應(yīng)用程序的漏洞，ASP.NET 關(guān)注的是防止HTML 頁面顯示不被破壞。在.NET 4.5及更高版本包含 MicroSoft WPL(Web Protection Library)的AntiXSS 編碼器。要使用AntiXSS 庫需要在 Web.config 的 httpRunTime 中添加以下代碼：7.6.2 威脅：跨站請求偽造跨站請求偽造（Cross-Site Request Forger

12、y,CSRF,有時(shí)也寫作XSRF 表示）要比簡單的跨站腳本攻擊更具有危險(xiǎn)性。1，威脅概述eg:用戶退出登錄方法為：/account/Logout用戶將評論中提交這樣一個(gè)標(biāo)簽img src=瀏覽器將自動(dòng)向該地址發(fā)送Get 請求。2,阻止 CSRF 攻擊ASP.NET MVC 提供了阻止 CSRF 攻擊的方法。1)令牌驗(yàn)證Html.AntiForgeryToken 輔助方法會(huì)生成一個(gè)加密值作為隱藏的輸入元素。該值會(huì)與作為會(huì)話cookie 存儲(chǔ)在用戶瀏覽器的另一個(gè)值相匹配。在提交表單時(shí)，ActionFilter 會(huì)驗(yàn)證這兩個(gè)值是否相匹配。這種方法可以阻止大部分的CSRF 攻擊。2)冪等的GET 請求

13、一個(gè)冪等操作的特點(diǎn)是執(zhí)行一次和執(zhí)行多次的效果是一樣的。一般來說，僅通過POST 修改數(shù)據(jù)庫中或網(wǎng)站上的內(nèi)容可以有效防御全部的CSRF 攻擊。3) HttpReferrer 驗(yàn)證HttpReferrer 驗(yàn)證通過使用ActionFilter 處理。這種情況下可以查看提交表單值的客戶段是否在目標(biāo)站點(diǎn)上。7.6.3 威脅：cookie 盜竊如果能夠竊取某人在一個(gè)網(wǎng)站上的身份驗(yàn)證Cookie,就可以在該網(wǎng)站上冒充他，執(zhí)行他權(quán)限內(nèi)的所有操作。這種攻擊依賴于 XSS 漏洞。攻擊者需要在目標(biāo)站點(diǎn)上注入一些腳本，才能竊取 CookieStackO 允許在評論中包含提交一定數(shù)量的HTML 標(biāo)記可以停止腳本對站點(diǎn)

14、中cookie 的訪問，需要設(shè)置一個(gè)簡單的標(biāo)志：HttpOnly可以在 web.config 文件中對所有的Cookie 設(shè)置，也可以為編寫的每個(gè)Cookie 單獨(dú)設(shè)置。7.6.4 威脅：重復(fù)提交重復(fù)提交:惡意用戶向查詢字符串或提交的表單添加超出用戶最終操作權(quán)限的值。防御重復(fù)提交最簡單的一個(gè)方法是使用Bind 特性顯式的控制需要由模型綁定器綁定的屬性。也可以用 UpdateModel 或 TryUpdateModel 方法的一個(gè)重載版本接受一個(gè)綁定列表。7.6.5 威脅：開放重定向1.威脅概述那些通過請求(如查詢字符串和表單數(shù)據(jù))指向重定向URL 的WEB 應(yīng)用程序可能被篡改，而把用戶重定向到

15、外部的惡意URL。這種篡改就被稱為開放重定向攻擊（open redirection attack）?？梢哉{(diào)用 IsLocalUrl()方法對 returnUrl 參數(shù)進(jìn)行驗(yàn)證。7.7 適當(dāng)?shù)腻e(cuò)誤報(bào)告和堆棧跟蹤customErrors 模式有3 個(gè)可選設(shè)置項(xiàng)，分別是：On:服務(wù)器開發(fā)最安全選項(xiàng)，因?yàn)樗偸请[藏錯(cuò)誤提示消息。RemoteOnly:向大多數(shù)用戶展示一般的錯(cuò)誤信息，但向擁有服務(wù)器訪問權(quán)限的用戶展示完整的錯(cuò)誤提示消息。Off:最容易受到攻擊的選項(xiàng)，它向每一個(gè)網(wǎng)站的訪問者展示詳細(xì)的錯(cuò)誤處理。7.7.1 使用配置轉(zhuǎn)換使用RemoteOnly 模式替換掉customError 模式。7.7.2 在生