本科畢業(yè)設計-基于錯誤注入的組件安全性測試研究

[60]，將所有的不同系統(tǒng)調用按威脅大小確定其權值(見表4.2)。有兩種情況只注入單個錯誤：一種是只有一個系統(tǒng)調用；另一種是在組合錯誤中只對一個交互點注入錯誤，其他交互點不注入錯誤。在只注入單個錯誤的測試用例中，威脅權值決定了測試用例的執(zhí)行次序。接下來根據“調用模式”確定注入多個錯誤的測試用例的次序。首先把系統(tǒng)調用分為讀調用和寫調用。所謂讀調用，就是對環(huán)境實體的內容以及相關屬性進行查詢，并不對其改寫，典型的是Read和Access；而寫調用則造成實體內容以及相關屬性的改變，典型的是Write和Set；但是類似Open這種“打開”調用應從對其操作客體相關的操作序列進行分析，如果序列中只含有諸如Read的讀操作，那么這個Open就是讀調用，反之則為寫調用。對系統(tǒng)調用的讀寫分類也列在表4.2中。表STYLEREF1\s4.2系統(tǒng)調用威脅權值(1-5)及讀寫分類根據對己知安全性的分析，易出問題的調用模式是一個讀調用緊接一個寫調用，因此，將讀調用集合中的元素與寫調用中的元素進行組合，且威脅權值之和較高的組合優(yōu)先執(zhí)行，這就是多個錯誤的測試用例生成次序。在以上的論述中，一直假設己知所有調用的操作客體，由此得到對調用集的分劃。但是在實際的測試過程中，操作客體集在動態(tài)環(huán)境錯誤注入之前是未知的。由此，測試前需要運行組件并通過注入點，也就是偽函數(shù)得到分劃。把這種測試前組件的運行過程稱為收集(gleaning)。gleaning過程對調用序列的提取存在幾個問題：首先，一般情況下，動態(tài)運行組件無法將組件中的調用完全遍歷一遍，只能提供其中的一個子集。有兩種選擇，一是將gleaning提供的調用序列作為事實上的調用，把除此之外組件代碼中其他的調用排除在測試用例之外，一是測試用例中仍然保留所有的調用，但是與之相關的測試用例不用上面提出的算法產生，仍舊使用不帶啟發(fā)算法的組合生成。考慮到gleaning過程基本上代表了組件的一般行為gleaning沒有遍歷的調用在組件的以后運行中不執(zhí)行的概率還是相當大的，并且排除一些調用可以減少測試用例。測試系統(tǒng)中采取了前一種方案。此外，由于阻塞組件不能立即結束，gleaning過程只能待續(xù)設定的一段時間，因此，得到的調用序列也只能是代碼中所有調用的子集，對此以相同的方法解決，即測試用例中的調用集以gleaning中出現(xiàn)的為準。以上確定了單個分劃子集中的測試用例生成次序，再考慮到一個組件中由于操作客體集的相互鏈接造成對安全策略的違反的概率較大，給出最終的分劃和權值排序(DivisionandSortingbyWeight,簡稱DSW)測試用例生成算法。算法4.1DSW測試用例生成算法輸入：環(huán)境錯誤注入表(如表4.1)，系統(tǒng)調用威脅權值和讀寫分類表(如表4.2)輸出：生成動態(tài)環(huán)境錯誤注入的測試用例集T步驟：//第一步：確定操作客體集O以及調用分劃Sfori=1tondo通過的參數(shù)判定操作的環(huán)境實體，記為；forj=1todoif()then；break；endif；endforif()then；；endif；endfor//第二步：生成測試用例集T1和T2，；；fori=1tokdo，其中；通過環(huán)境錯誤注入表找到對應的錯誤注入集，記為；假設代表無錯誤，；fori=1tomdoif(符號鏈接錯誤)then{符號鏈接于實體}；{當時，；否則}；endif；；endforendfor//第三步：在T1和T2中進行排序；；，；//取出注入單個錯誤的測試用例，按威脅權值排序fori=1tondoif(注入錯誤數(shù)==1)then通過系統(tǒng)調用威脅權值和讀寫分類表找到對應的權值；forj=1tokdo為中第j個測試用例對應的威脅權值；if()then將插入到中第j個位置；break；endif；endforif()then將插入到中第個位置；endif；；；；endif；endfor//注入操作客體集的相互鏈接錯誤的測試用例；//取出既包含讀調用也包含寫調用的測試用例，按調用數(shù)量從少到多排好，其中相同調用數(shù)量相同的根據威脅權值之和大小排序fori=1tondo通過系統(tǒng)調用威脅權值和讀寫分類表計算讀寫調用數(shù)量；if()thenforj=1todo為中第j個測試用例的讀寫調用數(shù)量；if()then將插入到中第j個位置；break；endif；if()then分別計算、威脅權值之和，得到和；if()then將插入到中第j個位置；break；else將插入到中第個位置；break；endif；endif；endforif()then將插入到中第個位置；endif；endif；endfor//缺少讀調用或者缺少寫調用的測試用例不分次序列在最后；根據“基于操作實體的測試用例分劃”中的分析，DSW算法產生的測試用例數(shù)為。算法首先通過分劃減小了測試用例集的規(guī)模，然后采用兩種相關的算法對其定序，使測試用例按照造成安全策略違反的可能性遞減的順序排列。第一步的時間復雜度為，n為系統(tǒng)調用數(shù)；第二步得到測試用例集的大小為：，測試用例集的大小為；第三步為插入排序，在最壞情況下，時間復雜度為第二步得到的測試用例數(shù)平方。因此，總的時間復雜度近似為：。違反安全策略監(jiān)測和環(huán)境恢復可以把組件對安全策略的違反分為“局部違反”和“全局違反”。局部違反包括組件崩潰、掛起、潛伏和其他特定于組件功能的異常情況；全局違反是對系統(tǒng)全局安全環(huán)境的破壞，比如關鍵文件的破壞、信息泄漏等。判定這兩種違反是個復雜的問題，有時候缺少人工檢測就無法判別。因此，測試系統(tǒng)中預先設定一組一般安全規(guī)則，將可自動判斷的情況包含在內，然后，由分析人員制訂依賴于特定組件功能的安全規(guī)則，這兩種安全規(guī)則組成了對組件是否違反安全策略的判據。與通常的組件測試不同，在安全性測試中，完成一個測試用例的執(zhí)行后，執(zhí)行環(huán)境應該恢復為此測試用例執(zhí)行前的狀態(tài)，否則測試用例之間就無可比性，測試結果也缺乏準確性。但是，對系統(tǒng)進行整體備份又顯然不現(xiàn)實。這里采用的方法是“按需備份”。即對組件中操作的客體進行備份，不備份系統(tǒng)中其他客體，而且，并不是對所有訪問的文件進行備份，而只保存寫調用的操作客體，而讀調用的操作客體就無需保存。本章小結環(huán)境是漏洞攻擊者所竭力利用的地方，針對組件環(huán)境進行動態(tài)的錯誤注入，是發(fā)現(xiàn)組件潛在安全漏洞的一種現(xiàn)實而又有效的方法。本章選擇在組件運行之時，對組件運行的環(huán)境故意注入人為的錯誤，在WenliangDuetal.的EAI模型的基礎上，提出了一種檢測組件安全漏洞的動態(tài)環(huán)境錯誤注入方法。首先從整體出發(fā)，介紹了動態(tài)環(huán)境錯誤注入的概念和所要解決的關鍵問題。然后圍繞所要解決的關鍵問題，分五個要點進行了詳細論述。為了解決實際測試中的“組合爆炸”問題，提出了一種DSW測試用例生成算法，有效地約減了測試用例。在理論的基礎上，下面一章將從實踐的角度給出本文第三章和本章方法的一種實現(xiàn)。CSTS中錯誤注入子系統(tǒng)實現(xiàn)在目前的Windows操作系統(tǒng)平臺上，基于微軟COM(ComponentObjectModel，組件對象模型)標準的組件是最為普遍的組件。隨著網絡技術的飛速發(fā)展，COM到目前已經歷了OLE(ObjectLinkingandEmbedding，對象鏈接和嵌入)、ActiveX技術和.NET平臺上.NET組件的發(fā)展過程，其間爆發(fā)各種各樣的COM組件安全漏洞。組件安全測試系統(tǒng)CSTS概述CSTS(ComponentSecurityTestingSystem)是一個組件安全性測試原型系統(tǒng)所實現(xiàn)的自動化測試工具。CSTS是在基于錯誤注入測試方法和動態(tài)監(jiān)測測試方法的基礎上對組件從靜態(tài)和動態(tài)兩個級別進行安全性測試。在靜態(tài)級別上，先分析出組件接口信息，然后對方法參數(shù)從參數(shù)個數(shù)、參數(shù)順序、參數(shù)范圍和參數(shù)類型等方面進行錯誤注入，注入錯誤測試用例后再編譯執(zhí)行，觀察組件運行狀態(tài)；在動態(tài)級別上，先執(zhí)行測試驅動，然后對組件所依賴的環(huán)境進行錯誤注入，主要從內存、磁盤文件系統(tǒng)、注冊表、進程及網絡五個方面進行錯誤注入，在組件測試驅動執(zhí)行的同時進行動態(tài)監(jiān)測。圖5.1是CSTS系統(tǒng)的總體結構圖。CSTS是在WindowsXP平臺上用VisualStudio.NET2005C#開發(fā)的一個針對COM組件安全性測試的集成測試系統(tǒng)原型，主要包含以下主要功能：(1)對COM組件進行接口分析，得到必要的類型信息；(2)自動生成組件方法級的測試程序，通過進一步生成接口方法測試用例實現(xiàn)接口參數(shù)錯誤注入測試；(3)編譯測試程序，生成組件測試驅動；(4)對被驅動運行中的COM組件進行動態(tài)環(huán)境錯誤注入測試；(5)動態(tài)監(jiān)測被測試COM組件的運行情況，記錄組件異常行為，并寫入日志文件；(6)COM組件安全評估與分析。圖STYLEREF1\s5.SEQ圖表\*ARABIC\s11CSTS系統(tǒng)總體結構圖對測試系統(tǒng)的一個重要的要求是自動化，不能實現(xiàn)自動化的測試技術妨礙了軟件項目運行周期的流水線推進，而且大大增加了測試成本，因此CSTS設計運行以全自動化或者僅需少量人工操作的方式進行。其中自動化包括：(1)組件自動化測試框架，包括自動生成接口測試用例，自動驅動運行，自動返回測試結果；(2)自動進行接口靜態(tài)錯誤注入和環(huán)境動態(tài)錯誤注入；(3)自動的COM組件運行時動態(tài)監(jiān)視，監(jiān)視組件的行為和狀態(tài)，一旦出現(xiàn)違反安全的異常行為，則證明組件存在安全漏洞；(4)自動安全性測試有效性評估，組件運行完畢自動評估組件的安全性程度和錯誤注入的有效程度。CSTS功能模塊CSTS系統(tǒng)主要功能由五個功能子系統(tǒng)完成：接口分析、測試用例生成、自動編譯、錯誤注入和動態(tài)監(jiān)測。在CSTS系統(tǒng)中進行COM組件安全測試時各模塊協(xié)作過程如圖5.2所示。接口分析對于第三方COM組件，其源代碼不可知，測試前必須通過一定的手段得到構圖STYLEREF1\s5.SEQ圖表\*ARABIC\s12CSTS系統(tǒng)中進行測試時各模塊協(xié)作過程示意圖件的類型信息。CSTS系統(tǒng)中通過分析組件類型信息(TypeInfo)得到組件的接口方法等詳細信息。類型庫(TypeLibrary)包含COM組件所暴露接口的二進制描述信息。它們包含的信息與IDL(接口定義語言)文件的基本相同。類型庫可以是單獨的二進制文件(.tlb)，也可以是動態(tài)鏈接庫或可執(zhí)行文件(.dll，.olb，.exe)中的資源。通過分析類型庫可以獲得以下信息：類型庫名稱和版本信息；類型信息個數(shù)；每個類型信息的接口類型(如CoClass、Interface、Dispatch等)、函數(shù)個數(shù)及變量個數(shù)；函數(shù)名、返回值類型、標志位、調用類型(如function、get、put等)、參數(shù)個數(shù)、可選參數(shù)個數(shù)、參數(shù)名、參數(shù)類型和參數(shù)方向。以上分析得到的信息均同時存儲在預先定義的XML格式文件中。測試用例生成根據接口分析模塊產生的XML文件，生成測試用例模塊所需要的測試程序(CS測試文件)。主要實現(xiàn)步驟是：使用XPath技術讀取接口信息XML文件；根據XML文件，利用CodeDom技術生成測試程序文件；根據組件安全需求說明得到組件接口方法中的初始參數(shù)。自動編譯自動編譯模塊主要完成把待測試COM組件、測試用例文件和相關程序集(dll格式)自動編譯成動態(tài)鏈接庫文件(dll格式)，供驅動程序調用。實現(xiàn)功能：通過讀取配置文件config.xml獲取指定位置的COM組件和COMTLB文件，完成COM組件注冊；選擇測試用例程序(程序類型為cs格式)及相關程序集(dll格式)，編譯生成可執(zhí)行的動態(tài)鏈接庫文件，用于驅動器調用執(zhí)行。錯誤注入錯誤注入模塊主要完成從靜態(tài)和動態(tài)兩個級別上對待測COM組件進行錯誤注入，以測試待測COM組件在運行的過程中是否出現(xiàn)違反安全的異常行為。實現(xiàn)功能：接口參數(shù)錯誤注入和動態(tài)環(huán)境錯誤注入(下文詳述)。動態(tài)監(jiān)測動態(tài)監(jiān)測模塊主要利用Windows操作系統(tǒng)中調試API技術獲得對測試驅動的控制，從而對其運行狀態(tài)進行監(jiān)測。實現(xiàn)的主要功能有：監(jiān)測組件函數(shù)運行時的堆棧值（函數(shù)的輸入參數(shù)）；在函數(shù)運行結束時的堆棧值（函數(shù)的輸出參數(shù)）；CPU寄存器的值（函數(shù)返回值）?；驹恚涸讷@取組件函數(shù)的入口地址后，在函數(shù)入口上設置斷點；當程序調用了設置斷點的函數(shù)時便會產生調試中斷事件，進一步可暫停目標程序的運行，讀取目標程序內存；最終獲得目標程序內存中希望得到的信息。測試系統(tǒng)CSTS根據狀態(tài)監(jiān)測日志中的組件狀態(tài)信息及其相關異常信息識別組件是否存在安全漏洞。錯誤注入子系統(tǒng)設計系統(tǒng)總體流程在CSTS中，根據COM組件的特點，系統(tǒng)采用靜態(tài)接口參數(shù)錯誤注入和動態(tài)環(huán)境錯誤注入實施錯誤注入，以測試COM組件的安全性。其總體錯誤注入流程如圖5.3所示：圖STYLEREF1\s5.SEQ圖表\*ARABIC\s13CSTS錯誤注入流程首先，通過COM接口分析自動得到COM組件對象、接口、方法及方法參數(shù)等必要的錯誤注入測試信息，然后對組件方法進行靜態(tài)的“接口錯誤注入”，自動生成TestFixture(包含測試用例的測試文件)，將測試文件和必要的條件引用進行自動編譯鏈接，生成可執(zhí)行的TestFixture(測試驅動可以識別的DLL文件)。接著，驅動組件運行起來，在組件運行的過程當中，同時對組件的運行環(huán)境進行動態(tài)的“環(huán)境錯誤注入”，并監(jiān)視組件的行為是否出現(xiàn)異常。最后，對測試的結果進行分析，判定是否出現(xiàn)安全漏洞。其中，靜態(tài)接口錯誤注入和動態(tài)接口錯誤注入是兩個相互獨立的過程，可以將靜態(tài)接口錯誤注入和動態(tài)環(huán)境錯誤注入分開測試，也可以貫穿于一個測試流程當中，并且可以對靜態(tài)接口錯誤注入生成的測試用例手工修改或添加新的測試用例。系統(tǒng)結構和功能錯誤注入子系統(tǒng)是CSTS的一個重要組成部分。按照錯誤注入的總體流程，CSTS錯誤注入子系統(tǒng)的結構設計如圖5.4所示。圖STYLEREF1\s5.SEQ圖表\*ARABIC\s14錯誤注入子系統(tǒng)結構圖根據系統(tǒng)功能要求錯誤注入子系統(tǒng)包含以下兩個功能模塊：(1)接口參數(shù)錯誤注入對接口錯誤注入，基于的是現(xiàn)有的Ballista方法，即對接口方法的參數(shù)進行錯誤注入，以參數(shù)類型為核心預先構造無效的、畸形的異常參數(shù)案例庫，對接口方法的參數(shù)類型、參數(shù)順序、參數(shù)個數(shù)、輸入值、輸出值進行“轟炸”，觸發(fā)組件內部的安全漏洞通過接口爆發(fā)出來。(2)動態(tài)環(huán)境錯誤注入對運行時的組件，從內存、磁盤系統(tǒng)、進程、網絡及注冊信息等相關環(huán)境進行錯誤注入。在組件被驅動運行時錯誤注入模塊根據錯誤注入的類型在進程中對組件和操作系統(tǒng)交互的相應API進行攔截。采用的技術是用預先定義的偽DLL替換系統(tǒng)DLL。根據環(huán)境錯誤注入測試要求，預先編寫一些同名的偽DLL用于替換原來的系統(tǒng)DLL。根據錯誤注入類型，對于不需要攔截的API函數(shù)直接把參數(shù)傳遞給系統(tǒng)DLL對應的API函數(shù)處理并返回結果。對需要攔截的API，則在偽DLL中添加攔截代碼進行攔截，同時注入錯誤。系統(tǒng)實現(xiàn)關鍵技術實現(xiàn)組件動態(tài)環(huán)境錯誤注入，關鍵是要對選定的環(huán)境錯誤注入點，即組件和操作系統(tǒng)交互的相應系統(tǒng)API調用進行截獲。這里針對COM組件，需要對Win32API系統(tǒng)調用進行截獲。實施Win32API系統(tǒng)調用截獲的過程主要分兩個方面：根據CSTS中選擇的錯誤注入類型，查找到需要截獲的系統(tǒng)API，對組件驅動進程中所調用的這些API進行攔截，將其替換為指向中間偽函數(shù)；為防止將環(huán)境錯誤也注入到驅動進程中，在偽函數(shù)中需要對調用該API的對象進行判斷，如果是待測COM組件則進行錯誤注入，否則調用原系統(tǒng)API。圖STYLEREF1\s5.SEQ圖表\*ARABIC\s15Win32API截獲原理圖5.5描述了Win32API截獲原理。其原理可以描述如下：在驅動進程中，需要調用三個系統(tǒng)API函數(shù)S1、S2、S3，并假定S1、S3是一次環(huán)境錯誤注入中要截獲的系統(tǒng)API。編一個偽DLL包含兩個偽函數(shù)forgeS1和forgeS3(與S1、S3有相同的原型)。其中，驅動進程的IAT(ImportAddressTable，導入地址表)保存了其導入系統(tǒng)函數(shù)S1、S2、S3的地址。通過修改驅動進程中IAT表中S1、S3的入口地址使其分別指向偽函數(shù)forgeS1和forgeS3，這樣每當驅動進程調用S1、S3時，實際調用的卻是偽函數(shù)forgeS1和forgeS3，這樣就實現(xiàn)了對S1、S3的攔截。在偽函數(shù)forgeS1、forgeS3中進一步對調用者進行判斷，因為驅動進程中除了待測COM組件調用系統(tǒng)函數(shù)S1、S3外有可能還有其他調用者，如果調用者是待測COM組件，則實施環(huán)境錯誤注入，否則轉向正常調用系統(tǒng)函數(shù)S1和S3。這樣就實現(xiàn)了COM組件對系統(tǒng)API調用的截獲。當需要恢復COM組件對系統(tǒng)函數(shù)S1和S3的調用時，只需將驅動進程IAT中指向偽函數(shù)forgeS1和forgeS3的指針替換回指向S1和S3的指針即可。1)通過改變導入地址表攔截API調用在尋找針對API函數(shù)的調用點時，必須知道驅動進程空間中內容的排列方式。在Win32操作系統(tǒng)中，進程空間中的內容及其排列方式由與該進程對應的EXE文件決定。EXE文件不但包含了進程的可執(zhí)行代碼和數(shù)據，同時也詳細地記錄了進程所引用到的所有DLL和外部函數(shù)的信息。所以，可以根據EXE文件的格式來尋找針對目標函數(shù)的調用點。Win32操作系統(tǒng)中的EXE文件和DLL文件都屬于PE(PortableExecutable)格式。PE文件格式定義了若干個數(shù)據結構，分別用于保存文件的代碼、數(shù)據和輸入輸出函數(shù)等信息，利用這些結構可以很容易地對PE文件進行操作(如圖5.6所示)。PE文件的主體是若干個文件節(jié)，其中有一個稱為.idata的節(jié)，專門用于保存EXE文件從DLL中引入的所有外部函數(shù)的信息，包括調用點的信息，所以，可以根據這個節(jié)的格式，并結合API函數(shù)的調用方式，來尋找并替換針對目標函數(shù)的調用點。圖STYLEREF1\s5.SEQ圖表\*ARABIC\s16PE文件結構當程序調用某外部函數(shù)時，它并非是從調用處直接跳轉到函數(shù)入口處，而是先統(tǒng)一跳轉到一個共同的中間點，那里保存著一行CALLDWORDPTR[XXXXXXXX]形式的指令，XXXXXXXX就是IAT中與調用函數(shù)相對應的函數(shù)指針。因此，尋找針對API函數(shù)的調用點時，首先根據API函數(shù)所在DLL的名稱，從.idata節(jié)的結構體數(shù)組中找到與該DLL對應的結構體，然后再根據API函數(shù)的名稱，可以在與該DLL對應的IAT中找到與API函數(shù)對應的函數(shù)指針。因為所有對API函數(shù)的調用都將根據該處的指針來跳轉到API函數(shù)，所以，修改該指針，將其改變?yōu)橹赶騻魏瘮?shù)的指針，便實現(xiàn)了用偽函數(shù)替換API函數(shù)。在恢復時，執(zhí)行同樣的步驟，將指向偽函數(shù)的指針替換回指向API函數(shù)的指針即可。另外，需要改寫的

