孫 歆，張 聞

（浙江省電力試驗研究院，杭州 310014）

應用系統(tǒng)的安全性越來越受到人們的關注，利用B/S（瀏覽器/服務器，Browser/Server）應用系統(tǒng)的漏洞進行入侵、滲透已經成為互聯(lián)網安全隱患之一。企業(yè)內部的管理信息系統(tǒng)大部分采用B/S架構，如何保障系統(tǒng)安全和企業(yè)核心數據不受破壞，已成為企業(yè)信息部門的焦點問題。應用系統(tǒng)在上線前進行安全性測試，可以驗證其是否存在安全缺陷和漏洞，是企業(yè)信息安全管控的重要手段。很多廠商或企業(yè)內部QA部門雖能提供安全性測試服務，但安全性測試對技能要求較高，也缺乏可參照的標準和規(guī)程。本文分析了B/S結構應用系統(tǒng)存在的主要安全問題并介紹了測試方法，可為企業(yè)安全性測試提供指導。

1 B/S結構特點

B/S是當前主流的應用系統(tǒng)結構，具有客戶層、應用層、數據層等多層結構，用戶可通過瀏覽器訪問應用，實現(xiàn)瘦客戶端。與傳統(tǒng)的C/S（客戶端/服務器，Client/Server）結構相比，B/S結構更加靈活高效，特別是Web2.0技術興起之后，其在客戶端的表現(xiàn)絲毫不遜色于C/S。但與此同時，B/S應用系統(tǒng)存在更多的安全隱患，原因是：B/S結構系統(tǒng)只要有瀏覽器就可訪問，用戶難以控制；HTTP（S）協(xié)議為無連接協(xié)議，較難進行會話跟蹤；AJAX技術使B/S系統(tǒng)由“瘦”轉“胖”，交互更多樣化、更加隱蔽；B/S系統(tǒng)開發(fā)門檻較低，不專業(yè)的開發(fā)者可能引起系統(tǒng)安全問題等。

2 測試方法與手段

本文介紹的安全性測試屬于軟件測試中的黑盒測試，除了向用戶獲取部分系統(tǒng)相關信息和資料，如系統(tǒng)采用的技術、系統(tǒng)構架、所使用的中間件、數據庫和操作系統(tǒng)等，測試人員并不知道系統(tǒng)的工作原理和細節(jié)。安全性測試手段可以分為工具測試和手工測試兩種，工具測試指利用自動化測試工具幫助測試人員完成信息搜集或常見安全漏洞檢測工作，提高測試效率和準確性，較為常用的商業(yè)測試工具有IBM AppScan和A-cunetix Web Vulnerability Scanner。手工測試指安全測試團隊憑借個人經驗，通過測試向量的輸入和相應的輸出判斷系統(tǒng)是否存在安全問題，并進行一定程度的滲透測試，確定安全問題的風險等級。一般來說，安全測試應以人工測試的結果為主要依據，工具測試的結果只能作為參考，測試人員應對其進行驗證和確認，不可盲從。

3 安全性測試技術

對B/S應用系統(tǒng)漏洞的檢測方法和滲透技術，目前還沒有相應的測試標準，但有一些安全組織團體編寫了安全性測試的指導文檔，比較有代表性的是OWASP組織編寫的OWASP Testing Guide，也有書籍和論文闡述了關于B/S系統(tǒng)的安全測試以及漏洞檢測方法。本文參考了上述方法，結合本企業(yè)應用系統(tǒng)的實際情況，著重介紹SQL注入、跨站腳本、上傳漏洞等幾種常見應用系統(tǒng)漏洞的安全性測試方法。

3.1 SQL注入

SQL注入是最常見的B/S應用系統(tǒng)漏洞，危害極大。該漏洞是由于對輸入參數過濾不嚴，導致任意語句可注入到程序原有的SQL語句，執(zhí)行數據庫權限范圍內的任意SQL語句。圖1為某新聞內容顯示頁面存在SQL注入的語句。

圖1 典型的SQL注入漏洞代碼

由于沒有對參數id進行過濾而直接將其拼接到SQL語句中執(zhí)行，攻擊者可以通過id參數注入自己的SQL語句。比如當id＝1;drop table author;時，SQL語句select id,news,time,author from article where id＝1;drop table author;被執(zhí)行，author表將被刪除。

絕大多數應用系統(tǒng)都可用安全測試工具檢測SQL注入漏洞，但為了確保測試結果，建議以手動測試為主，工具檢測為輔。測試是否存在SQL注入就是要確認參數是否被帶入SQL語句執(zhí)行，注入的參數類型有數字型、字符型和搜索型3種?？衫媒浀浞ㄒ来螌︽溄又械膮颠M行測試，在參數中注入SQL語句，檢查語句是否被執(zhí)行。假設被測鏈接為article.php?id＝1，其測試向量如表1所示。

表1 3種參數類型SQL注入漏洞的測試方法

