【文章內容簡介】 交的時候通過查找到CheckBox控件，判斷其是否被選中從而更改用戶權限。界面如下圖所示 用戶管理界面 教材管理模塊主要審核教師提交的教材，并生成匯總表格。審核類似與用戶審核，通過修改表中的審核字段信息，將審核信息通知用戶。然后在經過審核之后可以生成匯總表格界面如下圖所示： 教材匯總界面當點擊教材庫的時候，管理員可以根據實際情況進行教材庫更新操作。 多媒體管理模塊主要審核教師的多媒體申請，并生成匯總表格。審核類似與用戶審核，通過修改表中的審核字段信息，將審核信息通知用戶。審核界面如圖所示： 多媒體申請審核界面當點擊匯總的時候進入匯總界面，如下圖所示： 多媒體申請匯總界面這里解決的一個問題是在表格中會出現重復列，這里我設計了一個函數，來合并相同的行，避免重復顯示數據。 期中檢查匯總模塊通過查詢VoteInfo表得到老師的教師得分并按照平均分給出名次，當平均分相同時按照A的數目來確定名次。界面如下圖所示： 期中檢查匯總模塊5 系統(tǒng)的性能優(yōu)化建立在B/S模式上的教務管理系統(tǒng)，需要增加其安全性能，才能更好的滿足教務管理的需要。 系統(tǒng)安全優(yōu)化系統(tǒng)安全性主要是針對SQL注入式攻擊[8]的防范，下面將對SQL注入式攻擊及防范、身份驗證和異常處理做具體說明。 什么是SQL注入式攻擊所謂SQL注入式攻擊，就是攻擊者把SQL命令插入到Web表單的輸入域或頁面請求的查詢字符串，欺騙服務器執(zhí)行惡意的SQL命令。在某些表單中，用戶輸入的內容直接用來構造（或者影響）動態(tài)SQL命令，或作為存儲過程的輸入參數，這類表單特別容易受到SQL注入式攻擊。常見的SQL注入式攻擊過程類如：（1） Web應用有一個登錄頁面，這個登錄頁面控制著用戶是否有權訪問應用，它要求用戶輸入一個名稱和密碼。（2）登錄頁面中輸入的內容將直接用來構造動態(tài)的SQL命令，或者直接用作存儲過程的參數。：例如用戶的查詢語句是select * from tbUser wher name =’”amp。useramp?！薄?and password=’”amp。pwdamp?！薄?（3）攻擊者在用戶名和密碼輸入框中輸入1‘or’1‘=’1之類的內容。（4）用戶輸入的內容提交給服務器之后，但由于攻擊者輸入的內容非常特殊，所以最后得到的SQL命令變成：select *from admin where tbUser=1‘or’1‘=’1 and password=’”amp。pwdamp?！薄?）服務器執(zhí)行查詢或存儲過程，將用戶輸入的身份信息和服務器中保存的身份信息進行對比。（6）由于SQL命令實際上已被注入式攻擊修改，已經不能真正驗證用戶身份，所以系統(tǒng)會錯誤地授權給攻擊者。如果攻擊者知道應用會將表單中輸入的內容直接用于驗證身份的查詢，他就會嘗試輸入某些特殊的SQL字符串篡改查詢改變其原來的功能，欺騙系統(tǒng)授予訪問權限。系統(tǒng)環(huán)境不同，攻擊者可能造成的損害也不同，這主要由應用訪問數據庫的安全權限決定。如果用戶的帳戶具有管理員或其他比較高級的權限，攻擊者就可能對數據庫的表執(zhí)行各種他想要做的操作，包括添加、刪除或更新數據，甚至可能直接刪除表。 防范措施，只要在利用表單輸入的內容構造SQL命令之前，把所有輸入內容過濾一番就可以了。過濾輸入內容可以按多種方式進行。（1）對于動態(tài)構造SQL查詢的場合，可以使用下面的技術：　　　第一，替換單引號，即把所有單獨出現的單引號改成兩個單引號，防止攻擊者修改SQL命令的含義。再來看前面的例子，“SELECT * from Users WHERE login = 39。39。39。 or 39。39。139。39。=39。39。139。 AND password = 39。39。39。 or 39。39。139。39。=39。39。139?！憋@然會得到與“SELECT * from Users WHERE login = 39。39。 or 39。139。=39。139。 AND password = 39。39。 or 39。139。=39。139。”不同的結果?！　〉诙瑒h除用戶輸入內容中的所有連字符，防止攻擊者構造出類如“SELECT * from Users WHERE login = 39。mas39。 —— AND password =39。39?！敝惖牟樵儯驗檫@類查詢的后半部分已經被注釋掉，不再有效，攻擊者只要知道一個合法的用戶登錄名稱，根本不需要知道用戶的密碼就可以順利獲得訪問權限?！　〉谌簩τ谟脕韴?zhí)行查詢的數據庫帳戶，限制其權限。用不同的用戶帳戶執(zhí)行查詢、插入、更新、刪除操作。由于隔離了不同帳戶可執(zhí)行的操作，因而也就防止了原本用于執(zhí)行SELECT命令的地方卻被用于執(zhí)行INSERT、UPDATE或DELETE命令?！　。?）用存儲過程來執(zhí)行所有的查詢。SQL參數的傳遞方式將防止攻擊者利用單引號和連字符實施攻擊。此外，它還使得數據庫權限可以限制到只允許特定的存儲過程執(zhí)行，所有的用戶輸入必須遵從被調用的存儲過程的安全上下文，這樣就很難再發(fā)生注入式攻擊了。　 （3）限制表單或查詢字符串輸入的長度。如果用戶的登錄名字最多只有10個字符，那么不要認可表單中輸入的10個以上的字符，這將大大增加攻擊者在SQL命令中插入有害代碼的難度。（4）檢查用戶輸入的合法性，確信輸入的內容只包含合法的數據。數據檢查應當在客戶端和服務器端都執(zhí)行——之所以要執(zhí)行服務器端驗證，是為了彌補客戶端驗證機制脆弱的安全性?！　≡诳蛻舳?，攻擊者完全有可能獲得網頁的源代碼，修改驗證合法性的腳本（或者直接刪除腳本），然后將非法內容通過修改后的表單提交給服務器。因此，要保證驗證操作確實已經執(zhí)行，唯一的辦法就是在服務器端也執(zhí)行驗證。你可以使用許多內建的驗證對象，例如RegularExpressionValidator，它們能夠自動生成驗證用的客戶端腳本，當然你也可以插入服務器端的方法調用。如果找不到現成的驗證對象，你可以通過CustomValidator自己創(chuàng)建一個?！? （5）將用戶登錄名稱、密碼等數據加密保存。加密用戶輸入的數據，然后再將它與數據庫中保存的數據比較，這相當于對用戶輸入的數據進行了“消毒”處理，用戶輸入的數據不再對數據庫有任何特殊的意義，從而也就防止了攻擊者注入SQL命令。，非常適合于對輸入數據進行消毒處理。（6）檢查提取數據的查詢所返回的記錄數量。如果程序只要求返回一個記錄，但實際返回的記錄卻超過一行，那就當作出錯處理。本文所提及的教務管理系統(tǒng)采用的是用存儲過程進行查詢。比如在登錄模塊中：string uname= 。string upwd= 。string strSql=select * from UserInfo where UserName=@uname and Pwd=@upwd。 SqlConnection con = new SqlConnection()。=[DSN]。()。SqlCommand = new SqlCommand(strSql,con)。(newSqlParameter(@uname,20))。 [@uname].Value =uname。(newSqlParameter(@upwd,20))。 [@upwd].Value =upwd。SqlDataReader dr = ()。 身份驗證基于窗體的身份驗證是 身份驗證服務，它使應用程序能夠提供它們自己的登錄 UI 和進行它們自己的憑據驗證。 驗證用戶的身份，將未授權的用戶重定向到登錄頁并執(zhí)行所有必要的 Cookie 管理。這種身份驗證是許多 Web 站點使用的流行方法。應用程序必須被配置成使用基于窗體的身份驗證，將 authentication 設置為 Forms 并且拒絕匿名用戶訪問。下面的示例說明如何在所需應用程序的 文件中完成此配置：configuration authentication mode=Forms/ authorization deny users=? / /authorization //configuration管理員使用基于窗體的身份驗證來配置要使用的 Cookie 名稱、保護類型、用于登錄頁的 URL、Cookie 生效的時間長度以及用于已發(fā)布 Cookie 的路徑。下表顯示了 Forms 元素（它是下面的示例中顯示的 authentication 元素的子元素）的有效屬性：authentication mode=Forms forms name=.ASPXCOOKIEDEMOloginUrl= protection=all timeout=30 path=/ /forms/authentication配置了應用程序后，需要提供一個登錄頁。下面的示例顯示了一個簡單的登錄頁。未授權的請求被重定向到登錄頁 ()，此頁顯示一個簡單的窗體，提示用戶輸入用戶名和密碼。這將用戶重定向回當初請求的 URL。不想執(zhí)行重定向的應用程序可以或者調用 來檢索 Cookie 值，或者調用 將正確加密的 Cookie 附加到輸出的響應中。對于提供嵌入在包含頁中的登錄 UI 的應用程序，或者想要更多地控制用戶被重定向到的位置的應用程序而言，這些方法很有用。身份驗證 Cookie 既可以臨時又可以永久（“持久”）。臨時 Cookie 只在當前瀏覽器會話期間保持。當瀏覽器關閉時，臨時 Cookie 隨即丟失。永久 Cookie 則被瀏覽器保存，并在瀏覽器會話間回發(fā)，直到被用戶顯式刪除。窗體身份驗證使用的身份驗證 Cookie 由 類的線性版本組成。信息包括用戶名（但沒有密碼）、使用的窗體身份驗證版本、發(fā)出 Cookie 的日期以及可選的應用程序特定數據的字段。通過使用 方法，應用程序代碼可以撤消或移除身份驗證 Cookie。這將移除身份驗證 Cookie，不論它是臨時的還是永久的。 異常處理根據具體的情況，可能需要以不同的方式處理應用程序錯誤。例如，開發(fā)時可能需要查看 提供的詳細錯誤頁，以幫助確定和修復問題。然而，一旦應用程序應用于生產環(huán)境，您可能不想向客戶所在的客戶端顯示詳細的錯誤。可以使用 指定是向本地客戶端、遠程客戶端還是這兩者顯示錯誤。默認情況下，僅向本地客戶端（即服務器所在的同一計算機上的客戶端）顯示錯誤。也可以指定自定義錯誤頁，以在發(fā)生錯誤時將客戶端重定向到該頁。 在 文件中為某個應用程序啟用自定義錯誤。例如： configuration customErrors defaultRedirect== mode=remoteonly / //configuration此配置使本地客戶端能夠看到默認的 詳細錯誤頁，但將遠程客戶端重定向到自定義頁 。該頁也可以是 .aspx 頁。 以 QueryString 參數的形式將發(fā)生錯誤的頁的路徑傳遞到該錯誤頁。注意：如果執(zhí)行錯誤頁時產生錯誤，則將給遠程客戶端發(fā)回空白頁。 除了將所有的錯誤重定向到一個公共頁外，還可以將特定的錯誤頁分配給特定的錯誤狀態(tài)代碼。customerrors 配置節(jié)支持內部 error 標記，該標記使 HTTP 狀態(tài)代碼與自定義錯誤頁關聯。例如： configuration customErrors mode=RemoteOnlydefaultRedirect=/ error statusCode=500 redirect=/error// error statusCode=404 redirect=/error// error statusCode=403 redirect=/error// /customErrors //configuration 本論文提及的系統(tǒng)采用自定義錯誤，如果在客戶端產生錯誤。界面如下圖所示： 錯誤界面 系統(tǒng)測試作為軟件開發(fā)的重要環(huán)節(jié), 軟件測試越來越受到人們的重視. 隨著軟件開發(fā)規(guī)模的增大、復雜程度的增加, 以尋找軟件中的錯誤為目的的測試工作就顯得更加困難. 為了盡可能多地找出程序中的錯誤,生產出高質量的軟件產品, . 或者說, 軟件測試[9]是根據軟件開發(fā)各階段的規(guī)格說明和程序的內部結構而精心設計一批測試用例(即輸入數據及其預期的輸出結果) , 并利用這些測試用例去運行程序, 以發(fā)現錯誤的過程. 軟件測試是軟件質量保證的重要手段. 測試按照典型的軟件工程理論分為單元測試、集成測試、系統(tǒng)測試等, 此外從其他角度還可以分成白盒測試、黑盒測試. 軟件測試工作分布于整個開發(fā)周期中, 測試從單元測試開始, 以系統(tǒng)測試結束.本系統(tǒng)采用的是WAST測試工具，模擬多用戶登錄來查看服務器的壓力。Report name: 2007526 22:12:59Run on: 2007526 22:12:59Run length: 00:00:30Web Application Stress Tool Version:Number of test clients: 1Number of hits: 1817Requests per Second: Socket StatisticsSocket Connects: 1818Total Bytes Sent (in KB): Bytes Sent Rate (in KB/s): Total Bytes Recv (in KB): Bytes Recv Rate (in KB/s): Socket Er