.idata

節(jié)不一定都是可寫的，可以調用系統(tǒng)函數(shù)VirtualProtect(…)

來實現(xiàn)。2)利用“鉤子”技術注入偽DLLWin32操作系統(tǒng)實行了“進程地址空間分離”的機制，每個進程有自己獨立的地址空間，所以CSTS主進程不能直接訪問驅動進程空間中的內容，不能直接在驅動進程空間中尋找針對系統(tǒng)API函數(shù)的調用點，因此必須設法突破進程邊界，將執(zhí)行尋找API函數(shù)調用點的代碼和偽函數(shù)注入到驅動進程的空間內。有多種打破進程邊界的方法，比較簡單的方法是使用鉤子(Hook)。鉤子是Win32操作系統(tǒng)中用來攔截窗體消息的一項技術，分為兩種類型：線程鉤子和全局鉤子。前者只攔截某個具體窗體的消息，后者則能攔截所有正在運行程序的窗體消息。鉤子通過安裝來運行。安裝鉤子時需要提供一個鉤子回調函數(shù)，而且該函數(shù)必須位于一個DLL中，當鉤子安裝好后，系統(tǒng)就會將該DLL加載到窗體所屬進程的空間內。每次鉤子攔截到窗體消息時，回調函數(shù)都會首先被系統(tǒng)調用，以預處理消息，直至鉤子被卸載。鉤子被卸載后，DLL也將被從窗體進程的空間內卸載。這樣，可以利用鉤子來打破進程邊界：將執(zhí)行截獲的代碼和偽函數(shù)與鉤子回調函數(shù)放在同一個偽DLL中，然后針對驅動進程的窗體安裝一個線程鉤子，鉤子運行后，偽DLL便會被強制注入到驅動進程的空間內。當需要從驅動進程空間內撤離這些代碼時，只需將鉤子卸載掉即可。3)根據返回地址確定調用對象在錯誤注入之前，關鍵是需要判定調用者是否是待測的COM組件。確定API函數(shù)的調用者，可以通過API函數(shù)調用的返回地址進行判斷。圖STYLEREF1\s5.SEQ圖表\*ARABIC\s17函數(shù)調用?？臻g在如圖5.7所示的函數(shù)調用棧空間中，用如下內聯(lián)匯編可獲取調用API函數(shù)的返回地址。DWORD*retAddress;__asm{Movecx,[ebp+4]/*4是4個byte，32位機器，就是指針下一個，取到存returnaddress的塊的地址*/MovretAddress,ecx/*從寄存器中取出放入一個指針里面，用指針記錄這個地址*/}DWORDadd=*retAddress;/*add中就是返回地址的值*/通過該地址，可以借助操作系統(tǒng)系統(tǒng)提供的一個函數(shù)virturalquery(…)得到該地址所在虛擬地址空間塊的信息。在這個結構體信息中有一個值，是調用模塊的基址值也即句柄值，通過句柄值就可知道該模塊的名稱和其他信息。于是，通過模塊的名稱就可知道調用該API函數(shù)是否是待測COM組件。本章小結本章針對目前普遍使用的COM組件研制自動化安全性測試工具并實現(xiàn)其中的核心部分之一——錯誤注入子系統(tǒng)。首先對組件安全測試系統(tǒng)(CSTS)的總體框架和功能模塊進行了簡要的介紹，然后詳細給出了錯誤注入子系統(tǒng)的總體流程、結構和功能設計，最后對系統(tǒng)實現(xiàn)關鍵技術——API截獲技術進行了充分的論述。COM組件測試及效果評估上一章已經介紹了CSTS中錯誤注入子系統(tǒng)的設計和實現(xiàn)，為了進一步檢驗錯誤注入子系統(tǒng)在測試COM組件安全漏洞中的實際效果，本章選擇兩個第三方COM組件作為測試實例進行錯誤注入前后的對比分析，達到驗證接口參數(shù)錯誤注入和動態(tài)環(huán)境錯誤注入有效性的測試目的。COM組件測試測試環(huán)境在配置Intel處理器并安裝WindowsXPSP2中文版操作系統(tǒng)和.NETFramework2.0版本的軟硬件平臺上，對CSTS中錯誤注入子系統(tǒng)的有效性進行測試。測試實例為了證明接口參數(shù)錯誤注入的有效性，以一個有漏洞的第三方COM組件vuln.dll作為測試樣本(考慮到第三方COM組件一般接口和方法數(shù)較多，樣本組件中僅有針對性設計了一個接口和五個成員方法，這五個成員方法中有幾個方法是存在安全漏洞的，但事先并不知)，分兩個方面去證明接口錯誤注入的有效性：在沒有接口錯誤注入之前，考察能否測試出組件安全漏洞；在接口參數(shù)錯誤注入之后，考察能否檢測出組件安全漏洞并能給出漏洞原因的分析結論。除了能證明接口參數(shù)錯誤注入在揭露已知安全漏洞方面的能力，接口錯誤注入還要能夠檢測出事先未知是否有漏洞，即新的、未曾公布的COM組件安全漏洞，接下來給出這樣的測試案例。由于目前公布的COM組件安全漏洞尚無環(huán)境擾動方面的實例，為了證明動態(tài)環(huán)境錯誤注入的有效性，以一個第三方COM組件GomWeb3.dll作為測試實例，對在沒有環(huán)境錯誤注入和環(huán)境錯誤注入后COM組件安全測試的結果進行對照，根據動態(tài)環(huán)境錯誤注入所發(fā)現(xiàn)的新的潛在安全漏洞表明動態(tài)環(huán)境錯誤注入的有效性。測試過程1)測試第三方COM組件vuln.dll在不進行接口錯誤注入的前提下，使用CSTS測試vuln.dll有如下幾個步驟：(1)新建項目，選擇待測COM組件vuln.dll；(2)COM組件接口分析；(3)自動生成測試腳本文件；(4)手動添加或修改測試用例；(5)編譯鏈接；(6)啟動測試驅動程序；(7)開始動態(tài)監(jiān)視；(8)執(zhí)行測試；(9)測試結果查看分析。經過COM組件接口分析，發(fā)現(xiàn)vuln.dll有一個組件對象Server，Server中有一個接口Iserver，Iserver中有五個成員方法：Method1()、Method2()、Method3()、Method4()、HeapCorruption()，其原型如下所示：dispinterfaceIserver{properties:methods:longMethod1([in]BSTRsPath);longMethod2([in]longlin);longMethod3([in]VARIANTvin);longMethod4([in]BSTRsPath,[in]BSTRmsg);longHeapCorruption([in]BSTRstrIn,[in]longbufSize);}針對這五個成員方法，可手動輸入簡單測試用例如下：namespacevulntest{usingSystem;usingSystem.Collections.Generic;usingSystem.Text;usingSystem.Runtime.InteropServices;usingCOMTest;[TestFixture]publicclassserver{privateVULNLib.serverClassmyserverClass=newVULNLib.serverClass();[SetUp]publicvoidSetUp(){}[Test]publicvoidIserverMethod1(){stringsPath="test";myserverClass.Method1(sPath);}[Test]publicvoidIserverMethod2(){myserverClass.Method2(0);}[Test]publicvoidIserverMethod3(){stringvin="test";myserverClass.Method3(vin);}[Test]publicvoidIserverMethod4(){stringsPath="test";stringmsg="test";myserverClass.Method4(sPath,msg);}[Test]publicvoidIserverHeapCorruption(){stringstrIn="test";myserverClass.HeapCorruption(strIn,0);}}}圖6.1是在未進行接口參數(shù)錯誤注入的測試結果。圖STYLEREF1\s6.1未接口參數(shù)錯誤注入的測試結果使用CSTS進行接口參數(shù)錯誤注入測試vuln.dll的步驟如下：(1)新建項目，選擇待測COM組件vuln.dll；(2)COM組件接口分析；(3)選擇“接口錯誤注入”自動生成測試用例；(5)編譯鏈接；(6)啟動測試驅動程序；(7)開始動態(tài)監(jiān)視；(8)執(zhí)行測試；(9)測試結果查看分析。針對以上五個方法原型，接口參數(shù)錯誤注入自動生成如下測試用例：namespacevulnInterfaceFaultInjection{usingSystem;usingSystem.Collections.Generic;usingSystem.Text;usingSystem.Runtime.InteropServices;usingCOMTest;[TestFixture]publicclassserver{privateVULNLib.serverClassmyserverClass=newVULNLib.serverClass();[SetUp]publicvoidSetUp(){}[TearDown]publicvoidTearDown(){}[Test]publicvoidIserverMethod1(){stringsPath=newstring('A',500);longresult=myserverClass.Method1(sPath);}[Test]publicvoidIserverMethod2(){longresult=myserverClass.Method2(2147483647);}[Test]publicvoidIserverMethod3(){stringvin=newstring('A',500);longresult=myserverClass.Method3(vin);}[Test]publicvoidIserverMethod4(){stringsPath=newstring('A',500);stringmsg=newstring('A',500);longresult=myserverClass.Method4(sPath,msg);}[Test]publicvoidIserverHeapCorruption(){stringstrIn=newstring('A',500);longresult=myserverClass.HeapCorruption(strIn,2147483647);}}}圖6.2是在進行接口參數(shù)錯誤注入后的測試結果。圖STYLEREF1\s6.2接口參數(shù)錯誤注入后的測試結果2）測試第三方COM組件GomWeb3.dll在不進行動態(tài)環(huán)境錯誤注入下測試GomWeb3.dll和在不進行接口錯誤注入的前提下測試vuln.dll的步驟一樣，其測試結果如圖6.3所示。圖STYLEREF1\s6.3未動態(tài)環(huán)境錯誤注入的測試結果使用CSTS進行動態(tài)環(huán)境錯誤注入測試GomWeb3.dll的步驟如下：(1)新建項目，選擇待測COM組件GomWeb3.dll；(2)GomWeb3.dll接口分析；(3)自動生成測試腳本文件；(4)編譯鏈接；(5)啟動測試驅動程序；(6)開始動態(tài)監(jiān)視；(7)選擇要注入的“環(huán)境錯誤”，如內存不足和注冊表崩潰(如圖6.4所示)；(8)執(zhí)行測試。動態(tài)環(huán)境錯誤注入后的測試結果如圖6.5、圖6.7所示。圖STYLEREF1\s6.4選擇注入的環(huán)境錯誤圖STYLEREF1\s6.5環(huán)境錯誤注入后的測試結果測試效果評估一個首要的安全需求是阻止一個不可信的組件訪問主機上任意地址和資源，如“存儲越界訪問”或“非法訪問異?！薄Ｈ绻跍y試過程中出現(xiàn)“存儲越界訪問”，則表明待測組件存在安全漏洞。接口參數(shù)錯誤注入的有效性從圖6.1可以看到在沒有接口參數(shù)錯誤注入之前，手動輸入的12個測試用例全部執(zhí)行成功，但在接口參數(shù)錯誤注入后，第三方COM組件vuln.dll出現(xiàn)“存儲越界訪問”異常(如圖6.2所示)，從而表明vuln.dll存在安全漏洞。進一步反復對vuln.dll進行“接口參數(shù)錯誤注入”，生成不同的測試用例，通過查看參數(shù)在輸入何值時導致異常，最終得出vuln.dll漏洞原因結論：(1)Method1()僅有一個字符串類型參數(shù)sPath，在輸入超長字符串的時候，產生緩沖區(qū)溢出漏洞，因此漏洞原因在于sPath沒有進行有效的參數(shù)長度檢查；(2)Method2()、Method3()經檢測無安全漏洞；(3)Method4()的二個參數(shù)sPath和msg均是字符串類型，但只有第二個存在緩沖區(qū)溢出漏洞，因此漏洞原因在于msg沒有進行有效的參數(shù)長度檢查，未經驗證就輸入到緩沖區(qū)導致安全漏洞；(4)HeapCorruption()的兩個參數(shù)strIn和bufSize，一個是字符串，另一個是長整型，對第一個參數(shù)輸入超長字符串導致緩沖區(qū)溢出，對第二個參數(shù)輸入大整數(shù)時造成整數(shù)溢出。通過以上對第三方COM組件vuln.dll的安全測試，可知：在沒有接口錯誤注入之前，不能測試出組件安全漏洞，而在接口參數(shù)錯誤注入之后，能檢測出組件安全漏洞并能給出漏洞原因的分析結論。因此，證明了接口參數(shù)錯誤注入在揭露已知安全漏洞方面的有效性。除了能完全檢查出現(xiàn)今已知的或已公布的COM組件安全漏洞，接口參數(shù)錯誤注入還能夠檢測出事先未知是否有漏洞和未曾公布的COM組件安全漏洞。圖6.6就是一個通過接口參數(shù)錯誤注入檢測出的未曾在網上公布的新的安全漏洞。該漏洞源自騰訊QQ2006珊瑚蟲版CoralAssist.dll組件(版本15)，其中的一個方法Excute()的三個字符型參數(shù)，均未對輸入值進行長度檢查，導致緩沖區(qū)溢出漏洞。圖STYLEREF1\s6.6CoralAssist.dll組件漏洞另外，暴風影音Ⅱ的一個COM組件mps.dll(版本2.07.06.15)經接口參數(shù)錯誤注入也發(fā)現(xiàn)了未曾公布的安全漏洞，該組件中的URL屬性輸入超長字符串時，出現(xiàn)存儲訪問越界異常，另一個函數(shù)advancedOpen()也暴露出緩沖區(qū)溢出漏洞。綜上所述，接口參數(shù)錯誤注入不僅在揭露已知安全漏洞方面有效，而且在揭露未知安全漏洞方面也同樣具有一定的有效性，因而證明了接口錯誤注入的有效性。動態(tài)環(huán)境錯誤注入的有效性從圖6.3可以看到在沒有動態(tài)環(huán)境錯誤注入之前，手動輸入的78個測試用例全部執(zhí)行成功，但在動態(tài)環(huán)境錯誤注入后，78個測試用例失敗2個，同時第三方COM組件GomWeb3.dll在執(zhí)行過程中出現(xiàn)“存儲越界訪問”異常(如圖6.7)，表明GomWeb3.dll存在安全漏洞。在以上測試GomWeb3.dll過程中，可知是由于注入了“環(huán)境錯誤”——內存不足和注冊表崩潰而導致GomWeb3.dll執(zhí)行出現(xiàn)異常，通過監(jiān)視日志查看GomWeb3.dll在執(zhí)行過程中調用系統(tǒng)API的情況，發(fā)現(xiàn)GomWeb3.dll在執(zhí)行接口方法OpenURL()對應的測試用例時調用了系統(tǒng)函數(shù)LocalAlloc()，即本地內存分配函數(shù)，當選擇注入“內存不足”環(huán)境錯誤時，返回一個“ERROR_NOT_ENOUGH_MEMORY”的模圖STYLEREF1\s6.7環(huán)境錯誤注入后出現(xiàn)“存儲越界訪問”異常擬錯誤，而GomWeb3.dll沒有正確處理該錯誤，忽視了返回值的應有判斷，導致在沒有分配的內存空間上越界訪問，所以出現(xiàn)“存儲越界訪問”異常。綜上，通過在沒有環(huán)境錯誤注入和環(huán)境錯誤注入后GomWeb3.dll安全測試的結果進行對比分析，動態(tài)環(huán)境錯誤注入不僅能發(fā)現(xiàn)新的安全漏洞，并且能定位到安全漏洞產生的具體來源，從而證明了動態(tài)環(huán)境錯誤注入的有效性。本章小結本章對錯誤注入子系統(tǒng)進行了測試，通過選取兩個典型的測試實例進行系統(tǒng)測試驗證了系統(tǒng)的功能。測試表明針對第三方COM組件運用所設計與實現(xiàn)的錯誤注入子系統(tǒng)完成了對組件靜態(tài)的接口參數(shù)錯誤注入和動態(tài)的環(huán)境錯誤注入功能，通過錯誤注入子系統(tǒng)能有效地觸發(fā)組件內部的安全漏洞，并能結合動態(tài)監(jiān)視得出組件漏洞原因的結論。這說明錯誤注入子系統(tǒng)的功能設計正確，實現(xiàn)有效。結束語本文工作總結隨著組件特別是第三方組件的使用，大大提高了軟件開發(fā)的效率，但同時也增加了軟件可靠性和安全性的風險。隨著互聯(lián)網的發(fā)展，這種風險越來越突出。作為保障組件安全的可靠手段——組件安全性測試成為重要的研究內容。然而由于其理論和技術的難度，組件安全性測試研究尚未取得實質的進展。本文即在此背景下對組件安全性測試的理論與技術進行研究，提出了一種基于錯誤注入技術的SDFI組件安全性測試方法，并在實踐上設計和開發(fā)了一個COM組件安全自動化錯誤注入測試系統(tǒng)，測試結果表明SDFI在組件安全性測試中具有一定的實用性和有效性。本文的主要工作及創(chuàng)新總結如下：1)對錯誤注入技術概念、歷史以及利用錯誤注入技術進行安全性測試的方法進行了深入的研究和探討，并針對組件、尤其是第三方組件，提出一種基于錯誤注入的SDFI組件安全性測試方法；2)通過對組件安全性測試基本概念、研究內容和難點的研究，在安全漏洞分類學研究的基礎之上，給出了一種FIM組件安全錯誤注入測試模型；3)根據FIM針對組件運行前和運行時兩個不同的時機，分別提出了測試組件安全漏洞的基于Ballista的接口參數(shù)錯誤注入方法和基于EAI模型的動態(tài)環(huán)境錯誤注入方法，并給出了相應的EEC和DSW測試用例約減算法；4)在理論研究的基礎上，針對目前普遍使用的COM組件，設計和實現(xiàn)了基于Win32API截獲技術的CSTS組件安全自動化錯誤注入子系統(tǒng)；5)選取第三方COM組件作為測試實例進行錯誤注入前后的對比分析，測試結果表明通過錯誤注入子系統(tǒng)不僅能有效地揭露已知的安全漏洞，還能觸發(fā)組件未知的安全漏洞，從而驗證了SDFI組件安全性測試方法的有效性。后續(xù)工作展望由于時間關系和作者水平有限，課題研究中還存在一些不足，一些工作還需要進一步的完善和深入。作者認為還需要在下面這些方面做更深層次的研究工作：1)深化接口參數(shù)錯誤注入方法的研究在本文基于Ballista的接口參數(shù)錯誤注入方法中，通過預先針對不同參數(shù)類型構建各種各樣的異常元素，測試用例就是這些不同異常元素的組合，但并沒有提供對不同類型的異常元素進行結構化的設計，下一步的工作就是如何使測試用例的構造更為系統(tǒng)化，使測試用例更有針對性。2)改進錯誤注入測試用例生成算法在本文提出的接口參數(shù)錯誤注入和動態(tài)環(huán)境錯誤注入方法中，測試用例生成算法仍然需要改進，現(xiàn)有的算法在處理較復雜的組件時產生的測試用例集合還是過大，并且錯誤注入測試用例的有效性還需要進一步提高。今后工作重點可圍繞這一方面進行深入研究。3)完善和增強CSTS與錯誤注入子系統(tǒng)的功能目前的CSTS工具只能測試基于COM標準的簡單組件，對參數(shù)約束、有狀態(tài)的情況以及需要搭建運行環(huán)境的復雜組件仍然需要手工操作。如何實現(xiàn)一個更通用的、針對任何Windows平臺的組件安全性測試工具也將是下一階段工作的方向之一。另外，錯誤注入子系統(tǒng)中動態(tài)環(huán)境錯誤注入功能需要提高Win32API截獲的穩(wěn)定性和效率，這方面也有待解決。碩士階段的生活短暫而充實，在師長的關心和幫助下，作者在專業(yè)知識方面取得了不小的進步，各方面的能力也有了提高。作者十分清楚自己存在的缺點和不足，在今后的工作和學習中還要不斷努力提高自己的綜合素質。致謝碩士階段的學習即將結束，兩年的學習生活緊張而又愉快。論文是我這一階段學習工作情況的總結。在此謹向所有關心、幫助、支持過我的老師、同學、朋友和親人致以最誠摯的感謝！首先要感謝我的導師徐麗萍副教授，本文是在她的孜孜不倦的教誨和無微不至的關懷下完成的。這里謹向徐老師表示最誠摯的謝意與敬意！我還要特別感謝敬愛的盧炎生教授：盧老師深厚的理論功底、淵博的學識、儒雅的學術風范和兢兢業(yè)業(yè)、精益求精的工作態(tài)度給我留下了深刻的印象，深深地感染和激勵著我，也將永遠鞭策著我不斷進??！盧老師正直無私的品格，豁達的胸襟，樂觀積極地人生態(tài)度展現(xiàn)了學者的思想境界和人格魅力，為我樹立了做人的楷模，使我終生難忘！感謝謝曉東老師在課題研究上給我悉心的幫助和指導。謝老師嚴謹?shù)膶W術態(tài)度、忘我的工作精神和耐心細致的言傳身教不斷激勵著我，在此特別感謝謝老師對我的鼓勵，幫助和信任感謝殷賢亮副教授、楊茂林老師、趙小松老師、潘鵬老師、吳海老師、江勝老師、瞿彬彬老師等各位老師在學習和生活中對我的指導和幫助，從你們身上我學到了豐富的知識和寶貴的經驗。感謝陳錦富、游亮、黃晉博士，同課題組的溫賢鑫、王平、張超、倪銘同學，在實驗室的學習生活中我們朝夕相處，與他們在學術上的交流，給了我很多有益的啟示，使我受益頗多。感謝師兄，感謝實驗室所有的師兄師姐和師弟師妹們，感謝你們和我一起度過快樂的時光！感謝我的父母。一直以來，他們都無私地為我貢獻著，風風雨雨陪伴我走了過來?；厥走@兩年走過的路，回顧過去的點點滴滴，覺得萬分地感動。我要向他們深深地鞠一躬！最后感謝所有關心、愛護和幫助過我的親人和朋友！PAGE參考文獻GPour.Component-BasedsoftwareDevelopmentApproach:NewOpportunitiesandChallenges[C].In:ProcofTechnologyofObject-OrientedLanguages,1998:375-383.張勇，基于規(guī)格說明的組件安全性測試技術研究與實現(xiàn)，中國人民解放軍信息工程大學碩士學位論文，2005.12。毛澄映，盧炎生，構件軟件測試技術研究進展，計算機研究與發(fā)展，2006年08期：1375-1382。ClarkJAPradhanDK.FaultInjection:AMethodforValidatingComputer-SystemDependability.IEEEComputer,1995,28(6):47-56.AnupK.Ghosh,TomO'Connor&GaryMcGraw,AnAutomatedApproachforIdentifyingPotentialVulnerabilitiesinSoftware,ReliableSoftwareTechnologiesCorporation,1998.鄒濤，張翠，許博義，基于故障注入的軟件安全性測試方法研究，全國抗惡劣環(huán)境計算機第十五屆學術年會，2005：26-29