測試實際上就是輸入布爾邏輯，根據回顯判斷或推理想要的數據。 表 1 中的“1＝1、 1＝2”等可以用其他布爾邏輯代替。數字型和字符型注入則多出現(xiàn)在用于檢索的id值，比如文獻的id，搜索型注入則多出現(xiàn)在搜索關鍵字段中。各種類型的參數都有可能出現(xiàn)注入漏洞，包括GET，POST，HTTP頭、COOKIE等，前兩者較為常見，后兩者雖出現(xiàn)較少，但容易被程序員忽視。檢測HTTP頭和COOKIE注入或者AJAX程序時，需要用到代理工具截獲并篡改HTTP數據包進行測試，常用的代理工具有Webscarab和TamperIE。

3.2 跨站腳本

跨站腳本漏洞也是較常見的漏洞，是由于對輸入參數驗證不嚴導致客戶端可執(zhí)行任意構造的客戶端腳本，實質上屬于一種代碼注入漏洞。典型的存在跨站漏洞的代碼如圖2所示。

圖2 典型的跨站漏洞代碼

圖2中的代碼沒有對$keyword變量進行過濾，直接輸出到表現(xiàn)層，用戶可以構造惡意客戶端代碼，進行跨站攻擊。例如可以構造如下代碼盜取用戶 cookie：＜script＞document.write （"＜img src ＝'http∶//evilsite.com/getCookies?c ＝ "+document.cookie+"'＞"）＜/script＞。 跨站腳本漏洞會對存在漏洞頁面的客戶端產生巨大危害，造成掛馬、信息泄露等嚴重安全問題。隨著Web2.0技術的廣泛應用，跨站漏洞危害將越來越大。

跨站腳本漏洞可以用工具檢測，但可能輸入垃圾數據。手工測試時一般對請求參數注入＜script＞alert（/xss/）＜/script＞等跨站測試向量， 查看該Javascript代碼是否反饋到了客戶端。如果系統(tǒng)未經處理直接反饋代碼，將彈出一個對話框。與測試不同，惡意攻擊者通常是將代碼改為盜取cookie、下載木馬等操作。測試中應考慮以下幾種情況：

（1）＞＜script＞window.alert（"xss"）＜/script＞， 前面添加尖括號閉合之前的HTML標簽，使得代碼生效。

（2）＜script＞alert[String.fromCharCode（88， 115，115,84,101,115,116）]， 利用 ASCII碼轉換繞過引號過濾。

（3）利用＜sCripT＞或＜scr%00ipt＞等混淆手段繞過特征字符串過濾。

（4）＜img src＝javascript∶alert（'xss'）；＞， 使用img或iframe等標簽繞過script特征字符串。

（5）＜div style＝"width∶expression（alert（'xss'））；"＞，繞過script和javascript特征字符串。

3.3 上傳漏洞

上傳漏洞是由于程序沒有對上傳的文件進行類型判斷，從而造成惡意文件上傳至服務器，攻擊者可能因此獲得應用系統(tǒng)的webshell。當系統(tǒng)存在上傳文件模塊時，測試人員必須注意。

上傳漏洞檢測比較復雜，只能靠人工測試。一般是上傳各種類型文件并判斷上傳是否成功，所以測試過程中會引入垃圾數據。如果上傳成功，還應判斷文件上傳后是否可執(zhí)行，因為某些程序會將上傳文件改名或隱藏文件路徑，使得文件無法運行。常用的上傳漏洞測試向量如下：

（1）直接上傳 asp，php，jsp， asa甚至 exe等腳本文件或可執(zhí)行文件，檢查系統(tǒng)是否對文件類型進行過濾。

（2）文件后綴大小寫混編（如 AsP， pHp）， 或后綴嵌套（如asaspp），繞過后綴過濾。

（3）IIS，Apache等服務器軟件的某些版本存在文件名解析漏洞，如利用IIS路徑解析漏洞上傳文件名為test.asp；1.jpg的腳本。

（4）有些程序通過 HTTP頭的Content-Type參數判斷文件類型，則可利用代理工具修改該參數再上傳，繞過文件類型過濾機制。

（5）某些系統(tǒng)采用第三方文字編輯插件，如FCKEditor，eWebEditor等，這些插件的多個版本存在上傳漏洞，可依據相關漏洞測試方法測試。

3.4 目錄遍歷

目錄遍歷是較為常見的Web應用漏洞，是由于程序沒有對父路徑進行有效限制，造成攻擊者可獲取主機任意文件資源。某些系統(tǒng)利用參數傳遞文件路徑，讀取目標文件后再輸出，進行文件下載或圖片顯示，此時可能存在遍歷漏洞。典型的問題代碼如圖3所示。

圖3 典型的目錄遍歷漏洞代碼

圖3中的代碼沒有對path參數進行驗證，如果用戶將path改為../../../etc/passwd，將會直接下載Linux系統(tǒng)的passwd文件。Windows系統(tǒng)也可用c∶/windows/boot.ini進行測試。

