高校數字化校園應用系統(tǒng)安全測試研究

李鳳強

摘要：近幾年，高校數字化校園飛速發(fā)展，同時也面臨巨大的風險與挑戰(zhàn)。數據泄露、網絡攻擊等事件層出不窮，如何保證高校數字化校園應用系統(tǒng)的安全是我們亟待解決的問題。該文從安全測試人手，針對校園信息系統(tǒng)的特點主要從數據安全保護和網絡攻擊的防御技術方面進行了探討，為保證數字化校園的健康發(fā)展提供參考。

關鍵詞：數字化校園；安全測試；數據安全；web掃描器；web攻擊

中圖分類號：TP393 文獻標識碼：A 文章編號：1009-3044（2018）06-0022-03

1引言

數字化校園是以數字化信息和網絡為基礎，在計算機和網絡技術上建立起來的對教學、科研、管理、技術服務、生活服務等校園信息的收集、處理、整合、存儲、傳輸和應用，使數字資源得到充分優(yōu)化利用的一種虛擬教育環(huán)境。作為教育信息化的重要內容，數字化校園快速發(fā)展。數字化校園中集成了大量的業(yè)務系統(tǒng)，涵蓋了學校發(fā)展的方方面面，同時安全問題也前所未有的凸顯。為了保證數字化校園的健康發(fā)展，必須對數字化校園的系統(tǒng)進行安全測試。

2數字化校園的安全現狀

為貫徹發(fā)展現代化高等教育，再造中國人才紅利的國家戰(zhàn)略，響應黨中央國務院《教育信息化十年發(fā)展規(guī)劃（2011-2020年）》精神，實現教育的信息化，各高校的數字化校園建設取得了巨大的成績。在取得巨大成績的同時，巨大的安全風險也隨之而來。2017年肆掠全國的勒索病毒，其中一個高發(fā)地就是各大高校。近年來，數字化校園門戶被攻陷，主頁被篡改發(fā)布一些反動言論，數據信息被盜取的事件屢次發(fā)生。所以在假期，重大事件發(fā)生時候好多高校的數字校園門戶和系統(tǒng)就會關閉對Internet的服務功能，只能在校園內網中才能訪問，有的學校甚至為了安全只允許在內網訪問數字化校園門戶和系統(tǒng)。此舉的目的就是防止數字化校園被攻陷產生不良的社會效應，但是此舉也給廣大的老師和學生使用數字化校園系統(tǒng)帶來了極大的不方便，嚴重的限制了數字化校園的使用率和發(fā)展。此種現象的產生歸根結底是由于大多數學校的數字化校園過分依賴于數字化校園的開發(fā)公司，校方自身的技術能力有限，對于數字化校園的安全防范能力的認知基本上也是停留在開發(fā)公司的匯報上，校方自身并沒有一個比較清楚地掌握。

3數據安全的測試

數字化校園安全問題的核心是數據安全的問題。在建設數字化校園的過程中，為了防止數據孤島和數據不一致的情況出現，建設了統(tǒng)一的數據中心。所有數字化校園的應用系統(tǒng)都要和統(tǒng)一的數據中心交換數據，所以數據中心的數據一旦遭到破壞，對于整個的數字化校園來說將是嚴重的損失，輕則需要斷網恢復數據，重則無法恢復數據導致災難性的后果。所以數據的安全是安全測試的重中之重，必須花大力氣去保證。

3.1簽訂合同和需求階段

對于數據安全，我們要考慮最壞的結果，如果數據全部丟失或破壞，我們應該怎么做？別無他法，唯有數據的備份才能解決這一問題。備份有兩種形式，一種是同一機房備份，既可以把數據備份到數據庫所在的服務器，也可以備份到專門的服務器上，另一種就是異地備份。不同的備份各有自己的優(yōu)缺點，主要的差別在于成本，所以在前期一定要把備份方式進行明確，以確定項目的成本，如果在項目后期再變動備份方式，就牽扯到很多方面，比較麻煩。

對于數據安全來說，還有一個很重要的特點就是機密性，對于一些重要數據或者是個人信息，即使數據庫數據泄露，也不能使對方輕易獲取信息，這就需要對數據進行加密。此類事情最著名的事件就是2011年CSDN的數據庫‘脫庫事件。作為著名的計算機軟件行業(yè)的雜志在自己的網站中竟然用明文的形式存儲了用戶的登錄密碼，導致六百多萬的用戶賬戶信息被盜，教訓非常慘痛。數字化校園的數據中心中存儲的用戶的登錄密碼，個人姓名、身份證號、手機號、工資信息等個人信息都需要保證安全，所以在需求文檔中必須明確規(guī)定需要加密的字段列表。

在這個階段，測試的重點就是檢查合同和需求文檔中，驗證是否有具體的條款來約定備份方式和需要加密存儲的信息列表。這個測試很簡單，但是很重要，一定要做，問題解決越早，成本越低。

3.2驗收階段