。AnupK.Ghosh&GaryMcGraw,AnApproachforCertifyingSecurityinSoftwareComponents,ReliableSoftwareTechnologies,1998.PanelModerator:JimReynolds,Teknowledge,HowUsefulIsSoftwareFaultInjectionforEvaluatingtheSecurityofCOTSProducts,IEEESoftware,1998.NimalNissanke,ComponentSecurity–IssuesandanApproach,Proceedingsofthe29thAnnualInternationalComputerSoftwareandApplicationsConference(COMPSAC’05),IEEE,2005.K.Md.Khan,J.HanandY.Zheng,"CharacterisingUserDataProtectionofSoftwareComponents,"inSoftwareEngineeringConference,2000Australian,IEEEsoftware,Canberra,ACT,Australia,2000,pp.3-11.K.Md.Khan,J.Han,"AssessingSecurityPropertiesofSoftwareComponents:ASoftwareEngineer'sPerspective,"inProceedingsofthe2006AustralianSoftwareEngineeringConference(ASWEC),IEEE,2006,pp.199-210.J.Han,K.Md.Khan,"ASecurityCharacterisationFrameworkforTrustworthyComponentBasedSoftwareSystem,"inProceedingsofthe27thAnnualInternationalComputerSoftwareandApplicationsConference(COMPSAC),IEEE,pp.164-169,2003.J.Han,Y.Zheng,"SecurityCharacterisationandIntegrityAssuranceforComponent-BasedSoftware,"IEEEsoftware,pp.61-66,2000.A.Bertolino,A.Polini,"AFrameworkforComponentDeploymentTesting,"inthe25thInternationalConferenceonSoftwareEngineering(ICSE),IEEEComputerSociety,pp.221–231,2003.J.M.Haddox,G.M.KapfhammerandC.C.Michael,"AnApproachforUnderstandingandTestingThirdPartySoftwareComponents,"inProceedingsAnnualReliabilityandMaintainabilitySymposium,IEEE,Seattle,WA,USA,pp.293-299,2002.MartinS¨u?krautChristofFetzer,RobustnessandSecurityHardeningofCOTSSoftwareLibraries,37thAnnualIEEE/IFIPInternationalConferenceonDependableSystemsandNetworks,2007.Hsueh,M.C.,Tsai,T.,Iyer,R.:FaultInjectionTechniquesandTools.In:IEEEComputer,pp.75-82,1997.J.V.Carreira,D.Costa,andS.J.G,"FaultInjectionSpot-ChecksComputerSystemDependability",IEEESpectrum,pp.50-55,1999.J.Carrara,H.Madeira,J.GabrielSilva.Xception:ATechniquefortheExperimentalEvaluationofDependabilityinModernComputers.IEEETrans.onSoftwareEngineering,1998,24(2):125-136.H.Mills.Onthestatisticalvalidationofcomputerprograms.TechnicalReportFSC-726015,IBMFederalSystemsDivision,1972.BiemanJM,DreilingerD,LINLi-jun.Usingfaultinjectiontoincreasesoftwaretestcoverage[A].SoftwareReliabilityEngineeringProceedingsSeventhInternationalSymposium[C].NewYork:IEEEComputerSocietyPress,pp.166-174,1996.J.Voas,"FaultInjectionfortheMasses,"Computer,vol.30,pp.129-130,1997.R.Barbosa,N.Siliva,J.Dur?e,HMadeira,VerificationandValidationof(RealTime)COTSProductsusingFaultInjectionTechniques,2007.W.DuandA.P.Mathur.VulnerabilityTestingofSoftwareSystemUsingFaultInjection.TechnicalReport,COAST,PurdueUniversity,WestLafayette,IN,US,1998.JMVoas&AnupK.Ghosh.Softwarefaultinjectionforsurvivability.DARPAInformationSurvivabilityConferenceandExposition,P338-346,1999.CowanCPuCMaierDetal.StackguardAutomaticAdaptiveDetectionandPreventionofBuffer-overflowAttacks.InProceedingsofthe7thUSENIXSecuritySymposium,pages:63-78,1998.11.MillerB.PKoskiDLeeC.Petal.FuzzRevistedARe-examinationoftheReliabilityofUnixUtilitiesandServices.Technicalreport,UniversityofWisconsin,ComputerSciencesDept,1995.Jo?oDur?e,HenriqueMadeira,DefinitionofSoftwareFaultEmulationOperators:aFieldDataStudy.TheInternationalConferenceonDependableSystemsandNetworks,2003.朱鴻宇，謝余強，劉瑰，基于故障注入發(fā)現(xiàn)緩沖區(qū)溢出漏洞的研究，微計算機應用，2005年06期26卷：676-678。R.Moraes,R.Barbosa,J.Dur?es,N.Mendes,E.Martins,H.Madeira,Injectionoffaultsatcomponentinterfacesandinsidethecomponentcodearetheyequivalent,ProceedingsoftheSixthEuropeanDependableComputingConference,IEEE,2006.B.P.Miller,L.Fredriksen,andB.So,"AnEmpiricalStudyoftheReliabilityofUNIXUtilities",CommunicationsoftheACM33,12(December1990).Alsoappears(inGermantranslation)as"FataleFehlertractigkeit:EineEmpirischeStudiezurZuverlassigkeitvonUNIX-Utilities",iX,March1991.NathanP.Kropp,PhilipJ.Koopman,DanielP.Siewiorek,AutomatedRobustnessTestingofOff-the-ShelfSoftwareComponent,CarnegieMellonUniversity,1998.Koopman,P.Siewiorek,D.DeVale,K.DeVale,J.Fernsler,K.Guttendorf,D.Kropp,N.Pan,J.Shelton,C.Shi,Y.“BallistaProject:COTSSoftwareRobustnessTesting”,CarnegieMellonUniversity,2003.Martins,E.Rubira,C.M.F.LemeN.G.M.“Jaca:Areflectivefaultinjectiontoolbasedonpatterns”Procofthe2002InternConferenceonDependableSystems&Networks,pp.483-487,WashingtonD.C.USA,23-267,2002.李明，高勇，李祥和，基于語法的軟件安全檢測，信息安全與通信保密，2006年08期：86-87，91。PeteBroadwell,NaveenSastry,JonathanTraupman.FIGProject-FaultInjectioninglibc(FIG),RecoveryOrientedComputing(ROC)-UCB,December10,2001.JamesA.Whittaker.ICSE–RuntimeFaultInjection.Toappear.單國棟，連一峰，環(huán)境錯誤注入測試機制，計算機工程，2004年第30卷19期：113-114，182。\o"王航"王航，\o"戴英俠"戴英俠，單國棟，連一峰，軟件系統(tǒng)安全脆弱性測試技術，\o"計算機科學"計算機科學，2002年29卷08期：134-136。C.Szyperski.ComponentSoftware-BeyondObjectOrientedProgramming[M].AddisonWesley,1997.Moraes,R.andMartins,E.“AnArchitecture-basedStr