侯海燕 符志鵬

摘要：該文闡述了網絡軟件安全檢測的重要性，介紹了現(xiàn)有的主要檢測方法，包括形式化安全測試、基于模型的安全功能測試、語法測試、基于故障注入的安全測試、基于屬性的測試、模糊測試、基于風險的安全性測試、基于故障樹的安全性測試以及基于滲透的安全性測試。

關鍵詞：安全性檢測；功能測試；漏洞測試；安全測試方法

中圖分類號：TP393 文獻標識碼：A 文章編號：1009-3044（2014）25-5847-05

Survey of Software Security Test Technology

HOU Hai-yan， FU Zhi-peng

（College of Medical Technology and Engineering， Henan University of Science and Technology， Luoyang 471000， China）

Abstract： The importance of software security test is described in this paper and the main software security test method is introduced such as model based method， Grammar-based method， Syntax-based method， defects threat tree modeling method and so on.

Key words： security test； functional test； vulnerability test； security test method

在互聯(lián)網普及之前，單機應用程序軟件安全問題并不突出。但是自從互聯(lián)網普及后，軟件安全問題愈加顯加突顯，使得軟件安全性測試的重要性上升到一個前所未有的高度。同時，隨著軟件的廣泛應用和其規(guī)模、復雜度的不斷提高，軟件安全性問題日益突出。軟件安全性測試是保證軟件安全和質量、降低軟件安全風險的重要手段。

軟件安全性測試分為安全功能測試（Security Functional Testing）和安全漏洞測試（Security Vulnerability Testing）兩個方面，如表1所示。

表1 安全功能測試和安全漏洞測試

1 軟件安全測試的主要方法

1.1 形式化安全測試

建立軟件的數學模型，利用形式化規(guī)格說明語言對其進行說明[1]，形式規(guī)格說明語言主要包括以下幾類[2]：

基于模型的Z、VDM和B語言；

基于有限狀態(tài)語言，如有限狀態(tài)自動機、SDI；

代數語言，如OBJ；

基于行為的CSP、CCS、Petri Nets等語言；

混合語言，如離散和連續(xù)數學的規(guī)格說明語言；

狀態(tài)圖

形式化安全測試方法分為定理證明和模型檢測兩類，如表2所示。

表2 形式化安全測試方法分類

[定理證明＼&模型檢測＼&將程序轉換為邏輯公式，然后使用公理和規(guī)則證明程序是否是一個合法的定理＼&運用狀態(tài)遷移系統(tǒng)描述軟件行為，運用時序邏輯、計算樹邏輯等表示軟件執(zhí)行所必須滿足的性質，通過自動搜索遷移系統(tǒng)中不滿足公式或邏輯的狀態(tài)來發(fā)現(xiàn)軟件漏洞＼&]

形式化安全測試的特點是數學基礎完備，對系統(tǒng)理解深入。但，開發(fā)成本高，維護困難。

1.2 基于模型的安全功能測試

基于模型的安全性測試是通過對軟件的行為和結構進行建模，生成測試模型，繼而由測試模型生成測試用例，當前主要的軟件測試模型有馬爾科夫模型、有限狀態(tài)自動機模型、UML模型[3，4]等。

Nahid Shahmehri等[5]提出一種基于模型的方法，用以檢測和跟蹤運行中的軟件所存在的漏洞，這是一種被動測試技術。開發(fā)者可以很容易的確切的知道工具所針對的漏洞類型，并且當新的漏洞被發(fā)現(xiàn)時可以通過添加新的方法將工具進行擴展。

檢測模型是基于安全目標模型SGMs的，它可以顯示產生漏洞的潛在原因，以及各種原因之間的相互關系。SGMs和威脅樹模型非常類似，后者是將引發(fā)某種威脅的所有因素用樹狀結構描述，前者則是將引起漏洞的所有可能原因用樹狀結構描述。

Mark Blackburn等[6]提出一種基于模型的軟件安全自動檢測方法，該方法提供了一種端對端的模型構造、分析、自動測試用例生成、自動執(zhí)行測試以及結果分析的綜合技術手段，該方法適用于各種環(huán)境。該檢測方法的基礎是對安全函數說明進行建模，利用Oracle和Interbase數據庫引擎自動生成模型并進行測試。

1.3 語法測試

所謂語法就是定義了軟件接受的輸入的數據類型和格式。語法測試是根據被測軟件的功能接口的語法生成測試輸入，檢測被測軟件對各類輸入的響應，通過觀察被測軟件輸入與相應之間的關系做出安全性分析[7]。其流程如下：

語法測試適合對組件進行黑盒測試[8]，根據組件接口的語法特征，正則表達可以產生正常和非正常輸入，進而觸發(fā)各種安全問題。但是其缺點是測試樣例的數量巨大，很難保證測試覆蓋全面性。

