【正文】 = then return； end if；13. // 否則需要對參數(shù)的值進(jìn)行選擇14. for j=s+1 to do15. =；16. for 中的每一個值 do17. ={將參數(shù)的值加入到T中第j個測試用例，覆蓋的中兩兩組合}；18. if then ；； end if；19. end for20. // 用參數(shù)的值來擴(kuò)展T中第j個測試用例；21. =；22. end for；23. end for；EEC算法是需要測試用例數(shù)量最少的一種方法。產(chǎn)生的測試用例數(shù)量條。實(shí)現(xiàn)對各個參數(shù)的各種取值的覆蓋的同時，盡量考慮對各個參數(shù)之間兩兩組合的覆蓋。算法最耗費(fèi)時間的步驟在第六行偽代碼，因此可以估算算法的時間復(fù)雜度為。EEC算法產(chǎn)生測試用例的第一步將各個接口參數(shù)按照取值個數(shù)的多少進(jìn)行排序，不妨設(shè)，并按照這個次序來生成測試用例。首先生成個k元組，每個k元組中的第一個元素分別為集合中個不同的異常元素值。然后，將中的個異常元素值分別安排在這些元組的第二個位置上。當(dāng)時，這個k元組中還有個元組的第二個位置上是空的，在中選取一個元素，使之盡可能多的覆蓋和之間未被覆蓋的兩兩組合。以此類推，直到將這個k元組中所有空位置填滿，就得到一個接口方法的測試用例集。除了測試用例的構(gòu)造之外，針對被測端組件的監(jiān)控也是一個很必要的手段。監(jiān)控被測組件的目的是為了得到組件在得到特定測試用例輸入之后的運(yùn)行結(jié)果。一般來說針對安全性的黑盒測試會造成組件崩潰，或者不能正常處理輸入。文獻(xiàn)[55]和[56]都是選擇崩潰作為判斷的條件，但是在某些特殊的情況下，被測組件不一定會崩潰。這時需要對被測組件的調(diào)用序列、調(diào)用參數(shù)等細(xì)節(jié)實(shí)施進(jìn)一步的監(jiān)控和判斷。 本章小結(jié)接口是組件安全漏洞最常見的觸發(fā)渠道，針對組件接口參數(shù)進(jìn)行錯誤注入，是發(fā)現(xiàn)組件安全漏洞的最直接和有效的方法。本章選擇在組件運(yùn)行之前，對組件接口的輸入?yún)?shù)進(jìn)行“錯誤”注入，提出了一種測試組件安全漏洞的接口參數(shù)錯誤注入方法。方法借鑒于Ballista健壯性測試，以參數(shù)類型為核心，只需為每個參數(shù)類型構(gòu)建相應(yīng)的異常案例庫，就可重復(fù)利用為每一個接口方法生成測試用例。為減少測試用例，提出一種EEC測試用例生成算法，產(chǎn)生的一組測試用例首先保證對各個參數(shù)的覆蓋，同時考慮對各個參數(shù)間組合的覆蓋。704 動態(tài)環(huán)境錯誤注入方法組件執(zhí)行是一個動態(tài)的過程，僅僅利用靜態(tài)的接口錯誤注入無法發(fā)現(xiàn)組件動態(tài)運(yùn)行過程中的可能出現(xiàn)的安全漏洞，利用錯誤注入技術(shù)對正在執(zhí)行的組件環(huán)境進(jìn)行改變可以深層次地測試出組件潛在的安全漏洞。本章在EAI環(huán)境錯誤注入分析法的基礎(chǔ)之上給出一種測試組件安全漏洞的動態(tài)環(huán)境錯誤注入方法。 動態(tài)環(huán)境錯誤注入概念在本文中，動態(tài)環(huán)境錯誤注入是指在組件動態(tài)運(yùn)行時期，針對其所在的環(huán)境故意注入人為的錯誤，并驗(yàn)證組件對所注入錯誤的執(zhí)行效果的測試方法。其目的是通過盡可能多的自動擾動環(huán)境狀態(tài)來模擬對組件的影響，評估在特定地點(diǎn)一個環(huán)境狀態(tài)擾動給組件所造成的后果如何來判定它的安全與否。 動態(tài)環(huán)境錯誤注入利用動態(tài)環(huán)境錯誤注入進(jìn)行組件安全性測試有如下幾個優(yōu)點(diǎn)：首先，在實(shí)際運(yùn)行環(huán)境中，很難觸發(fā)環(huán)境中特定的異常情況，測試組件處于這些異常時的特性相當(dāng)困難。動態(tài)錯誤注入模擬環(huán)境異常可以加速測試的進(jìn)展，并且使注入的錯誤更對應(yīng)于現(xiàn)實(shí)；其次，這種方法可使模擬環(huán)境錯誤的時機(jī)選擇更加系統(tǒng)。判定組件在特定的環(huán)境錯誤下反應(yīng)是否正常需要搭建特定的環(huán)境。但是，搭建時機(jī)很難控制。如果太早，實(shí)際測試中的條件就可能改變，組件與環(huán)境的交互發(fā)生時的組件狀態(tài)就可能和期望中不符；如果太遲，則其對組件行為的影響就有可能和構(gòu)建時的目的不一致。通過實(shí)時的截獲待測組件與環(huán)境的動態(tài)交互，就能較精確的控制注入時機(jī)；最后，這種方法的實(shí)現(xiàn)過程可以實(shí)現(xiàn)自動化。 動態(tài)環(huán)境錯誤注入關(guān)鍵問題在動態(tài)環(huán)境錯誤注入中，有幾個關(guān)鍵問題需要解決：1) 錯誤模型的選擇。錯誤模型的選擇依賴于缺陷的本質(zhì)。例如，硬件缺陷導(dǎo)致的軟件錯誤通過在內(nèi)存中寫入特定的二進(jìn)制數(shù)據(jù)模擬，由于通信引起的協(xié)議實(shí)現(xiàn)錯誤則要通過消息的丟失、復(fù)制、重組或者延遲實(shí)現(xiàn)模擬?；诖耍疚倪x擇EAI模型作為動態(tài)環(huán)境錯誤注入的錯誤模型，不過在進(jìn)行具體注入測試時，針對組件需要進(jìn)行適當(dāng)?shù)牟眉簦?) 錯誤注入點(diǎn)的選擇。由于有各種各樣的漏洞缺陷，也就有了各種各樣需要注入錯誤的地方，而如何判別在某些地方注入錯誤就成為了一個關(guān)鍵性的問題。在這個方面就需要大量的資料匯總和一定的經(jīng)驗(yàn)判斷，確定錯誤注入點(diǎn)的選擇依據(jù)很多工作量；3) 注入錯誤分類匯總。錯誤注入點(diǎn)的選擇需要大量的總結(jié)，不過不單如此，即使選擇到了恰當(dāng)?shù)淖⑷朦c(diǎn)，注入的錯誤同樣是個難題，究竟什么樣的錯誤才能達(dá)到最好的測試效果，同樣是錯誤注入的難點(diǎn)。一種可行的解決方法就是通過對現(xiàn)實(shí)的大量錯誤進(jìn)行匯總和分類，總結(jié)出典型的、有針對性的錯誤類型，建立相應(yīng)的錯誤模式庫；4) 如何注入錯誤的實(shí)現(xiàn)方法。在選擇了錯誤注入點(diǎn)和注入的錯誤以后，下一個問題自然是如何在這些注入點(diǎn)注入相應(yīng)的環(huán)境錯誤，這是一個實(shí)現(xiàn)動態(tài)環(huán)境錯誤注入需要考慮的關(guān)鍵問題；5) 測試用例的生成。一個組件在運(yùn)行過程中可注入的錯誤很多，測試用例就是對這些可注入錯誤的組合，但是實(shí)際測試中的測試計(jì)算資源有限，要解決組合爆炸問題；6) 環(huán)境恢復(fù)。對于自動化的測試，環(huán)境恢復(fù)是非常重要的環(huán)節(jié)。如果不能在測試用例執(zhí)行后將環(huán)境恢復(fù)到此次測試前的狀態(tài)，則無法保證測試的正確性；7) 對違反安全策略的判定?？梢园凑瞻踩娜齻€性質(zhì)——可用性、保密性和完整性結(jié)合具體平臺的安全策略進(jìn)行判定。 基于EAI模型的動態(tài)環(huán)境錯誤注入方法 錯誤模型正如Wenliang Du et ，環(huán)境錯誤通過兩種方式影響組件。第一種方式，組件從環(huán)境接收輸入，經(jīng)過變量賦值轉(zhuǎn)化為組件內(nèi)部實(shí)體的錯誤。環(huán)境錯誤通過內(nèi)部實(shí)體間的狀態(tài)變換進(jìn)行傳播。如果組件對錯誤的處理不正確，就可能違反安全策略。這種錯誤引起的后果的過程以內(nèi)部實(shí)體為媒介，因此稱為“間接環(huán)境錯誤”；另一種方式，環(huán)境錯誤并不通過內(nèi)部實(shí)體傳播，當(dāng)組件訪問環(huán)境實(shí)體(如建立、修改、讀、寫、運(yùn)行文件)時，沒有正確處理錯誤，而立即引起對安全策略的違反，這種錯誤稱為“直接環(huán)境錯誤”。 組件環(huán)境交互錯誤模型針對組件動態(tài)環(huán)境錯誤注入而言。組件在運(yùn)行過程中，主要訪問以下五類環(huán)境實(shí)體：磁盤文件、目錄、注冊表、外部dll和網(wǎng)絡(luò)。選擇注入的錯誤主要是直接環(huán)境錯誤，這是基于以下二點(diǎn)考慮：1) 間接環(huán)境錯誤中的主要類別是用戶輸入錯誤，然而對組件而言，接口是用戶輸入的唯一渠道，用戶輸入對應(yīng)的就是組件接口調(diào)用，關(guān)于組件接口調(diào)用的錯誤注入，本文第三章已給出了基于Ballista的接口參數(shù)錯誤注入方法；2) 直接環(huán)境錯誤的注入可以通過對系統(tǒng)調(diào)用的參數(shù)的分析自動進(jìn)行，而各個間接環(huán)境缺陷之間的關(guān)聯(lián)不大，通常使用手工分析即可，因此集中于相關(guān)性強(qiáng)的直接環(huán)境缺陷注入有利于發(fā)揮自動化測試系統(tǒng)的長處。 注入點(diǎn)和對應(yīng)注入錯誤注入錯誤的有效性取決于它與現(xiàn)實(shí)系統(tǒng)中環(huán)境與應(yīng)用接口上發(fā)生錯誤的相似度如何，如果相似度大，就可以認(rèn)為，注入的錯誤所引起的安全策略的違反同樣可能在現(xiàn)實(shí)環(huán)境中以相同的次序發(fā)生，從而表明了被測組件存在安全漏洞。在實(shí)踐中，很難觸發(fā)某些異常環(huán)境，知道如何觸發(fā)依賴于安全分析人員的有關(guān)“環(huán)境”方面的知識。在異常的環(huán)境下測試組件安全變的非常困難。錯誤注入技術(shù)提供了一種模擬異常環(huán)境的方法，而不必考慮在實(shí)踐中異常環(huán)境是如何存在的。在此環(huán)節(jié)按照以上錯誤模型，并結(jié)合漏洞數(shù)據(jù)庫中錯誤環(huán)境的分析[52, 57]，構(gòu)造具有針對性的環(huán)境注入錯誤。 注入點(diǎn)和對應(yīng)注入錯誤 未經(jīng)測試的代碼常會導(dǎo)致安全漏洞。許多安全漏洞都是發(fā)生在“有敵意的壓力”環(huán)境下[58]，在測試過程中最容易忽視的代碼路徑是異常處理，有錯誤的異常處理是組件安全漏洞存在的一個主要原因。因此動態(tài)環(huán)境錯誤注入應(yīng)該盡可能多地對組件進(jìn)行安全壓力測試[59]，對其嘗試注入各種可能的環(huán)境錯誤，從而達(dá)到測試出組件安全漏洞的目的。對組件模擬如下五類有針對性的“錯誤和異常處理測試”：(1) 內(nèi)存錯誤。主要是限制組件訪問的內(nèi)存大小、低內(nèi)存注入、內(nèi)存訪問控制、內(nèi)存出錯等內(nèi)存相關(guān)的模擬錯誤注入。強(qiáng)迫組件在低內(nèi)存和磁盤空間下工作，剝奪資源以檢測在壓力條件下的安全性；(2) 磁盤或文件系統(tǒng)相關(guān)錯誤。主要是限制對文件的讀寫訪問、文件損壞、目錄損壞、磁盤寫保護(hù)等文件系統(tǒng)相關(guān)的模擬錯誤注入。強(qiáng)迫組件在訪問文件出現(xiàn)異常的情況下，能正確處理而不出現(xiàn)不安全的行為；(3) 注冊表相關(guān)錯誤。主要有惡意修改注冊表信息、拒絕修改、認(rèn)證、加密等相關(guān)錯誤注入。注冊表通常是假定受到信任的，在讀取注冊表值的時候，總是認(rèn)為正確和沒有被惡意篡改的，總是未受保護(hù)地存儲在注冊表中； (4) 調(diào)用外部進(jìn)程/dll錯誤。主要是阻止加載、拒絕訪問外部進(jìn)程或函數(shù)庫模擬錯誤注入。組件執(zhí)行依賴于外部函數(shù)庫或服務(wù)組件，通過拒絕加載一個函數(shù)庫，剝奪組件期望的某些功能，確保調(diào)用故障不會使組件安全受到影響；(5) 網(wǎng)絡(luò)錯誤。主要是在網(wǎng)絡(luò)線路及網(wǎng)絡(luò)組件上進(jìn)行模擬錯誤注入，如網(wǎng)絡(luò)斷線、拒絕服務(wù)、服務(wù)延時、網(wǎng)絡(luò)擁塞等相關(guān)錯誤注入。強(qiáng)迫組件在與網(wǎng)絡(luò)交互的過程中出現(xiàn)故障，如果組件沒有對這些故障正確反應(yīng)可能會導(dǎo)致DOS攻擊。 注入錯誤實(shí)現(xiàn)方法在解決了錯誤注入點(diǎn)和注入錯誤類型的選擇以后，下一個問題是如何在這些注入點(diǎn)注入錯誤。本文采用的方法是通過截獲由組件發(fā)起的操作系統(tǒng)調(diào)用并把錯誤注入到操作系統(tǒng)調(diào)用中實(shí)現(xiàn)。 環(huán)境錯誤注入實(shí)現(xiàn)錯誤注入點(diǎn)位于待測組件與系統(tǒng)環(huán)境的交互之處，也就是組件進(jìn)行系統(tǒng)調(diào)用的地方。因此，通過API截獲將組件中的系統(tǒng)調(diào)用的名字替換為指向偽函數(shù)庫中具有相同原型的偽函數(shù)，并在組件驅(qū)動程序運(yùn)行時將組件與偽函數(shù)庫鏈接。這樣每當(dāng)組件試圖調(diào)用目標(biāo)系統(tǒng)API時，控制流實(shí)際上就轉(zhuǎn)入了偽函數(shù)庫的偽函數(shù)中，具體的錯誤注入、檢測等操作則在偽函數(shù)中完成。在偽函數(shù)內(nèi)部，環(huán)境錯誤注入可以先對截獲到的參數(shù)進(jìn)行預(yù)處理，如查看API調(diào)用參數(shù)信息，注入錯誤參數(shù)數(shù)據(jù)動態(tài)改變組件執(zhí)行流程，然后調(diào)用API函數(shù)完成系統(tǒng)功能調(diào)用；也可以先調(diào)用API函數(shù)，再對API函數(shù)的返回結(jié)果做進(jìn)一步的處理，如返回一個畸形的數(shù)據(jù)；也可以不調(diào)用而直接返回一個系統(tǒng)調(diào)用失敗等等。 DSW測試用例生成算法環(huán)境錯誤注入中的測試用例是在一次測試中對組件注入環(huán)境錯誤的有序集合。假設(shè)組件C與環(huán)境的所有交互點(diǎn)即系統(tǒng)調(diào)用的調(diào)用集，每個交互點(diǎn)的環(huán)境錯誤集，S操作的實(shí)體集。如果不加區(qū)別地對其任意組成產(chǎn)生測試用例，則測試用例的個數(shù)將達(dá)到。利用API截獲技術(shù)，對Windows平臺上大量第三方COM組件中系統(tǒng)調(diào)用的次數(shù)進(jìn)行統(tǒng)計(jì)，平均達(dá)到10次左右，以一個系統(tǒng)調(diào)用平均注入5個錯誤計(jì)算，測試用例的規(guī)模大約就是，這種組合爆炸在實(shí)際測試中是無法忍受的。因此，必須找到削減測試用例集和確定測試用例執(zhí)行順序的有效算法。1) 基于操作實(shí)體的測試用例分劃削減測試用例規(guī)模的主要方法是對組件中的系統(tǒng)調(diào)用進(jìn)行分劃，這種分劃的依據(jù)是組件中系統(tǒng)調(diào)用操作的環(huán)境實(shí)體不盡相同。假設(shè)已知所有調(diào)用的操作實(shí)體，那么就把操作相同環(huán)境實(shí)體的調(diào)用作為單獨(dú)的集合從調(diào)用集中分離出來，形成S的一個k分劃，且滿足，令g：S→O為將調(diào)用映射為其所操作實(shí)體的函數(shù)，則每個子集Si，滿足。根據(jù)這個分劃分兩步完成測試用例的生成：Step1. 對每個分劃子集Si的元素進(jìn)行錯誤和無錯誤組合，得到的測試用例集的大小為：，其中表示的元素個數(shù)；Step 2. 針對錯誤類型“是否為符號鏈接”將各分劃子集的大小與除本子集之外的操作實(shí)體數(shù)之積求和，得到：。最后得到的測試用例大小為：，顯然遠(yuǎn)遠(yuǎn)小于。此算法的根據(jù)是：在一般情況下，一個組件里操作的實(shí)體之間關(guān)聯(lián)性不大，也就是說，可認(rèn)為對一個實(shí)體進(jìn)行錯誤注入和對另一個實(shí)體進(jìn)行錯誤注入是相互獨(dú)立的，因此分別對每個分劃子集生成測試用例集，在這些測試用例執(zhí)行時，只有一個操作實(shí)體被注入錯誤，別的操作實(shí)體被組件正常讀寫，這一步得到的結(jié)果就是T1；但是另一方面，有一種錯誤可能使操作實(shí)體間產(chǎn)生關(guān)聯(lián)，這就是錯誤類型“是否為符號鏈接”，因此只對這種錯誤組合各分劃子集，就得到T2，兩者相加，即得測試用例集合得最終大小。2) 基于錯誤威脅權(quán)值和調(diào)用模式的測試用例執(zhí)行排序雖然通過分劃減小了測試用例集的規(guī)模，但是在實(shí)際測試中產(chǎn)生的測試用例集依然較大，執(zhí)行測試用例的順序因此也變得相當(dāng)重要。因?yàn)槿绻@種順序能夠反映測試用例造成安全策略違反的可能性的遞減，測試過程就有可能在盡量短得時間內(nèi)觸發(fā)組件存在的安全漏洞。采用兩種相關(guān)的算法對其定序。需要指出的是，在定序算法中有相當(dāng)?shù)慕?jīng)驗(yàn)和統(tǒng)計(jì)因素。第一步是確定單個分劃子集中的測試用例次序。根據(jù)經(jīng)驗(yàn)和統(tǒng)計(jì)數(shù)據(jù)[60]，將所有的不同系統(tǒng)調(diào)用按威脅大小確定其權(quán)值()。有兩種情況只注入單個錯誤：一種是只有一個系統(tǒng)調(diào)用；另一種是在組合錯誤中只對一個交互點(diǎn)注入錯誤，其他交互點(diǎn)不注入錯誤。在只注入單個錯誤的測試用例中，威脅權(quán)值決定了測試用例的執(zhí)行次序。接下來根據(jù)“調(diào)用模式”確定注入多個錯誤的測試用例的次序。首先把系統(tǒng)調(diào)用分為讀調(diào)用和寫調(diào)用。所謂讀調(diào)用，就是對環(huán)境實(shí)體的內(nèi)容以及相關(guān)屬性進(jìn)行查詢，并不對其改寫，典型的是Read和Access；而寫調(diào)用則造成實(shí)體內(nèi)容以及相關(guān)屬性的改變，典型的是Write和Set；但是類似Open這種“打開”調(diào)用應(yīng)從對其操作客體相關(guān)的操作序列進(jìn)行分析，如果序列中只含有諸如Read的讀操作，那么這個Open就是讀調(diào)用，反之則為寫調(diào)用。 系統(tǒng)調(diào)用威脅權(quán)值(15)及讀寫分類根據(jù)對己知安全性的分析，易出問題的調(diào)用模式是一個讀調(diào)用緊接一個寫調(diào)用，因此，將讀調(diào)用集合中的元素與寫調(diào)用中的元素進(jìn)行組合，且威脅權(quán)值之和較高的組合優(yōu)先執(zhí)行，這就是多個錯誤的測試用例生成次序。在以上的論述中，一直假設(shè)己知所有調(diào)用的操作客體，由此得到對調(diào)用集的分劃。但是在實(shí)際的測試過程中，操作客體集在動態(tài)環(huán)境錯誤注入之前是未知的。由此，測試前需要運(yùn)行組件并通過注入點(diǎn)，也就是偽函數(shù)得到分劃。把這種測試前組件的運(yùn)行過程稱為收集(gleaning)。gleaning過程對調(diào)用序列的提取存在幾個問題：首先，一般情況下，動態(tài)運(yùn)行組件無