ASP.Net MVC 5 高級編程 第7章 成員資格、受權和安全性

第7章 成員資格、受權和安全性

7.1 安全性

ASP.NET MVC 提供了許多內置的保護機制（默認利用 HTML 輔助方法和Razor 語法進行 HTML編碼以及請求驗證等功能特性，以及經過基架構建的控制器白名單表單元素來防止重複提交攻擊）

永遠不要相信用戶提交的任何數據。

實際的例子

• 每次渲染用戶提交的數據的時候對其進行編碼。
• 考慮好網站哪些部分容許用戶匿名訪問，哪些部分須要認證訪問。
• 不要試圖本身淨化用戶的HTML 輸入，不然就會失敗。
• 在不須要經過客戶端腳本訪問cookie時，使用HTTP-only cookie
• 請記住外部輸入不僅是顯式的表單域。
• 建議使用AntiXSS 編碼器。

黑客、解密高手、垃圾郵件發送者、病毒、惡意軟件——它們都想進入計算讀查看裏面的數據。在閱讀本段內容時，咱們的電子郵箱極可能已經轉發了不少封電子郵件。咱們的端口遭到了掃描，而一個自動化的蠕蟲病毒頗有可能正在嘗試經過多種操做系統漏洞找到進入PC的途徑。因爲這些攻擊都是自動的，所以它們在不斷地探索，尋找一個開放的系統。

應用程序的構建基於這樣一種假設，即只有特定用戶才能執行某些操做，而其它用戶則不能執行這些操做。

7.2 使用Authorize 特性登陸

        保護應用程序安全的第一步，同時也是最簡單的一步，就是要求用戶只有登陸系統才能訪問應用程序的特定部分。         Authorize Attribute 是ASP.NET MVC 自帶的默認受權過濾器，可用來限制用戶對操做方法的訪問。    

Tips:身份驗證和受權

身份驗證是指經過某種形式的登陸機制(包括用戶名/密碼、OpenID、OAuth 等說明自已身份的項)來覈實用戶身份。

受權驗證是用來覈實登陸站點的用戶是否在他們的權限內執行操做。這一般使用一些基於聲明的系統來實現。

Authorize 特性不帶任何參數，只要求用戶以某種角色登陸網站。它禁止匿名訪問。

7.2.1 保護控制器操做

實現安全性的一個好方法是，始終使安全性檢查儘量的貼近要保護的對象。可能有其它更高層的檢查，但始終都要確保實際資源的安全。

7.2.2 Authorize 特性在表單身份驗證和AccountController 控制器中的用法

基本驗證信息

        IPrincipal user=httpContext.User;
        if(!user.Identity.IsAuthenticated)
        {return false;}

        if(_usersSplit.Length>0&&!_usersSplit.Contains(user.Identity.Name,StringComparer.OrdinalIgnoreCase))
        {return false;}

        if(_rolesSplit.Length>0&&!_rolesSplit.Any(user.IsInRole))
        {return false;}
        return true;

    

若是用戶身份驗證失敗，就會返回一個HttpUnauthorizedResult 操做結果，它產生了一個 HTTP 401(未受權)的狀態碼。

7.2.3 Windows Authentication

爲使用Intranet 驗證選項，咱們須要啓用Windows 驗證，禁用 Anonymous 驗證。

使用全局受權過濾器保障整個應用程序安全

MVC 4中新添加了AllowAnonymous 特性。若是把AuthorizeAttribute 註冊爲全局過濾器，而且有些方法須要外部訪問，那麼這些方法只須要使用4中新添加了AllowAnonymous 特性裝飾便可。AllowAnonymous 僅對標準的AuthorizeAttribute 有效；對於自定義的受權過濾器，則不必定起做用。全局受權僅對MVC 是全局的

7.3 要求角色成員使用Authorize 特性

Authorize 特性容許指定角色和用戶。

Roles 參數能夠有多個角色，咱們用‘，’分割：

7.4 擴展用戶身份

7.4.1 存儲用戶額外的信息

Code First 模式下只須要在用戶類中添加屬性。