Patrice Godefroid等[9]研究了輸入結構復雜應用程序，利用基于語法的方法對非法輸入進行描述，以提高白盒測試的效果，提出了一種新的動態(tài)測試用例生成算法。

1.4 基于故障注入的安全測試

用戶輸入、文件系統(tǒng)、環(huán)境變量、網絡接口等應用程序與環(huán)境之間的交互引起的故障均可作為注入的故障。人為主動的將故障引入系統(tǒng)，可以加速系統(tǒng)失效，同時也加速了對安全問題進行排查。具體的方法包括仿真注入、硬件注入、軟件注入等。

Binbin Qu等[10]提出了一種基于客戶機-服務器模式的錯誤注入測試方法，用于軟件組件的安全性測試。作者設計了了一種基于API Hooking的錯誤注入工具，該工具GCDEFI是基于客戶機-服務器模式的，由一個服務端和多個客戶組成。服務器控制客戶機，收集反饋信息并與客戶機交互；客戶機管理API攔截、錯誤信息和目標組件信息?？蛻魴C注入到測試驅動，處于驅動的地址范圍。GCDEFI運行后，控制器從用戶得到錯誤類型信息，該信息被保存在客戶機的錯誤管理模塊?？刂破饔|發(fā)Activator，將目標組件信息送入目標組件信息管理器。每當API被攔截，調用者的信息將被獲取，我們查找堆棧和目標組件列表，看是否有匹配的組件，如果沒有就返回，如果有就進入替代代碼，進而執(zhí)行注入的錯誤?？蛻魴C中的替代函數可以與服務器通信。該工具通用性不好，只在特定的環(huán)境對特定的組件具有較好的檢測效果。

Jinfu Chen[11]設計了一種典型的COM組件安全性測試工具——CSTS，該工具具有獲取并分析COM組件、靜態(tài)分析組件漏洞、自動生成測試腳本、生成測試驅動、注入環(huán)境錯誤、引導組建運行，記錄安全隱患并寫入日志、安全評級等功能。測試流程如下：

A.創(chuàng)建測試工程

B.選擇測試組件

C.分析接口信息

D.生成測試文件

E.編譯測試裝置

F.運行測試驅動

G.引導運行過程

H.注入環(huán)境錯誤

I.開始錯誤注入測試

J.結束并保存

但是該方法的風險評級標準并不明確，有待于進一步細化和明確。

1.5 基于屬性的測試

基于屬性的安全測試方法[12]是將確定的程序編寫規(guī)則進行編碼，將其作為安全屬性，以此為依據驗證程序代碼是否符合規(guī)則。

1.6 模糊測試

模糊測試是一種基于黑盒的隨機性測試，通過隨機地變異正常的程序輸入進而檢測程序響應，以發(fā)現(xiàn)軟件中存在的漏洞，可用語法規(guī)則生成正常輸入，也可用試探法指導輸入變量的產生。模糊測試的最大問題在于代碼覆蓋率很低。

Patrice Godefroid等[13]提出了一種白盒模糊測試方法，這種方法受動態(tài)測試用例生成方法和象征性執(zhí)行方法的啟發(fā)：

A.記錄程序在正常狀態(tài)下的運行情況；

B.標記程序運行軌跡、收集輸入的限制條件；

C.將限制條件逐一取消產生新輸入，執(zhí)行不同控制路徑；

D.在啟發(fā)式高代碼覆蓋率方法的輔助下重復上述過程，完成測試過程。

該方法的不足之處在于有限的樣本尺寸限制了代碼覆蓋率。

1.7基于風險的安全性測試

風險即錯誤發(fā)生的可能性以及造成的危害程度?；陲L險的安全測試的出發(fā)點和依據是軟件安全風險，把風險分析與管理、安全測試以及軟件開發(fā)過程系統(tǒng)化。該方法具有在軟件開發(fā)的各個階段可以把有風險的安全漏洞考慮在內，將安全測試與軟件開發(fā)同步進行的優(yōu)點[14]。

Brad Arkin、Gary McGraw等人[15]研究了基于風險的安全測試方法，在軟件開發(fā)的各個階段進行異常場景、誤用模式、風險分析以及滲透測試等，其實質是將安全測試相關過程集成到軟件開發(fā)的整個生命周期中。

1.8 基于故障樹的安全性測試

基于故障樹的安全測試技術[16-20]是利用故障分析樹和故障樹來生成安全性測試用例的方法，故障樹（威脅樹）[21]實際上是一種將系統(tǒng)故障（威脅）形成原因由上到下柱層細化的過程。

Huang Song[22，23]等選擇了CERT/CC的TOP 10瑕疵用來建立威脅樹以生成測試序列。

1.8.1 威脅樹

