孫 歆，張 聞

（浙江省電力試驗(yàn)研究院，杭州 310014）

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

1 B/S結(jié)構(gòu)特點(diǎn)

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

2 測試方法與手段

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

3 安全性測試技術(shù)

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

3.1 SQL注入

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

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

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

絕大多數(shù)應(yīng)用系統(tǒng)都可用安全測試工具檢測SQL注入漏洞，但為了確保測試結(jié)果，建議以手動(dòng)測試為主，工具檢測為輔。測試是否存在SQL注入就是要確認(rèn)參數(shù)是否被帶入SQL語句執(zhí)行，注入的參數(shù)類型有數(shù)字型、字符型和搜索型3種?？衫媒?jīng)典法依次對鏈接中的參數(shù)進(jìn)行測試，在參數(shù)中注入SQL語句，檢查語句是否被執(zhí)行。假設(shè)被測鏈接為article.php?id＝1，其測試向量如表1所示。

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

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

3.2 跨站腳本

跨站腳本漏洞也是較常見的漏洞，是由于對輸入?yún)?shù)驗(yàn)證不嚴(yán)導(dǎo)致客戶端可執(zhí)行任意構(gòu)造的客戶端腳本，實(shí)質(zhì)上屬于一種代碼注入漏洞。典型的存在跨站漏洞的代碼如圖2所示。

圖2 典型的跨站漏洞代碼

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

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

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

（2）＜script＞alert[String.fromCharCode（88， 115，115,84,101,115,116）]， 利用 ASCII碼轉(zhuǎn)換繞過引號(hào)過濾。

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

（4）＜img src＝j(luò)avascript∶alert（'xss'）；＞， 使用img或iframe等標(biāo)簽繞過script特征字符串。

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

3.3 上傳漏洞

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

上傳漏洞檢測比較復(fù)雜，只能靠人工測試。一般是上傳各種類型文件并判斷上傳是否成功，所以測試過程中會(huì)引入垃圾數(shù)據(jù)。如果上傳成功，還應(yīng)判斷文件上傳后是否可執(zhí)行，因?yàn)槟承┏绦驎?huì)將上傳文件改名或隱藏文件路徑，使得文件無法運(yùn)行。常用的上傳漏洞測試向量如下：

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

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

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

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

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

3.4 目錄遍歷

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

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

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

測試目錄遍歷漏洞應(yīng)輸入各種形式的父路徑，檢查是否可以突破應(yīng)用根目錄限制，訪問操作系統(tǒng)文件或敏感文件，如數(shù)據(jù)庫連接文件、密碼文件等。以獲取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 權(quán)限繞過

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

權(quán)限繞過測試可以利用管理員賬號(hào)進(jìn)入管理模塊，搜集管理子模塊的URL，再用一般用戶賬號(hào)登陸，直接輸入這些URL，驗(yàn)證是否可以進(jìn)入并進(jìn)行相應(yīng)操作，如果URL數(shù)量龐大，可適當(dāng)抽取部分進(jìn)行驗(yàn)證。可考慮3種情況進(jìn)行測試：

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

（2）低權(quán)限用戶是否可訪問高權(quán)限資源。

（3）當(dāng)系統(tǒng)有工作流模塊時(shí)，測試是否可以查看和操作非權(quán)限內(nèi)流程節(jié)點(diǎn)的內(nèi)容。

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

3.6 代碼注入

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

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

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

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

4 結(jié)語

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

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

[2] 劉述景.基于風(fēng)險(xiǎn)評估的滲透測試方案的研究與實(shí)施[D].北京郵電大學(xué)，2009.

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

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

[5] 劉文晉.遠(yuǎn)程滲透測試中的SQL注入攻擊技術(shù)研究[D].北京交通大學(xué)，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.