7.5 經過OAuth 和 OpenID 的外部登陸

OAuth 和 OpenID 是開放的標準。這些協議容許用戶使用他們已有的帳戶登陸咱們的網站。

配置網站以支持OAuth 和 OpenID是很是難以實現的，協議複雜，頂級提供器對這兩種協議的實現方式不同。MVC 經過在使用Individual User Accounts 身份驗證的項目模板中內置支持OAuth 和 OpenID 極大的簡化了這一點。

7.5.1 註冊外部登陸提供器

使用OAuth 提供器的網站要求咱們把網站註冊爲一個應用程序。這樣它們會提供給咱們一個客戶端id 和一個口令。咱們利用OAuth 提供器根據這些信息就能夠進行驗證。

7.5.2 配置OpenID提供器

由於不用註冊，不用填寫參數，配置OAuth 提供器是很是簡單的。

7.5.3 配置OAuth提供器

7.5.4 外部登陸的安全性

1,可信的外部登陸器

2，要求SSL 登陸

從外部提供器到咱們網站的回調中包含擁有用戶信息的安全令牌，這些令牌容許訪問咱們的網站。當令牌在Internet 中傳遞時，使用HTTPS 傳輸是很是重要的，由於這樣能夠訪問信息攔截。

爲訪問AccountController 的Login Get 方法並執行HTTPS,支持外部登陸的應用程序應該使用 RequireHttps 特性來使用HTTPS

 

        //
        //GET:/Account/login

        [RequireHttps]
        [AllowAnonymous]
        pulic ActionResult Login(string returnUrl)
        {
        ViewBag.ReturnUrl=returnUrl;
        return View();
        }

    

7.6 Web 應用程序中安全向量

由於Web 應用程序運行在標準的、基於文本的協議（像HTTP和HTML）之上，因此它們特別容易受到自動攻擊的傷害。

7.6.1 威脅：跨站腳本(XSS)

1,威脅概述

有兩種方法能夠實現XSS，一種方法是經過用戶將惡意腳本輸入到網站中，而這些網站又能夠接收「不乾淨」（unsanitized）的用戶輸入。另外一種方法是經過直接在頁面上顯示用戶的輸入。第一種狀況被稱爲「被動注入」(Passive Injection)。用戶把「不乾淨的」的        內容輸入到文本框，並把這些數據保存在數據庫中，之後再從新在頁面上顯示。第二種方法稱爲「主動注入」，涉及用戶直接把「不乾淨」的內容輸入到文本框中，這些輸入的內容會馬上被顯示出來。

2，被動注入

eg:

        "></a><script src="hackScript.js"></script><a href="

    

3，主動注入

eg:

      http://www.meishizouqi.com?Search=<form action=""><input type="text" name="name" /><input type="password" name="password" /><input type="submit" value="登陸" />

    

4，阻止 XSS

1）對全部內容進行HTML 編碼

頁面上每個輸出都應該是通過HTML 編碼或HTML 特性編碼。

2）Html.AttributeEncode 和 Url.Encode

謹記：永遠不要信任用戶可以接觸到或者使用的一切數據，其中包括全部的表單值、URL、cookie或來自第三方源（如OpenID）的我的信息。此外網站所訪問的數據庫或服務可能沒有通過編碼，因此不要輕易相信輸入應用程序的任何數據，要儘量的對其編碼。

3）JavaScript 編碼

黑客能夠很隨意的利用十六進制轉義碼隨意的向輸入內容中插入JavaScript 腳本代碼

4）將AntiXSS 庫做爲ASP.NET 的默認編碼器

• AntiXSS 使用的是一個信任字符的白名單，ASP.NET 默認實現一個有限的不信任字符的黑名單。
• AntiXSS 的重點是阻止應用程序的漏洞，ASP.NET 關注的是防止HTML 頁面顯示不被破壞。