威脅樹由威脅節(jié)點構成，根節(jié)點為待檢測瑕疵，將其向下分解，生成子節(jié)點（即須要實現(xiàn)父節(jié)點的必要步驟），子節(jié)點繼續(xù)向下分解直到無可分解）。節(jié)點分與節(jié)點和或節(jié)點兩種，如圖2所示。

圖2 節(jié)點類型

以SQL注入為例，其威脅樹和測試序列生成方法如下：

1.8.2 威脅樹生成方法

A.選擇一種典型瑕疵（待測瑕疵）作為根節(jié)點；

B.分析該節(jié)點，并將其作為父節(jié)點，將其所對應的所有情況作為子節(jié)點；標記父節(jié)點位與節(jié)點或者或節(jié)點；

C.分解子節(jié)點；

D.重復A-C，直到無可分解。

1.8.3 生成測試序列

圖3為SQL的注入威脅樹，其中SQL injection為與節(jié)點，其五個子節(jié)點為與關系，其中第四個節(jié)點為或節(jié)點，則其子節(jié)點為或關系。其測試序列為：a-b-c-e-d和a-b-c-f-d。

目前該方法還是手動進行的，工作量較大，需要設計自動化的方法才有更大的應用價值。

1.9基于滲透的安全性測試

這是一種評估網絡安全性和主機系統(tǒng)的模擬攻擊過程，安全工程師可以通過這種方式深入探測目標的安全性。滲透測試分兩類：被動攻擊和主動攻擊，被動攻擊不直接進入目標系統(tǒng)，而主動攻擊則要直接侵入目標系統(tǒng)。滲透測試步驟[24]如下所示：

Shu Xiao[25]等設計了一種用于網絡協(xié)議安全測試的解決方案，建立了一套完整的協(xié)議代碼健壯性評估環(huán)境。該環(huán)境的核心測試系統(tǒng)包括多功能測試引擎和PDU（協(xié)議數據單元）生成工具兩部分。

其中測試引擎工作流程為，首先由預定義資源或者命令行參數來決定內部功能模塊的屬性，這些內部功能模塊包括發(fā)送接收模塊、反饋模塊、測試樣本庫模塊；然后，發(fā)送模塊從測試樣本庫獲取一個測試樣本，發(fā)送給指定的后處理單元（TCP/UDP或IP套接字），數據被封裝；之后封裝的數據傳遞給虛擬網絡接口，由它發(fā)送給特定的目的單元。與此同時，發(fā)送模塊還會通知接收單元接收同步響應消息，并將其放入響應池，然后接收模塊調用反饋模塊分析返回包，根據其做出相應的修正，來決定下一個測試樣本。如此循環(huán)，如圖3所示。

PDU（協(xié)議數據單元）生成工具由Perl編寫，可以由PDU模版獲取規(guī)則，由此而生成所有的測試樣本。該系統(tǒng)在發(fā)現(xiàn)一般軟件漏洞以及對于網絡協(xié)議漏洞引起的問題的異常處理是十分有效的。適用于現(xiàn)代網絡產業(yè)環(huán)境中的自動檢測。該系統(tǒng)也支持同步接口錯誤注入。作為一種非傳統(tǒng)測試方法，有助于生產更安全的軟件產品。

該方法具有較大的局限性，僅對TCP/IP協(xié)議漏洞檢測有效，對于其他的協(xié)議和網絡通訊軟件的測試還無能為力。

Csaba Nagy[26]等提出的基于輸入相關錯誤的靜態(tài)安全性分析方法是基于這樣一個思想：輸入數據是沿著一定的路徑傳遞的，而錯誤可以出現(xiàn)在任何地方，但是當錯誤出現(xiàn)在該路徑上，它就會成為一個安全漏洞。該方法的步驟如下：

A.找到數據輸入點

B.得到程序中的輸入點集

C.列出危險（輸入相關函數）函數列表

D.自動檢測

該方法技術上采用了程序依存圖和系統(tǒng)依存圖來進行分析，通過輸入覆蓋指標和輸入距離指標來衡量數據距離原始輸入的距離以及輸入相關函數得到輸入的位置，這兩個指標可以告訴我們哪些函數是和用戶輸入相關的。得到這些函數后就可以進行自動錯誤檢測了。

1.10其他分類方法

此外，根據測試對象的不同，軟件安全測試還可分為應用程序安全測試、操作系統(tǒng)安全測試、數據庫安全測試、IIS服務器安全測試、網絡環(huán)境安全測試。具體如表3所示：

2 總結

軟件安全測試的實現(xiàn)有諸多的困難，需要測試工程師擁有高效的工具，豐富的經驗、全面的技能，這是一個相互聯(lián)系的整體。豐富的經驗包括對軟件安全漏洞，以及各種黑客攻擊手段的充分了解；全面的技能包括掌握編程、網絡、數據庫等知識；在此基礎上方能開發(fā)出高效的軟件安全測試工具。