測試目錄遍歷漏洞應輸入各種形式的父路徑，檢查是否可以突破應用根目錄限制，訪問操作系統(tǒng)文件或敏感文件，如數據庫連接文件、密碼文件等。以獲取linux的passwd文件為例，典型的測試向量如下：

（1）利用 URL 編碼： %2e%2e%2f%2e%2e%2fetc/passwd。

（2）利用不同路徑分隔符：....etcpasswd。

（3）利用 UTF-8 編碼：%c0%ae%c0%ae/%c0%ae%c0%ae/etc/passwd。

3.5 權限繞過

權限繞過漏洞十分普遍，通常由程序員權限控制機制存在安全缺陷引起，如只在登陸時進行權限控制，而沒有對每個模塊的權限控制節(jié)點進行控制，導致用戶直接輸入URL即可訪問不具備權限的資源。這種情況通常是程序員疏忽大意或缺乏良好的編程習慣造成的，應在需求分析和設計階段對安全需求進行規(guī)范。

權限繞過測試可以利用管理員賬號進入管理模塊，搜集管理子模塊的URL，再用一般用戶賬號登陸，直接輸入這些URL，驗證是否可以進入并進行相應操作，如果URL數量龐大，可適當抽取部分進行驗證。可考慮3種情況進行測試：

（1）匿名用戶是否可訪問系統(tǒng)資源。

（2）低權限用戶是否可訪問高權限資源。

（3）當系統(tǒng)有工作流模塊時，測試是否可以查看和操作非權限內流程節(jié)點的內容。

有些系統(tǒng)利用GET，POST，COOKIE等可被用戶控制的參數進行權限判斷，比如某些程序通過COOKIE參數isAdmin判斷當前用戶是否為管理員，而COOKIE參數可以在客戶端輕易被篡改，從而造成漏洞。測試這種情況一般通過代理工具獲取傳遞的參數，由參數名推測該參數的用途，并在篡改參數后查看是否獲取了相關權限。

3.6 代碼注入

代碼注入是由于沒有對輸入參數進行嚴格審核導致參數中的代碼被服務器執(zhí)行，可由多種途徑引起，比較典型的是腳本文件包含和命令執(zhí)行。腳本包含多發(fā)生于php程序，php腳本可允許通過include函數包含另一個腳本并執(zhí)行，而當被包含的腳本路徑來自于用戶輸入的參數，則有可能出現(xiàn)漏洞。當php.ini中的allow_url_fopen和allow_url_include都配置為On時，甚至可以包含執(zhí)行外部文件，形成遠程包含漏洞，其危害更為嚴重。典型的腳本包含漏洞代碼如圖4所示。

圖4 典型的腳本包含漏洞代碼

圖4代碼中，需要包含connect.php文件進行數據庫連接，但如將path改為其他惡意文件路徑，do.php將執(zhí)行該惡意文件。當然，利用本地包含漏洞需要事先在服務器文件中注入惡意代碼，而遠程包含漏洞的利用則更為便利。

該漏洞無法利用工具測試，只能憑經驗人工判斷和測試。測試人員可從參數名推測是否用于文件包含路徑，并將參數改為自定義的腳本路徑，檢查是否執(zhí)行了自定義腳本。對于本地包含，可將惡意代碼寫入URL，將其注入系統(tǒng)日志文件中，再包含該日志文件以達到利用目的。而遠程包含則可在其他站點上傳腳本進行包含測試。

4 結語

本文介紹了B/S結構應用系統(tǒng)上線前的安全性測試方法以及實施流程，根據電力企業(yè)實際情況結合安全組織的測試方法綜合得出，已在浙江電力企業(yè)得到實際運用，并取得了良好的效果，為應用系統(tǒng)上線后的安全穩(wěn)定運行提供了保障。

[1] 中國信息安全測評中心.Web系統(tǒng)安全和滲透性測試基礎[M].北京：航空工業(yè)出版社，2009.

[2] 劉述景.基于風險評估的滲透測試方案的研究與實施[D].北京郵電大學，2009.

[3] 楊廣華，齊璇，施寅生.基于威脅模型的軟件安全性測試[J].計算機安全，2010（02）∶11-13.

[4] 施寅生，鄧世偉，谷天陽.軟件安全性測試方法與工具[J].計算機工程與設計，2008，29（01）∶27-30.

[5] 劉文晉.遠程滲透測試中的SQL注入攻擊技術研究[D].北京交通大學，2009.

[6] MICHAEL CROSS，STEVEN KAPINOS.Web Application Vulnerabilities Detect，Exploit，Prevent[M].Syngress，2007.

[7] JUSTIN CLARKE，SQL Injection Attacks and Defense[M].Syngress，2009.

[8] JEREMIAH GROSSMAN，XSS Attacks Exploits and Defense[M].Syngress，2007.

[9] ANURAG AGARWWAL，OWASP Testing Guide[S].OWASP，2008.