在.NET 4.5及更高版本包含 MicroSoft WPL(Web Protection Library)的AntiXSS 編碼器。要使用AntiXSS 庫須要在 Web.config 的 httpRunTime 中添加如下代碼：< httpRuntime ... encoderType="System.Web.Security.AntiXss.AntiXssEncoder,System.Web,Version=4.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d59a3a"/>

7.6.2 威脅：跨站請求僞造

跨站請求僞造（Cross-Site Request Forgery,CSRF,有時也寫做XSRF 表示）要比簡單的跨站腳本攻擊更具備危險性。

1，威脅概述

eg:

用戶退出登陸方法爲：/account/Logout

用戶將評論中提交這樣一個標籤<img src="/account/Logout">

瀏覽器將自動向該地址發送Get 請求。

2,阻止 CSRF 攻擊

ASP.NET MVC 提供了阻止 CSRF 攻擊的方法。

1)令牌驗證

Html.AntiForgeryToken 輔助方法會生成一個加密值做爲隱藏的輸入元素。

該值會與做爲會話cookie 存儲在用戶瀏覽器的另外一個值相匹配。在提交表單時，ActionFilter 會驗證這兩個值是否相匹配。這種方法能夠阻止大部分的CSRF 攻擊。

2)冪等的GET 請求

一個冪等操做的特色是執行一次和執行屢次的效果是同樣的。

通常來講，僅經過POST 修改數據庫中或網站上的內容能夠有效防護所有的CSRF 攻擊。

3) HttpReferrer 驗證

HttpReferrer 驗證經過使用ActionFilter 處理。這種狀況下能夠查看提交表單值的客戶段是否在目標站點上。

7.6.3 威脅：cookie 盜竊

若是可以竊取某人在一個網站上的身份驗證Cookie,就能夠在該網站上冒充他，執行他權限內的全部操做。這種攻擊依賴於 XSS 漏洞。攻擊者須要在目標站點上注入一些腳本，才能竊取 Cookie

StackOverflow.com 容許在評論中包含提交必定數量的HTML 標記

能夠中止腳本對站點中cookie 的訪問，須要設置一個簡單的標誌：HttpOnly

能夠在 web.config 文件中對全部的Cookie 設置，也能夠爲編寫的每一個Cookie 單獨設置。

7.6.4 威脅：重複提交

重複提交:惡意用戶向查詢字符串或提交的表單添加超出用戶最終操做權限的值。

防護重複提交最簡單的一個方法是使用[Bind] 特性顯式的控制須要由模型綁定器綁定的屬性。也能夠用 UpdateModel 或 TryUpdateModel 方法的一個重載版本接受一個綁定列表。

7.6.5 威脅：開放重定向

1.威脅概述

那些經過請求(如查詢字符串和表單數據)指向重定向URL 的WEB 應用程序可能被篡改，而把用戶重定向到外部的惡意URL。這種篡改就被稱爲開放重定向攻擊（open redirection attack）。

能夠調用 IsLocalUrl()方法對 returnUrl 參數進行驗證。

7.7 適當的錯誤報告和堆棧跟蹤

customErrors 模式有3 個可選設置項，分別是：

• On:服務器開發最安全選項，由於它老是隱藏錯誤提示消息。
• RemoteOnly:向大多數用戶展現通常的錯誤信息，但向擁有服務器訪問權限的用戶展現完整的錯誤提示消息。
• Off:最容易受到攻擊的選項，它向每個網站的訪問者展現詳細的錯誤處理。

7.7.1 使用配置轉換

使用RemoteOnly 模式替換掉customError 模式。

7.7.2 在生產環境下使用Retail 部署配置

部署配置的是服務器環境下一的 machine.config 文件中的一個簡單開關，用來標識ASP.Net 是否在Retail 部署模式下運行。

將deployment/retail 設置爲true ,將影響如下幾項設置

• 設置爲On,就是最安全的設置
• 禁用跟蹤輸出
• 禁用調試

這些設置能夠覆蓋Web.config 文件中全部應用程序級別的設置

7.9 小結

Web 應用程序中安全問題老是能夠歸結爲開發人員一方的簡單問題：不當的假設、錯誤信息及缺少訓練等。