參考文獻：

[1] 魏懷鑒，鮑皖蘇. 形式化方法和測試技術及其在安全中的應用[J].微計算機信息， 2006， 22（11）： 55-57.

[2] Chen H， Wagner D. MOPS： an infrastructure for examining security properties of software[C]//Proceedings of the 9th ACM conference on Computer and communications security. ACM， 2002： 235-244.

[3] Lodderstedt T， Basin D， Doser J. SecureUML： A UML-based modeling language for model-driven security[M]//? UML? 2002—The Unified Modeling Language. Springer Berlin Heidelberg， 2002： 426-441.

[4] Sheng Q Z， Benatallah B. ContextUML： a UML-based modeling language for model-driven development of context-aware web services[C]//Mobile Business， 2005. ICMB 2005. International Conference on. IEEE， 2005： 206-212.

[5] Shahmehri N， Mammar A， Montes de Oca E， et al. An advanced approach for modeling and detecting software vulnerabilities[J]. Information and Software Technology， 2012， 54（9）： 997-1013.

[6] Blackburn M， Busser R， Nauman A， et al. Model-based approach to security test automation[J]. Proccedings of Quality Week 2001， 2001.

[7] Godefroid P， Kiezun A， Levin M Y. Grammar-based whitebox fuzzing[C]//ACM SIGPLAN Notices. ACM， 2008， 43（6）： 206-215.

[8] Tal O， Knight S， Dean T. Syntax-based Vulnerability Testing of Frame-based Network Protocols[C]//PST. 2004： 155-160.

[9] Godefroid P， Kiezun A， Levin M Y. Grammar-based whitebox fuzzing[C]//ACM SIGPLAN Notices. ACM， 2008， 43（6）： 206-215.

[10] Qu B， Huang Y， Xie X， et al. A Developed Dynamic Environment Fault Injection Tool for Component Security Testing[C]//Secure Software Integration and Reliability Improvement， 2009. SSIRI 2009. Third IEEE International Conference on. IEEE， 2009： 417-422.

[11] Chen J， Lu Y， Xie X. CSTS： A Prototype Tool for Testing COM Component Security[C]//Hybrid Intelligent Systems， 2009. HIS'09. Ninth International Conference on. IEEE， 2009， 3： 83-88.

[12] Fink G， Bishop M. Property-based testing： a new approach to testing for assurance[J]. ACM SIGSOFT Software Engineering Notes， 1997， 22（4）： 74-80.

[13] Godefroid P， Levin M Y， Molnar D A. Automated Whitebox Fuzz Testing[C]//NDSS. 2008， 8： 151-166.

[14] 張澤華，饒若楠，凌君逸.基于風險測試揭錯能力分析[J]. 計算機工程， 2004， 30（B12）： 72-73.

[15] Brad Arkin， Scott Stender， Gary McGraw： Software Penetration Testing. IEEE Security & Privacy， 2005， 3（1）： 84-87.

[16] Myers G J， Sandler C， Badgett T. The art of software testing[M]. John Wiley & Sons， 2011.

[17] Tsipenyuk K， Chess B， McGraw G. Seven pernicious kingdoms： A taxonomy of software security errors[J]. Security & Privacy， IEEE， 2005， 3（6）： 81-84.

[18] Firesmith D. Specifying reusable security requirements[J]. Journal of Object Technology， 2004， 3（1）： 61-75.

[19]Nancy R， Mead G M G. A portal for software security[J]. IEEE Computer society IEEE Security & Privacy， 2005.

[20] Moberg F. Security analysis of an information system using an attack tree-based methodology[J]. Master's

[21] C.A. Ericson II， Fault tree analysis — a history， in： Proceedings of the 17th International System Safety Conference， 1999.

[22] Song H， Liang W， Changyou Z， et al. A software security testing method based on typical defects[C]//Computer Application and System Modeling （ICCASM）， 2010 International Conference on. IEEE， 2010， 5： V5-150-V5-153.

[23] Huang S， Hui Z W， Wang L， et al. A Case Study of Software Security Test Based On Defects Threat Tree Modeling[C]//Multimedia Information Networking and Security （MINES）， 2010 International Conference on. IEEE， 2010： 362-365.

[24] 唐秀存，杜德慧.滲透測試技術與模型研究[J].計算機與信息技術，2007（5）：33-35.

[25] Xiao S， Deng L， Li S， et al. Integrated tcp/ip protocol software testing for vulnerability detection[C]//Computer Networks and Mobile Computing， 2003. ICCNMC 2003. 2003 International Conference on. IEEE， 2003： 311-319.

[26] Nagy C， Mancoridis S. Static security analysis based on input-related software faults[C]//Software Maintenance and Reengineering， 2009. CSMR'09. 13th European Conference on. IEEE， 2009： 37-46.