驗收階段需要對照合同或者需求文檔中約定的數據備份方式進行驗收。具體做法如下：根據合同或需求文檔約定在對應的服務器上查看是否有數據備份；通過對數據庫中的數據進行修改，刪除、新增，銷毀等操作改變數據庫中的數據；通過備份的數據進行數據庫的數據恢復，驗證數據庫中的數據是否能夠完全恢復，如果能夠恢復，測試通過，如果不能則要求整改。

對于需要加密的字段直接進入數據庫查看，如果用密文存儲，驗收合格，如果是明文需要開發(fā)公司整改。

4攻擊手段及測試方法

對于數字化校園系統(tǒng)的安全隱患主要集中在以下幾個方面：SQL注入攻擊、文件上傳漏洞、XSS攻擊、CSRF攻擊等。

4.1 SQL注入攻擊

SQL注入攻擊的本質就是把用戶輸入的數據當做代碼執(zhí)行。這里有兩個關鍵條件，第一個是用戶能夠控制輸入，第二個是原本程序要執(zhí)行的代碼，拼接了用戶輸人的數據。

下面我們介紹一下SQL注入的原理，我們用一個例子來演示。在很多數字化校園的門戶中都有一個登錄界面，需要用戶提供用戶名（username）和密碼（password），如果這個功能是一個沒有安全意識的新程序員開發(fā)的，程序如下：

a.在登錄界面中的用戶名輸入單引號，如果系統(tǒng)沒有做相應的處理，這時候構造的sql語句是有語法錯誤的，這個時候如果出現了web服務器的錯誤回顯信息例如：[OleDbException（Ox80040e14）：字符串的語法錯誤在查詢表達式‘UserName=‘中。]這些錯誤回顯信息證明系統(tǒng)存在注入漏洞，同時也暴露了一些敏感信息，對于攻擊者來說，構造SQL注入的語句就可以更加得心應手，所以如果出現錯誤回顯信息，這時候必須要求開發(fā)公司關閉web服務器的回顯信息。

b.構造SQL注入語句，對于登錄界面，我們可以對用戶名構造‘or‘1=1一類似這樣的語句查看系統(tǒng)是否可以匿名登錄。如果可以匿名登錄，說明有SQL注入漏洞，需要整改。

c.構造SQL注入語句，比如一個應用URL：http：∥127.0.0.1：8085/items.aspx？id=1，執(zhí)行的SQL語句可能為Sdect*fromitems_table where id=1，這時候我們可以構造如下條件的語句：http：∥127.0.0.1：8085/items.aspx？id=1 and 1=2，如果這個時候頁面無法顯示，我們繼續(xù)構造http：∥127.0.0.1：8085/items.aspx？id=1 and 1=1，如果這時候頁面可以正常顯示，則說明存在SQL注入漏洞，需要整改。

4.2文件上傳漏洞

文件上傳漏洞是指用戶上傳了一個可以執(zhí)行的腳本文件，并通過此腳本文件獲得了執(zhí)行服務器端命令的能力。做如下測試：

a.根據需求文檔得到可以上傳文件類型的白名單，然后用白名單外的文件類型進行上傳，驗證系統(tǒng)是否能夠正確處理，如果可以上傳，需要開發(fā)公司進行整改。

b.對于上面測試后不能上傳的文件，將其后綴改為白名單中的文件類型，假設白名單文件中沒有.aspx文件類型，有.docx文件類型，我們要上傳1.aspx文件，將其改名為1.docx，這時候只是改了后綴名，文件內容并無任何變化，如果能夠上傳，同樣需要開發(fā)公司進行整改。

4.3 XSS攻擊

XSS攻擊稱為跨站腳本攻擊，英文全稱是Cross Site Script。XSS攻擊是客戶端腳本安全中的頭號大敵。XSS攻擊是指通過“HTML注人”篡改了網頁，插入了惡意腳本，從而在用戶瀏覽網頁時，控制用戶瀏覽器的一種攻擊。我們用一個例子來說明XSS攻擊的原理。假設一個頁面把用戶輸入的參數直接輸出到頁面上：

在正常情況下，用戶向param提交的數據會展示到頁面中，比如提交

http：∥127.0.0.1：8085/test.php？param=正常顯示，此時查看頁面源代碼，可以看到

。但是如果提交的是http：∥127.0.0.1：8085hest.php？param=，這是在頁面上會彈出一個內容為“攻擊”的彈出框。從這里可以看出系統(tǒng)可以執(zhí)行用戶的命令，如果黑客構造了更為復雜的和帶有攻擊性的參數，將會給用戶和系統(tǒng)帶來風險。下面我們針對XSS攻擊的主要防御手段來建立我們的測試方法。

4.3.1對輸入和輸出進行檢查

對于XSS攻擊的防御方式主要有對輸入和輸出進行檢查過濾或轉義危險的特殊字符，比如<、>、等。

