【正文】 子系統的操作采用身份驗證和授權管理。 所謂身份驗證是指確定請求用戶身份的行為。通常，用戶通過登陸框向服務器提交憑證以便進行身份驗證。一旦用戶憑證通過驗證，就必須確定此用戶是否可以訪問特定的資源，這個過程稱為授權。 11． 1 安全分析 （一）身份驗證 身份驗證是用戶提交用戶憑證，通過服務器端驗證的過程。如果提交憑證有效，那么可視為通過身份驗證。 NET 提供了 4 種驗證方式：Windows 驗證、 Passport 驗證、 None驗證和 Forms 驗證。 Windows 驗證 Windows 驗證適合于企業(yè)內部 Intra 站點使用，該驗證方式基于 Windows 用戶帳戶和用戶組，可有效控制用戶對未授權信息的訪問。例如，企業(yè) Intra 為每個雇員分配了 Windows 用戶帳 號，這些用戶帳號可能包含在不同的用戶組中。如果需要實現只允許經理組中的用戶訪問雇員簡歷和任務完成表，那么可以使用基于 Windows 的驗證來防止其他用戶組的雇員訪問。 Windows 驗證方式依靠 Microsoft Inter 信息服務（ IIS）來執(zhí)行所需的用戶身份驗證。 IIS提供了多種驗證機制來驗證用戶身份，包括匿名身份驗證、集成 Windows身份驗證、基于身份驗證和 Windows域服務器的摘要式身份驗證等。 Passport 驗證 42 Passport 驗證是由微軟公司 1999 年公布的 Passport認證服 務發(fā)展而來的。 Passport 提供了一個可以在多個網站共享的驗證機制，可以讓用戶根據自身的電子郵件地址和密碼，在任何支持 Passport驗證服務的 WEB 站點上訪問資源，并且在注銷離開時，所有 Passport相關的信息都會清除。因此， Passport 驗證方式適合于跨站之間的應用。啟用 Passport 驗證的 WEB 站點依靠 Passport 中央服務器來驗證用戶，而不是主持和維護他們自己的專用身份驗證系統。 Passport中央服務器并不授權或拒絕特定用戶訪問單個啟用 Passport 的站點，而是由網站來控制用戶的權限。 Passport 驗證是一個集中式解決方案，它消除了應用程序中的憑證管理問題，并且比較安全，因為其加密技術相對而言比較先進。 None 驗證 在 None 驗證方式下， 將不對請求進行任何附加身份驗證。 None 驗證方式適合兩種情況。一種是 提供的身份驗證方式均不滿足應用程序對身份驗證的需要，那么可以使用自定義身份驗證方式，并且實現自定義的身份驗證機制。另一種是不希望對用戶進行身份驗證，那么這種方式將非常有用。 Forms 驗證 Forms 驗證是多數 WEB 應用程序使用的身份驗證方式。 Forms 驗證本身并不能進行驗證，只是使用自定義的用戶界面收集用戶信息，例如，用戶名和密碼等，最終通過自定義代碼實現驗證。 在因特網中， Forms 驗證是使用最廣泛的身份驗證方式，這主要 43 是因為該驗證方式具有很強的靈活性和適應性，能夠滿足多種應用需要。通常情況下，用戶利用 Forms 驗證訪問受保護資源，包括以下 4個步驟：第一步，用戶請求受保護的頁面；第二步， HTTP 模塊調用Forms 驗證服務器截取來自用戶的請求，并檢查其中是否包含用戶憑據；第三步，如果沒有發(fā)現任何用戶憑據，將自動轉向用戶登陸頁面；第四步，當用戶通過驗 證后，應用程序將根據用戶擁有的權限轉到相應的功能模塊中。 Forms 驗證包括：無 Cookie 會話功能和使用 Cookie 會話功能 （ 1）無 Cookie 會話功能 無 Cookie 會話功能的優(yōu)點：第一，提高了 Forms 驗證方式的適應性。第二，在一定意義上，克服了基于 Cookie 的 Forms 驗證在安全性方面的缺點。 無 Cookie 會話功能的缺點：第一，在某些情況下，無 Cookie 會話將帶來安全性問題。當攻擊者獲得對特定用戶的會話狀態(tài)的訪問時將發(fā)生會話劫持。這個過程的實質是，攻擊者竊取有效的會話 ID，并且使用它入侵系統 和窺探數據。獲取有效會話 ID 的一種常見方式是竊取有效的 Cookie, 其中包括了有效會話 ID。鑒于此，如果認為無 Cookie 會保護了應用程序的安全，那將是完全的錯誤的。因為對于無 Cookie 會話，會話 ID 是顯而易見的，它將直接顯示在 URL 地址欄中。竊取會話 ID 是一種必須受到禁止的操作。這種操作是否有害，取決于會話狀態(tài)中實際存儲的內容。竊取會話 ID 本身并不會執(zhí)行超出代碼控制范圍的操作。但是，它可能向未經授權的用戶泄露私有數 44 據，并且使一些別有用心的人能夠執(zhí)行未經授權的操作。第二，使用無 Cookie 會話會引起與連 接有關的問題。產生這個問題的主要原因是在 URL 地址中自動添加了會話 ID。 （ 2） Cookie 會話功能 Cookie 是一小段文本信息，伴隨著用戶請求和頁面在 Web 服務器和瀏覽器之間傳遞。用戶每次訪問站點時， Web 應用程序都可以讀取 Cookie 包含的信息。 Cookie 是與 Web 站點而不是與具體頁面關聯的，所以無論用戶請求瀏覽站點中的哪個頁面，瀏覽器和服務器都將交換 Cookie 信息。用戶訪問其他站點時，每個站點都可能會向用戶瀏覽器發(fā)送一個 Cookie，而瀏覽器會將所有這些 Cookie 分別保存。 Cookie最根本的用途是 Cookie 能夠幫助 Web 站點保存有關訪問者的信息。更概括地說， Cookie 是一種保持 Web 應用程序連續(xù)性（即執(zhí)行 “ 狀態(tài)管理 ” ）的方法。瀏覽器和 Web 服務器除了在短暫的實際信息交換階段以外總是斷開的，而用戶向 Web 服務器發(fā)送的每個請求都是單獨處理的，與其他所有請求無關。然而在大多數情況下，都有必要讓 Web 服務器在您請求某個頁面時對您進行識別。因此 Cookie 的作用就類似于名片，它提供了相關的標識信息，可以幫助應用程序確定如何繼續(xù)執(zhí)行。 IBMS 系 統采用 Forms 驗證方式。 Forms 驗證能夠通過獲取用戶名和密碼，實現用戶身份驗證。在驗證過程中，所有的用戶信息都保存在外部數據源中，如果用戶提交 45 的憑證與數據源中的數據匹配，則可認定為通過驗證。接著， Forms驗證將給用戶提供一個用于驗證的 cookies，或者包含對話的 ID 的URL 地址，當用戶訪問受保護頁時，則不必關心再次提交用戶名和密碼，而能夠正常訪問頁面內容。 Forms 驗證實現方式是通過在客戶端存入 cookies，并使用 MD5不可逆算法加密；在傳輸過程中使用安全套節(jié)字層（ SSL）連接來傳輸身份驗證 cookies，并驗證信息在傳輸過程中是否被更改；同時在服務器端進一步驗證身份的合法性。 11． 2 用戶授權 用戶授權是指確定經身份驗證的用戶是否可以請求資源的過程。NET 提供了 3 種授權方式：文件授權、 URL 授權、基于角色的授權。 文件授權是利用 FileAuthorizationModule 類來實現的。這種方式類似于 Unix 下的文件權限檢查，不過它更加嚴格和完備。當用戶請求某個頁面時， FileAuthorizationModule 負責對執(zhí)行處理程序文件的訪問控制列表（ ACL）進行檢查，以確定用戶是否應該擁有權限訪問受保護的文件。這種授權方式主要通過系統管理員對文件權限的設定來實現。 URL 授權是利用 UrlAuthorizationModule 類來實現的 , AuthorizationModule 實現肯定和否定的授權斷言。即可以使用該類有選擇性地允許或拒絕訪問用戶、角色和謂詞對 URL 命名空間的任意部分的訪問。這種授權方式對于某個用戶的頁面請求，并不是從文件權限出發(fā)，而是根據系統的配置情況，決定用戶的請求是否是經過授 46 權的。 基于角色的訪問控制的基本思想就是把對用戶的授權分成兩部分，用角色來充當用戶行使權限的 中介。這樣，原本在用戶和權限之間的分配關系就變成了用戶與角色之間，以及角色與權限之間兩個多對多的分配關系： ● 用戶 —— 角色分配：也稱用戶 — 角色授權。用戶與角色之間是多對多的關系，即一個用戶可以被分配給多個角色，多個用戶也可以分配給同一個角色。 ● 權限 —— 角色分配：也成角色 — 特權授權。角色與權限之間同樣也是多對多的關系，即一個權限可以與多個角色相關，一個角色也可以包含多重權限。 基于角色的訪問控制技術實現了用戶與訪問權限的邏輯分離，將對訪問者的控制轉換為對角色的控制，從而使授權管理更為方便實用、效率更高。同時 ，角色與角色之間可以繼承權限，使各個角色的權限劃分更為清晰、明確，降低了權限管理的復雜性，提高了管理效率。 系統把 URL 授權和基于角色的授權二者結合使用，即首先為用戶設置角色，然后再為角色進行 URL 授權，并限制特定用戶組對某頁面或者某系統的訪問權限。 11． 3 安全操作 驗證碼機制： 所謂驗證碼，就是將一串隨機產生的數字或符號，生成一幅圖片， 圖片里加上一些干擾象素防止 OCR（ 提取圖片中文 47 字的工具和方法 ） ，由用戶肉眼識別其中的驗證碼信息，輸入表單提交 服務器 驗證，驗證成功后才能使用某項功能。 它的作用是防止 自動注冊 程序識別此圖片中的字符。防止攻擊者編寫程序，自動注冊，重復登錄暴力破解密碼。 登陸密碼錯誤次數限制：設置 登陸密碼試探次數限制 ，多次密碼錯誤系統自動關閉，登陸名被鎖定，操作被記錄。防止 自動注冊程序或 攻擊者編寫程序重復登錄暴力破解密碼。 操作日志機制： 操作日志是用來記錄某管理員或者某 系統操作員何時進 入系統或者何時退出系統 ,并且記錄他們進入系統后的一些操作情況。 有 兩類 日志：登陸日志、操作日志。登錄日志記錄了所有用戶的登錄本系統的動作 和退出系統的時間 ，操作日志記錄了所有令系統數據庫產生數據變化的操作，如數據更新、數 據刪除等。 11． 4 具體實施 （一） 建立數據庫， 劃分 應用項目 的 不同安全級別的 子系統。 在應用項目的數據庫中， 建立 用戶數據表 ，記錄用戶帳號和密碼，其密碼采用 MD5 加密算法存儲。建立角色關系表，即記錄用戶和角色的關系。建立角色信息表，記錄角色的權限。建立操作日志和登陸日志表。 劃分系統各個子系統模塊，明確操作員的權限。 （二）實現介紹 任何用戶進入系統前，必須登陸驗證（進入系統首先進入登陸界面），只有通過驗證的登陸用戶才能訪問所擁有權限的功能模塊。 48 用戶通過登陸框向服務器提交憑證以便進行身份驗證。在向服務器 提交前首先在客戶端通過驗證碼驗證， 輸入表單提交 服務器 驗證，防止攻擊者編寫程序，自動注冊，重復登錄暴力破解密碼 。 在驗證過程中，所有的用戶信息都保存在服務器端數據源中，密碼使用 MD5 不可逆算法加密，如果用戶提交的憑證與數據源中的數據匹配，則在客戶端存入 cookies，并 創(chuàng)建認證票據 。 認證票據（用戶名和密碼）是沒有作為 cookie 的一部分來存儲的，而且也不可以，因為用戶可以修改他們的 cookie。事實上是用機器碼 （ machine key）來加密票據的。 如果用戶沒有登陸或者驗證沒有通過則 認證票據是無效的， 當訪問 系統時 從而強制轉向到登錄頁面 。 如果你登錄成功，并且你的角色對這個目錄有訪問權限，你就重新回到這個目錄下。 如果有用戶（或入侵者）企圖進入機密目錄， 由于使用了 登陸密碼錯誤次數限制， 用戶登錄的次數，超過一定次數就不讓用戶登錄，并且顯示系統拒絕了你的登錄請求！ 。 在驗證的同時系統將自動記錄用戶登陸成功和失敗的日志。 在傳輸過程中使用安全套節(jié)字層（ SSL）連接來傳輸身份驗證cookies，并驗證信息在傳輸過程中是否被更改。 由于系統使用了 基于角色的訪問控制 體系，不同的用戶具有不同的操作權限。超級管理員可以擁有最 大的系統管理權限，擁有增加刪除用戶和角色的權限。而個子系統的管理員只能管理個子系統的功能不能操作其他子系統。 由于采用了操作日志機制： 記錄某管理員或者某 系統操作員何時 49 進 入系統或者何時退出系統 ,并且記錄他們進入系統后的一些操作情況。 管理員可以明確知道 某管理員或者某 系統操作員在系統中的操作情況。