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