軟件安全性測試技術(shù)
軟件安全性測試技術(shù)【1】
摘 要 隨著(zhù)網(wǎng)絡(luò )技術(shù)的發(fā)達以及計算機技術(shù)的使用，軟件的普及率越來(lái)越高，其復雜程度以及具備的規模也不斷提高，軟件中的漏洞以及安全性的缺乏給人們造成的損失也不斷增加，軟件安全性問(wèn)題突出已經(jīng)引起了全社會(huì )的關(guān)注。
而軟件的安全性測試技術(shù)正是為了彌補軟件運用中所存在的這一缺陷而誕生的。
軟件安全性測試是降低軟件運用風(fēng)險，保證軟件使用安全性的重要手段，通曉軟件安全性測試技術(shù)，將使我們更好、更全面地了解日常使用的軟件，以及學(xué)會(huì )如果更好地規避軟件使用中的風(fēng)險。
本文將重點(diǎn)關(guān)注軟件安全性的測試技術(shù)，并從軟件安全性測試的特點(diǎn)、分類(lèi)，主要的測試方法和安全性測試工具分類(lèi)與功能這三個(gè)方面進(jìn)行相關(guān)的論述與探析。
關(guān)鍵詞 軟件;安全性;測試技術(shù)
軟件的安全性主要包括軟件的失效安全性以及保密安全性。
失效安全性是指軟件在不間斷運行中，不發(fā)生系統事故的能力。
其包括：因安全性失效可能造成單位的財產(chǎn)與人員損失、環(huán)境污染等重大安全事故。
而保密安全性是指軟件所具有的可以防止對數據和程序進(jìn)行非法存取的預防能力。
在我國，相關(guān)的軟件技術(shù)人員更多的是側重于軟件的失效安全性。
建立在可靠性理論基礎上的失效安全性主要度量標準有軟件事故率、失效度、安全度以及平均事故間隔時(shí)間。
目前常有的測試方法有基于最小割集的測試、故障樹(shù)的測試、ISO9126質(zhì)量模型、基于模型的測試、基于屬性的測試等。
1 軟件安全性測試的特點(diǎn)和分類(lèi)
軟件安全性測試是通過(guò)測試手段，來(lái)確定軟件的安全性是否與預期結果保持一致的過(guò)程。
軟件安全性的測試，是區別與其它軟件的測試類(lèi)型，它具有自身的特殊性、安全性，相關(guān)缺陷也與一般軟件缺陷相區別的特點(diǎn)。
軟件的安全性測試主要包括驗證，滲透測試，安全功能測試的過(guò)程。
與其他傳統測試軟件相比，軟件的安全性測試最大不同之處：軟件安全性測試強調軟件“不應該做什么”，而不是“應該做什么”，比如軟件缺陷所產(chǎn)生的影響甚微，但難以發(fā)現的軟件漏洞可能是致命錯誤，能讓客戶(hù)蒙受重大損失。
軟件安全性測試的這種不同，正是由其特殊性、安全性所決定的。
相比軟件中的非安全性測試，安全性測試更強調的是軟件的否定需求，比如用戶(hù)在使用該軟件的時(shí)候，如果登陸三次失敗就鎖定賬號。
相比非安全性測試中的違反常規，安全性測試的缺點(diǎn)是由軟件的副作用引起的。
比如，在非安全性測試缺陷下，本來(lái)軟件應該做G的，但它卻做了F;而在安全性測試缺陷下，本來(lái)軟件應該做G的，但是它在做完G的同時(shí)也順帶完成了F。
軟件的安全測試主要包括：安全漏洞的測試與安全功能的測試。
所謂軟件的安全漏洞指軟件系統在設計、使用等方面，存在可被利用的漏洞。
當不法分子發(fā)現或者利用這些軟件漏洞時(shí)，軟件便處于不安全的狀態(tài)。
所以，利用軟件的安全漏洞測試才能發(fā)現并識別軟件中的這些漏洞，并及時(shí)加以修補。
而所謂的安全功能需求包括數據的機密性，完整性以及可靠性，不可否認性，還包括身份認證，訪(fǎng)問(wèn)設置，跟蹤追查，安全管理，隱私保護等。
而基于軟件的安全功能需求的安全功能測試，就是用來(lái)測試該軟件是否具備與預期相一致的功能的。
2 軟件安全性測試主要方法
2.1 基于故障注入的安全性測試
故障注入的軟件安全性測試，就是指通過(guò)構造各類(lèi)協(xié)議數據包來(lái)植入故障，以測試目標軟件是否能正確處理這些預置故障。
該測試方法是Wenling Du建立的一種軟件與環(huán)境交互，將故障注入技術(shù)用于軟件安全性測試的一種故障模型。
該項目通過(guò)修改某些協(xié)議中的數據，支持的協(xié)議有HTTP、HIP、WAP、SNMP等。
故障注入就是通過(guò)故障注入函數，進(jìn)行故障模擬，并使程序強制進(jìn)入某些特定狀態(tài)，而使用常規的測試技術(shù)是很難查看到的。
2.2 基于自盒的安全性測試
基于自盒的安全測試主要是靜態(tài)分析，主要考察緩沖區溢出、數據競爭等安全性缺陷代碼模式，主要的技術(shù)分析有數據流分析、技術(shù)型推斷和約束分析。
為了在程序運行的時(shí)候插入攻擊代碼，測試安全機制是否真正可用，Lori Pollock和Ben Breech提出一種基于動(dòng)態(tài)編譯技術(shù)的安全測試框架，主要用來(lái)測試基于程序的攻擊。
2.3 攻擊樹(shù)理論與威脅模型
安全性研究方法大致可分為：基于漏洞的方法、基于威脅的方法。
前者是為了識別軟件的安全漏洞，主要是從軟件的內部考慮軟件的安全性。
而后者是通過(guò)分解應用程序(識別入口點(diǎn)，出口點(diǎn)，數據流描述)，識別要保護的資產(chǎn)等步驟，來(lái)識別軟件所面臨的安全威脅并測試是否能夠正常發(fā)生。
最常用的威脅分類(lèi)方法有篡改、欺騙、信息泄露、否認、拒絕服務(wù)等等，簡(jiǎn)稱(chēng)STRIDE。
2.4 基于模型的安全功能測試
Mark blackbum與Robert Busser研究出基于模型的安全功能測試，該模型安全功能測試常用的模型有：UML模型有限狀態(tài)機兩種。
這種方法的適用范圍取決于安全功能的建模能力，是一種較為一般的安全功能測試。
3 軟件安全性測試工具分類(lèi)與功能
為了更好地驗證系統安全機制是否有效，及時(shí)地查找軟件中的漏洞，檢測系統的運行是否正常，最近幾年產(chǎn)生了很多功能強大的安全性測試工具，這不僅大大地提高了軟件安全性的測試效率，而且在很大的程度上也降低了軟件的安全風(fēng)險，為軟件的順利運行提供了一個(gè)良好的環(huán)境。
在當前的市面上，主流的軟件安全測試工具有源代碼分析器、字節碼掃描器、網(wǎng)絡(luò )漏洞掃描器、配置分析工具、網(wǎng)絡(luò )應用漏洞掃描器、網(wǎng)絡(luò )服務(wù)掃描器、動(dòng)態(tài)分析工具、數據庫脆弱性?huà)呙杵�、設計驗證工具等，這些安全性測試工具的出現與應用，讓軟件安全性測試技術(shù)得到了進(jìn)一步的飛躍，加快了軟件的發(fā)展進(jìn)程。
4 結束語(yǔ)
本文通過(guò)具體的案例，分析了軟件安全性測試的分類(lèi)、特點(diǎn)、主要測試方法、安全性測試工具分類(lèi)與功能，深入探析軟件安全性測試。
軟件的安全性測試是通過(guò)相關(guān)的工程技術(shù)，為了盡可能地避免人為很難發(fā)現的技術(shù)缺陷和安全風(fēng)險，最大限度地保障人民的生命財產(chǎn)安全而開(kāi)發(fā)的一個(gè)工程技術(shù)，是軟件開(kāi)發(fā)中的一個(gè)重要的組成部分。
如何通過(guò)完善的文檔資料，技術(shù)分析，測試方案，最大限度的實(shí)現測試覆蓋，并發(fā)現軟件瑕疵，是所有的軟件技術(shù)人員面臨及應思考的問(wèn)題。
參考文獻
[1]畢媛媛，陳錦平.基于模型的安全靜態(tài)檢測技術(shù)[J].硅谷，2012(08).
[2]李明，高勇.基于語(yǔ)法的軟件安全檢測[J].信息安全與通信保密，2011(06).
[3]劉東飛.故障樹(shù)分析技術(shù)在軟件測試中的運用[J].軟件導刊，2011(07).
[4]王之.參透測試技術(shù)與模型研究[J].計算機與信息技術(shù)，2011(05).
軟件安全性測試方法【2】
摘 要為了提高軟件研發(fā)的安全性，需要對軟件的安全性進(jìn)行測試，筆者根據軟件安全測試的主要內容及特征，總結出了相關(guān)的軟件安全測試的方法，為提高軟件質(zhì)量及安全性提供借鑒。
【關(guān)鍵詞】軟件 安全測試 方法 研究
軟件安全性是指在其運行的過(guò)程中，采用相關(guān)的技術(shù)方法將可能發(fā)生的風(fēng)險控制在可以接受的范圍內，避免系統發(fā)生不能接受的風(fēng)險，提高軟件系統的安全性能。
雖然作為系統不會(huì )直接威脅到人們的生命財產(chǎn)安全，但是一旦人工操作失誤也會(huì )造成危機。
例如，在運用航天軟件時(shí)，一旦飛機比預期的高度低，航天軟件就要及時(shí)發(fā)送警告，避免飛機下墜。
對軟件的安全性進(jìn)行分析測試，及時(shí)發(fā)現和排除錯誤，減少損失。
目前國內的安全軟件測試針對性不強，缺乏測試依據，需要改進(jìn)。
1 軟件安全性測試的特點(diǎn)和分類(lèi)
對軟件進(jìn)行安全測試就是看其安全特性是否和設計時(shí)要求的效果一致，包含對軟件的功能測試，驗證測試及滲透測試。
軟件安全測試有其獨特性，安全性的缺陷和普通的軟件缺陷不同，安全方面出現漏洞會(huì )使很多的用戶(hù)受到損失，注重強調軟件不應該做什么而不是強調讓軟件做什么，強調的是其否定需求，比如說(shuō)，未經(jīng)允許用戶(hù)沒(méi)有權利訪(fǎng)問(wèn)數據。
軟件安全測試可以分為兩類(lèi)，安全功能測試(Security Functional Testing)和安全漏洞測試(Security Vulnerability Testing)，前者主要從軟件功能角度出發(fā)，根據安全功能的要求測試軟件的安全性是否達標，軟件的功能要求主要有軟件的完整性、機密性、不可否認性及隱私保護等等;后者相關(guān)的漏洞測試主要站在攻擊者的層面上看，主要目標是發(fā)現軟件的安全漏洞，主要的安全漏洞包括，軟件在操作、設計、運行方面是否有漏洞或者缺陷。
因為一旦漏洞被攻擊者利用，必然使軟件處于危險狀態(tài)，所以，安全漏洞測試就是辨識軟件的缺陷及漏洞。
2 軟件測試的方法
2.1 靜態(tài)測試
在測試軟件的代碼時(shí)，并不真實(shí)運行被測試的軟件，靜態(tài)測試還經(jīng)常被應用于軟件文檔測試，比如，可以檢測或者驗證文檔，對系統軟件設計的文檔或者軟件代碼的檢查。
2.2 動(dòng)態(tài)測試
和靜態(tài)測試不同的就是需要在檢測時(shí)實(shí)際運行軟件，通過(guò)運行檢測軟件的運行情況及動(dòng)態(tài)的行為。
所以，在進(jìn)行動(dòng)態(tài)測試時(shí)，一定要運行被測試的軟件，真正輸入數據進(jìn)行驗證檢測。
2.3 功能測試
功能測試時(shí)建立在刺痛或者程序的功能上，測試的人員無(wú)需知道程序的運行過(guò)程，重點(diǎn)關(guān)注軟件程序的功能是否符合標準、規格。
2.4 結構測試
結構測試要求測試工作人員了解程序軟件的內部結構和邏輯過(guò)程，重點(diǎn)關(guān)注軟件生成的代碼，可以忽略功能測試，不關(guān)注功能是否匹配。
3 安全性測試的主要方法
3.1 形式化安全測試
形式化安全測試就是通過(guò)建立數學(xué)模型，運用形式規范的語(yǔ)言，供給軟件的說(shuō)明。
可以將這種測試方法氛圍兩類(lèi)，
3.1.1 定理證明
就是把相關(guān)的軟件程序轉變?yōu)檫壿嫻�，運用之前的理論及規則證實(shí)程序的合法性。
3.1.2 模型檢測
在描述軟件行為方面使用S代表狀態(tài)遷移系統，在描述軟件執行必須滿(mǎn)足的性質(zhì)方面用計算樹(shù)邏輯F代表，然后對S這一過(guò)程進(jìn)行自動(dòng)搜索，找到不能滿(mǎn)足F這一公式的狀態(tài)的方式發(fā)現軟件漏洞。
NASA的一個(gè)實(shí)驗室叫JPL曾經(jīng)進(jìn)行過(guò)形式化安全測試，通過(guò)建立形式化模型，比如，狀態(tài)機，對軟件進(jìn)行形式化安全測試就是通過(guò)搜索狀態(tài)空間，尋找路徑使其達到違背規約的不安全狀態(tài)，模型不斷增大，逐漸變得復雜，狀態(tài)空間也不斷增長(cháng)，JPL研發(fā)了一種方式避免狀態(tài)爆炸。
3.2 建立在模型基礎上的安全功能測試
通過(guò)對軟件的行為和機構建模，再將測試模型生成測試軟件，一般會(huì )用到的測試模型有UML模型、有限狀態(tài)機及馬爾可夫鏈等等。
Mark Blackburn、Robert Busser研發(fā)了安全功能測試，就是通過(guò)利用SCRModeling建模，運用表單的形式建立安全功能行為模型，把相應的表單模型轉化為說(shuō)明模型，運用T-VEC生成向量，包括輸入和輸出變量，研發(fā)測試驅動(dòng)模式，再將測試向量輸入測試驅動(dòng)模式，運行測試模式。
通過(guò)這種安全功能測試，能夠有效測試軟件的安全性，但是它只適用于安全功能建模能力達到一定的程度，例如，對授權、訪(fǎng)問(wèn)控制等進(jìn)行軟件應用進(jìn)行測試。
3.3 語(yǔ)法測試
這種測試方法是用來(lái)檢測軟件對各種輸入情況的反應，檢測軟件的功能接口的語(yǔ)法生成測試輸入。
接口的類(lèi)型有很多，例如，命令行、環(huán)境變量等等，接口需要已經(jīng)規定了所要求輸入的語(yǔ)法，這一語(yǔ)法對輸入的數據的格式及類(lèi)型進(jìn)行了定義。
測試的一般過(guò)程就是辨識接口的語(yǔ)法形式，據此生成測試用例，執行測試。
測試時(shí)正確、錯誤及畸形的語(yǔ)法都應該包括在測試范圍內，檢測軟件的處理情況及缺陷，語(yǔ)法測試和故障注入技術(shù)相結合效果會(huì )更好。
3.4 模糊測試
在發(fā)現軟件的安全漏洞方面，模糊測試是一種很重要的方法，它是通過(guò)將隨機的不完善的數據插入到程序中，觀(guān)測軟件程序是否能夠接受胡亂的數據輸入，模糊測試一般是不符合邏輯的，通過(guò)產(chǎn)生雜亂的數據供給程序來(lái)達到測試的目的，通過(guò)這種間接的測試方法可以可以檢測出來(lái)正常邏輯思維難以發(fā)現的安全漏洞。
4 結語(yǔ)
軟件安全測試時(shí)軟件研發(fā)過(guò)程中的重要環(huán)節，通過(guò)發(fā)現軟件之星時(shí)的故障和缺陷，及時(shí)更正，避免造成更大的破壞，軟件測試的最理想效果就是使用較少的測試用例實(shí)現較大的安全測試。
在進(jìn)行軟件安全測試前，要針對所要測試軟件的類(lèi)型，制定測試方案，分析測試結果，整理測試資料，查找漏洞。
出了筆者探討的上述安全測試方法之外，還有建立在故障注入基礎上的安全性測試方法，基于屬性的安全測試方法等。
在未來(lái)，Web服務(wù)軟件發(fā)展迅速，怎樣針對Web服務(wù)進(jìn)行安全測試是需要研究的新課題。
參考文獻
[1]陸璐，王柏勇.軟件自動(dòng)化測試技術(shù)[M].北京：清華大學(xué)出版社，2006.
[2]郭群.軟件測試設計技術(shù)[J].電腦知識與技術(shù)，2007(17).
[3]游歷貞，郭宇春，李純喜.AJAX引擎的原理和應用[J].微計算機信息，2006(22)：2-3.
[4]黃愛(ài)明.國內軟件測試現狀及對策研究[J].中國管理信息化，2007(02).
軟件安全性檢測技術(shù)【3】
摘要：該文闡述了網(wǎng)絡(luò )軟件安全檢測的重要性，介紹了現有的主要檢測方法，包括形式化安全測試、基于模型的安全功能測試、語(yǔ)法測試、基于故障注入的安全測試、基于屬性的測試、模糊測試、基于風(fēng)險的安全性測試、基于故障樹(shù)的安全性測試以及基于滲透的安全性測試。
關(guān)鍵詞：安全性檢測;功能測試;漏洞測試;安全測試方法
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)網(wǎng)普及之前，單機應用程序軟件安全問(wèn)題并不突出。
但是自從互聯(lián)網(wǎng)普及后，軟件安全問(wèn)題愈加顯加突顯，使得軟件安全性測試的重要性上升到一個(gè)前所未有的高度。
同時(shí)，隨著(zhù)軟件的廣泛應用和其規模、復雜度的不斷提高，軟件安全性問(wèn)題日益突出。
軟件安全性測試是保證軟件安全和質(zhì)量、降低軟件安全風(fēng)險的重要手段。
軟件安全性測試分為安全功能測試(Security Functional Testing)和安全漏洞測試(Security Vulnerability Testing)兩個(gè)方面，如表1所示。
表1 安全功能測試和安全漏洞測試
1 軟件安全測試的主要方法
1.1 形式化安全測試
建立軟件的數學(xué)模型，利用形式化規格說(shuō)明語(yǔ)言對其進(jìn)行說(shuō)明[1]，形式規格說(shuō)明語(yǔ)言主要包括以下幾類(lèi)[2]：
基于模型的Z、VDM和B語(yǔ)言;
基于有限狀態(tài)語(yǔ)言，如有限狀態(tài)自動(dòng)機、SDI;
代數語(yǔ)言，如OBJ;
基于行為的CSP、CCS、Petri Nets等語(yǔ)言;
混合語(yǔ)言，如離散和連續數學(xué)的規格說(shuō)明語(yǔ)言;
狀態(tài)圖
形式化安全測試方法分為定理證明和模型檢測兩類(lèi)，如表2所示。
表2 形式化安全測試方法分類(lèi)
[定理證明\&模型檢測\&將程序轉換為邏輯公式，然后使用公理和規則證明程序是否是一個(gè)合法的定理\&運用狀態(tài)遷移系統描述軟件行為，運用時(shí)序邏輯、計算樹(shù)邏輯等表示軟件執行所必須滿(mǎn)足的性質(zhì)，通過(guò)自動(dòng)搜索遷移系統中不滿(mǎn)足公式或邏輯的狀態(tài)來(lái)發(fā)現軟件漏洞\&]
形式化安全測試的特點(diǎn)是數學(xué)基礎完備，對系統理解深入。
但，開(kāi)發(fā)成本高，維護困難。
1.2 基于模型的安全功能測試
基于模型的安全性測試是通過(guò)對軟件的行為和結構進(jìn)行建模，生成測試模型，繼而由測試模型生成測試用例，當前主要的軟件測試模型有馬爾科夫模型、有限狀態(tài)自動(dòng)機模型、UML模型[3，4]等。
Nahid Shahmehri等[5]提出一種基于模型的方法，用以檢測和跟蹤運行中的軟件所存在的漏洞，這是一種被動(dòng)測試技術(shù)。
開(kāi)發(fā)者可以很容易的確切的知道工具所針對的漏洞類(lèi)型，并且當新的漏洞被發(fā)現時(shí)可以通過(guò)添加新的方法將工具進(jìn)行擴展。
檢測模型是基于安全目標模型SGMs的，它可以顯示產(chǎn)生漏洞的潛在原因，以及各種原因之間的相互關(guān)系。
SGMs和威脅樹(shù)模型非常類(lèi)似，后者是將引發(fā)某種威脅的所有因素用樹(shù)狀結構描述，前者則是將引起漏洞的所有可能原因用樹(shù)狀結構描述。
Mark Blackburn等[6]提出一種基于模型的軟件安全自動(dòng)檢測方法，該方法提供了一種端對端的模型構造、分析、自動(dòng)測試用例生成、自動(dòng)執行測試以及結果分析的綜合技術(shù)手段，該方法適用于各種環(huán)境。
該檢測方法的基礎是對安全函數說(shuō)明進(jìn)行建模，利用Oracle和Interbase數據庫引擎自動(dòng)生成模型并進(jìn)行測試。
1.3 語(yǔ)法測試
所謂語(yǔ)法就是定義了軟件接受的輸入的數據類(lèi)型和格式。
語(yǔ)法測試是根據被測軟件的功能接口的語(yǔ)法生成測試輸入，檢測被測軟件對各類(lèi)輸入的響應，通過(guò)觀(guān)察被測軟件輸入與相應之間的關(guān)系做出安全性分析[7]。
其流程如下：
語(yǔ)法測試適合對組件進(jìn)行黑盒測試[8]，根據組件接口的語(yǔ)法特征，正則表達可以產(chǎn)生正常和非正常輸入，進(jìn)而觸發(fā)各種安全問(wèn)題。
但是其缺點(diǎn)是測試樣例的數量巨大，很難保證測試覆蓋全面性。
Patrice Godefroid等[9]研究了輸入結構復雜應用程序，利用基于語(yǔ)法的方法對非法輸入進(jìn)行描述，以提高白盒測試的效果，提出了一種新的動(dòng)態(tài)測試用例生成算法。
1.4 基于故障注入的安全測試
用戶(hù)輸入、文件系統、環(huán)境變量、網(wǎng)絡(luò )接口等應用程序與環(huán)境之間的交互引起的故障均可作為注入的故障。
人為主動(dòng)的將故障引入系統，可以加速系統失效，同時(shí)也加速了對安全問(wèn)題進(jìn)行排查。
具體的方法包括仿真注入、硬件注入、軟件注入等。
Binbin Qu等[10]提出了一種基于客戶(hù)機-服務(wù)器模式的錯誤注入測試方法，用于軟件組件的安全性測試。
作者設計了了一種基于A(yíng)PI Hooking的錯誤注入工具，該工具GCDEFI是基于客戶(hù)機-服務(wù)器模式的，由一個(gè)服務(wù)端和多個(gè)客戶(hù)組成。
服務(wù)器控制客戶(hù)機，收集反饋信息并與客戶(hù)機交互;客戶(hù)機管理API攔截、錯誤信息和目標組件信息。
客戶(hù)機注入到測試驅動(dòng)，處于驅動(dòng)的地址范圍。
GCDEFI運行后，控制器從用戶(hù)得到錯誤類(lèi)型信息，該信息被保存在客戶(hù)機的錯誤管理模塊。
控制器觸發(fā)Activator，將目標組件信息送入目標組件信息管理器。
每當API被攔截，調用者的信息將被獲取，我們查找堆棧和目標組件列表，看是否有匹配的組件，如果沒(méi)有就返回，如果有就進(jìn)入替代代碼，進(jìn)而執行注入的錯誤。
客戶(hù)機中的替代函數可以與服務(wù)器通信。
該工具通用性不好，只在特定的環(huán)境對特定的組件具有較好的檢測效果。
Jinfu Chen[11]設計了一種典型的COM組件安全性測試工具――CSTS，該工具具有獲取并分析COM組件、靜態(tài)分析組件漏洞、自動(dòng)生成測試腳本、生成測試驅動(dòng)、注入環(huán)境錯誤、引導組建運行，記錄安全隱患并寫(xiě)入日志、安全評級等功能。
測試流程如下：
A.創(chuàng )建測試工程
B.選擇測試組件
C.分析接口信息
D.生成測試文件
E.編譯測試裝置
F.運行測試驅動(dòng)
G.引導運行過(guò)程
H.注入環(huán)境錯誤
I.開(kāi)始錯誤注入測試
J.結束并保存
但是該方法的風(fēng)險評級標準并不明確，有待于進(jìn)一步細化和明確。
1.5 基于屬性的測試
基于屬性的安全測試方法[12]是將確定的程序編寫(xiě)規則進(jìn)行編碼，將其作為安全屬性，以此為依據驗證程序代碼是否符合規則。
1.6 模糊測試
模糊測試是一種基于黑盒的隨機性測試，通過(guò)隨機地變異正常的程序輸入進(jìn)而檢測程序響應，以發(fā)現軟件中存在的漏洞，可用語(yǔ)法規則生成正常輸入，也可用試探法指導輸入變量的產(chǎn)生。
模糊測試的最大問(wèn)題在于代碼覆蓋率很低。
Patrice Godefroid等[13]提出了一種白盒模糊測試方法，這種方法受動(dòng)態(tài)測試用例生成方法和象征性執行方法的啟發(fā)：
A.記錄程序在正常狀態(tài)下的運行情況;
B.標記程序運行軌跡、收集輸入的限制條件;
C.將限制條件逐一取消產(chǎn)生新輸入，執行不同控制路徑;
D.在啟發(fā)式高代碼覆蓋率方法的輔助下重復上述過(guò)程，完成測試過(guò)程。
該方法的不足之處在于有限的樣本尺寸限制了代碼覆蓋率。
1.7基于風(fēng)險的安全性測試
風(fēng)險即錯誤發(fā)生的可能性以及造成的危害程度。
基于風(fēng)險的安全測試的出發(fā)點(diǎn)和依據是軟件安全風(fēng)險，把風(fēng)險分析與管理、安全測試以及軟件開(kāi)發(fā)過(guò)程系統化。
該方法具有在軟件開(kāi)發(fā)的各個(gè)階段可以把有風(fēng)險的安全漏洞考慮在內，將安全測試與軟件開(kāi)發(fā)同步進(jìn)行的優(yōu)點(diǎn)[14]。
Brad Arkin、Gary McGraw等人[15]研究了基于風(fēng)險的安全測試方法，在軟件開(kāi)發(fā)的各個(gè)階段進(jìn)行異常場(chǎng)景、誤用模式、風(fēng)險分析以及滲透測試等，其實(shí)質(zhì)是將安全測試相關(guān)過(guò)程集成到軟件開(kāi)發(fā)的整個(gè)生命周期中。
1.8 基于故障樹(shù)的安全性測試
基于故障樹(shù)的安全測試技術(shù)[16-20]是利用故障分析樹(shù)和故障樹(shù)來(lái)生成安全性測試用例的方法，故障樹(shù)(威脅樹(shù))[21]實(shí)際上是一種將系統故障(威脅)形成原因由上到下柱層細化的過(guò)程。
Huang Song[22，23]等選擇了CERT/CC的TOP 10瑕疵用來(lái)建立威脅樹(shù)以生成測試序列。
1.8.1 威脅樹(shù)
威脅樹(shù)由威脅節點(diǎn)構成，根節點(diǎn)為待檢測瑕疵，將其向下分解，生成子節點(diǎn)(即須要實(shí)現父節點(diǎn)的必要步驟)，子節點(diǎn)繼續向下分解直到無(wú)可分解)。
節點(diǎn)分與節點(diǎn)和或節點(diǎn)兩種，如圖2所示。
圖2 節點(diǎn)類(lèi)型
以SQL注入為例，其威脅樹(shù)和測試序列生成方法如下：
1.8.2 威脅樹(shù)生成方法
A.選擇一種典型瑕疵(待測瑕疵)作為根節點(diǎn);
B.分析該節點(diǎn)，并將其作為父節點(diǎn)，將其所對應的所有情況作為子節點(diǎn);標記父節點(diǎn)位與節點(diǎn)或者或節點(diǎn);
C.分解子節點(diǎn);
D.重復A-C，直到無(wú)可分解。
1.8.3 生成測試序列
圖3為SQL的注入威脅樹(shù)，其中SQL injection為與節點(diǎn)，其五個(gè)子節點(diǎn)為與關(guān)系，其中第四個(gè)節點(diǎn)為或節點(diǎn)，則其子節點(diǎn)為或關(guān)系。
其測試序列為：a-b-c-e-d和a-b-c-f-d。
目前該方法還是手動(dòng)進(jìn)行的，工作量較大，需要設計自動(dòng)化的方法才有更大的應用價(jià)值。
1.9基于滲透的安全性測試
這是一種評估網(wǎng)絡(luò )安全性和主機系統的模擬攻擊過(guò)程，安全工程師可以通過(guò)這種方式深入探測目標的安全性。
滲透測試分兩類(lèi)：被動(dòng)攻擊和主動(dòng)攻擊，被動(dòng)攻擊不直接進(jìn)入目標系統，而主動(dòng)攻擊則要直接侵入目標系統。
滲透測試步驟[24]如下所示：
Shu Xiao[25]等設計了一種用于網(wǎng)絡(luò )協(xié)議安全測試的解決方案，建立了一套完整的協(xié)議代碼健壯性評估環(huán)境。
該環(huán)境的核心測試系統包括多功能測試引擎和PDU(協(xié)議數據單元)生成工具兩部分。
其中測試引擎工作流程為，首先由預定義資源或者命令行參數來(lái)決定內部功能模塊的屬性，這些內部功能模塊包括發(fā)送接收模塊、反饋模塊、測試樣本庫模塊;然后，發(fā)送模塊從測試樣本庫獲取一個(gè)測試樣本，發(fā)送給指定的后處理單元(TCP/UDP或IP套接字)，數據被封裝;之后封裝的數據傳遞給虛擬網(wǎng)絡(luò )接口，由它發(fā)送給特定的目的單元。
與此同時(shí)，發(fā)送模塊還會(huì )通知接收單元接收同步響應消息，并將其放入響應池，然后接收模塊調用反饋模塊分析返回包，根據其做出相應的修正，來(lái)決定下一個(gè)測試樣本。
如此循環(huán)，如圖3所示。
PDU(協(xié)議數據單元)生成工具由Perl編寫(xiě)，可以由PDU模版獲取規則，由此而生成所有的測試樣本。
該系統在發(fā)現一般軟件漏洞以及對于網(wǎng)絡(luò )協(xié)議漏洞引起的問(wèn)題的異常處理是十分有效的。
適用于現代網(wǎng)絡(luò )產(chǎn)業(yè)環(huán)境中的自動(dòng)檢測。
該系統也支持同步接口錯誤注入。
作為一種非傳統測試方法，有助于生產(chǎn)更安全的軟件產(chǎn)品。
該方法具有較大的局限性，僅對TCP/IP協(xié)議漏洞檢測有效，對于其他的協(xié)議和網(wǎng)絡(luò )通訊軟件的測試還無(wú)能為力。
Csaba Nagy[26]等提出的基于輸入相關(guān)錯誤的靜態(tài)安全性分析方法是基于這樣一個(gè)思想：輸入數據是沿著(zhù)一定的路徑傳遞的，而錯誤可以出現在任何地方，但是當錯誤出現在該路徑上，它就會(huì )成為一個(gè)安全漏洞。
該方法的步驟如下：
A.找到數據輸入點(diǎn)
B.得到程序中的輸入點(diǎn)集
C.列出危險(輸入相關(guān)函數)函數列表
D.自動(dòng)檢測
該方法技術(shù)上采用了程序依存圖和系統依存圖來(lái)進(jìn)行分析，通過(guò)輸入覆蓋指標和輸入距離指標來(lái)衡量數據距離原始輸入的距離以及輸入相關(guān)函數得到輸入的位置，這兩個(gè)指標可以告訴我們哪些函數是和用戶(hù)輸入相關(guān)的。
得到這些函數后就可以進(jìn)行自動(dòng)錯誤檢測了。
1.10其他分類(lèi)方法
此外，根據測試對象的不同，軟件安全測試還可分為應用程序安全測試、操作系統安全測試、數據庫安全測試、IIS服務(wù)器安全測試、網(wǎng)絡(luò )環(huán)境安全測試。
具體如表3所示：
2 總結
軟件安全測試的實(shí)現有諸多的困難，需要測試工程師擁有高效的工具，豐富的經(jīng)驗、全面的技能，這是一個(gè)相互聯(lián)系的整體。
豐富的經(jīng)驗包括對軟件安全漏洞，以及各種黑客攻擊手段的充分了解;全面的技能包括掌握編程、網(wǎng)絡(luò )、數據庫等知識;在此基礎上方能開(kāi)發(fā)出高效的軟件安全測試工具。
參考文獻：
[1] 魏懷鑒，鮑皖蘇. 形式化方法和測試技術(shù)及其在安全中的應用[J].微計算機信息， 2006， 22(11)： 55-57.
[2] Chen H， Wagner D. MOPS： an infrastructure for examining security properties of software[C]/pic/p>
[3] Lodderstedt T， Basin D， Doser J. SecureUML： A UML-based modeling language for model-driven security[M]/pic/p>
[4] Sheng Q Z， Benatallah B. ContextUML： a UML-based modeling language for model-driven development of context-aware web services[C]/pic/p>
[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]/pic/p>
[8] Tal O， Knight S， Dean T. Syntax-based Vulnerability Testing of Frame-based Network Protocols[C]/pic/p>
[9] Godefroid P， Kiezun A， Levin M Y. Grammar-based whitebox fuzzing[C]/pic/p>
[10] Qu B， Huang Y， Xie X， et al. A Developed Dynamic Environment Fault Injection Tool for Component Security Testing[C]/pic/pic/p>
[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]/pic/p>
[14] 張澤華，饒若楠，凌君逸.基于風(fēng)險測試揭錯能力分析[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]/pic/p>
[23] Huang S， Hui Z W， Wang L， et al. A Case Study of Software Security Test Based On Defects Threat Tree Modeling[C]/pic/p>
[24] 唐秀存，杜德慧.滲透測試技術(shù)與模型研究[J].計算機與信息技術(shù)，2007(5)：33-35.
[25] Xiao S， Deng L， Li S， et al. Integrated tcp/ip protocol software testing for vulnerability detection[C]/pic/p>
[26] Nagy C， Mancoridis S. Static security analysis based on input-related software faults[C]/pic/p>
【軟件安全性測試技術(shù)】相關(guān)文章：
軟件測試實(shí)習報告01-31
軟件測試實(shí)習報告11-13
軟件測試的實(shí)習報告09-14
軟件測試報告06-17
軟件測試個(gè)人總結11-11
軟件測試技術(shù)服務(wù)合同（通用9篇）01-06
軟件測試述職報告02-22
大學(xué)軟件測試學(xué)習總結10-31