a.對于輸入內容有限制的字段進行功能測試。比如用戶名，假如限定用戶名只能由數字和字母組成，這時我們就要測試輸入非數字和字母的內容后能否通過檢查。

b.對于輸入內容無限制的，這時候我們需要構造一些包含這樣的內容，看系統(tǒng)是否會彈出用戶輸人的彈出框。如果有彈出框，測試不通過，需整改。

c.針對get方式的URL構造帶有執(zhí)行代碼的參數，例如http：∥127.0.0.1：8085/test.php？param=，看看是否有彈出框。如果有彈出框，測試不通過，需整改。

4.3.2使用HttpOnly解決XSS后的Cookie劫持

黑客可以通過XSS竊取用戶的Cookie，然后登陸進該用戶的賬戶。在這個過程中的關鍵就是黑客可以讀取用戶的Cook-ie并發(fā)給自己。HttpOnly這個屬性將會使JavaScript無法讀取Cookie。所以這個測試我們主要看系統(tǒng)是否對Cookie設置了HttpOnlv屬性。我們通過在網站地址欄中輸入javacript：alert（document.cookie）看是否顯示cookie，如果不顯示，測試通過。如果顯示則需要和開發(fā)公司確認顯示的Cookie是否和登錄認證有關，如果有關則需要開發(fā)公司整改。

4.4 CSRF攻擊

CSRF稱為跨站點請求偽造，全名是Cross Site Request Forgery.可以這么理解CSRF攻擊：攻擊者盜用了你的身份，以你的名義發(fā)送惡意請求。CSRF能夠做的事情包括：以你名義發(fā)送郵件，發(fā)消息，盜取你的賬號，轉賬虛擬貨幣等。

我們以錄入學生成績?yōu)槔?，教務系統(tǒng)A，它以GET請求來完成成績錄入的操作，如：http：∥www.jw.com/luru.php？studentid=11&shuxue;=90&yuwen;=90&zhengzhi;=90，同時還有危險網站B，它里面有一段HTML的代碼如下：。

首先，錄入成績的老師登錄了教務網站A，然后訪問了危險網站B，這時會發(fā)現id為11的學生成績已經錄入了系統(tǒng)。

應對CSRF攻擊的一種主要手段就是給傳遞的參數增加一個Token，Token的值是隨機的，這樣危險網站B上的請求因為沒有Token隨機值將不能被執(zhí)行。所以我們的測試就是在需要防止CSRF攻擊的頁面進行輸入并提交，驗證構造的參數中是否有Token參數，并查看其值是否一個隨機值。

5使用測試工具

以上介紹了數字化校園應用系統(tǒng)中安全測試的原理和方法，但是對于攻擊測試比如SQL注入，XSS攻擊等技術要求比較高，而且特別繁瑣，手動測試是比較困難的，因此我們需要使用對應的安全測試工具。對于數字化校園應用系統(tǒng)推薦兩款免費的掃描器：w3af和skipfish。對于sql注入推薦SQLMAP。

6選擇測試方式

在數字化校園項目驗收的關鍵時刻，安全測試究竟該由誰來執(zhí)行，一般有以下三種方式，每個學校根據自己的實際情況來進行選擇。

6.1校方自行進行安全測試

此種情況的前提條件是校方自身必須具有較強的技術能力，這樣校方可以自己對開發(fā)公司交付的數字化校園系統(tǒng)進行安全測試。此種方式由于校方的測試團隊對業(yè)務需求了解得更清楚，這樣的測試更有針對性，測試更全面，測試結果更可靠。

6.2聘請第三方測試團隊測試

專業(yè)的測試團隊，技術強、經驗豐富，會最大程度的發(fā)現系統(tǒng)中存在的安全隱患。但此種方式需要額外的資金預算，同時需要考察測試團隊的資質。

6.3讓開發(fā)公司來測試

如果校方即無較強技術能力也無對應的資金預算，可以讓開發(fā)公司提供安全測試報告。通過這種方式可以促使開發(fā)公司更加注意系統(tǒng)的安全問題，提高系統(tǒng)的安全性能。根據測試規(guī)律，自己測試自己的產品會陷入思維定勢，有些問題難以發(fā)現。

7總結

數字化校園的快速發(fā)展是實現教育信息化的重要手段，數字化校園要更快更好的發(fā)展，必須要有安全保駕護航。做好數字化校園系統(tǒng)的安全測試工作，就是要盡可能提高系統(tǒng)的安全性，讓教職工和學生在一個安全放心的環(huán)境下使用數字化校園的系統(tǒng)。但是世界上沒有絕對的安全，做安全測試是為了盡可能地發(fā)現系統(tǒng)存在的安全漏洞，然后解決漏洞，安全測試不能解決所有的安全問題，只是提高攻擊人員的攻擊成本，降低系統(tǒng)的風險。攻擊手段不斷推陳出新，花樣百出，我們要持續(xù)關注安全領域的新動向。我們要以安全工作永遠在路上的態(tài)度來做好數字化校園的安全工作。