黎慧華
摘 要:在網絡技術被大面積的覆蓋之前,單機的應用程序軟件所產生的安全沖突的問題并不多。而隨著現在互聯網技術的深入,軟件的安全問題所造成的影響也越來越嚴重。在實際的發展中我們開始重視軟件安全的重要性。目前軟件的廣泛應用以及其規模空前的增加,相應的難度也被提高,這種背景下的軟件安全問題不得不引起重視。本文主要闡述關于網絡軟件的安全監測的主要內容,其中會介紹目前發展的主要監測方法,比如形式化的安全測試、模糊測試、語法測試等方法,筆者會對軟件安全性的技術發展做一定的回顧,希望能夠從這些技術中能夠得到更多安全性檢測的思路。
關鍵詞:軟件安全;檢測技術;概述;
1.軟件安全性測試概述
軟件安全性測試主要可以分為兩個方面,一方面是對安全功能的測試,另外一方面則是對安全漏洞的測試。首先,我們對于安全功能的測試的主要目的是為了判定軟件的設計功能是否能夠符合用戶對軟件的要求,而這種設計是否能夠幫助他們需求的實現。當然對漏洞的測試的主要目的是從漏洞的攻擊者的角度考慮,確保軟件的安全漏洞不受到威脅【1】。另外,在內容上,安全功能測試主要會涉及到數據的機密完整性以及其隱私保護等內容,而安全漏洞測試的重點在于對系統的設計和操作等出現的弱點,一旦被利用就容易受到外界的攻擊而進入不安全的狀態。從以上兩個方面我們可以得知,在軟件安全性測試中我們應該確保以下幾個方面:第一,全面檢測出軟件一旦陷入不安全的狀態所產生的反應。第二,測試軟件在設計時需要盡可能的提高其安全性,包括在算法冗余、容錯等做好優化。第三,了解軟件在異常情況下的反應。第四,對于軟件中的模塊以及部件要做好單獨的測試并加強整個測試流程的進行。
2.軟件安全測試的主要技術
2.1形式化安全測試
形式化的主要運用思路通過建立軟件的數學模型來進行測試的一種方法。它可以分為兩種類型,一種是定理證明,另外一種是模型檢測。首先,前者是將程序切換成邏輯的公式,運用相關的規則來證明該程序是一種合法的定理。而后者用遷移系統S用來描述軟件的模式,通過邏輯公式來達到軟件需要形成的目的,如果能夠在自動搜索系統S中發現存在的不滿足函數F的問題,則可以確認相應的軟件漏洞。NASA中的JPL曾經做過此類技術的項目【2】。他們在實驗中的主要思路是通過建立針對安全需求的形式化模型,來判斷是否從起始之后沒有發現存在違約的不安全的狀態。這種技術存在著一定的不足。比如定理的證明方法無法確保全面的自動化操作,它依然需要分析人員參與運行過程,這期間非常耗費人力,而模型的檢測方法需要將所有的可能性進行執行,因此檢測時的效率較低。
2.2基于模型的測試方法
基于模型的安全性測試是通過對軟件中的行為以及結構建立模型,然后運用生成的測試模型產生測試的用例。Nahid Shahmehri等在研究中提出一種基于模型的軟件安全性測試方法,這種模型用來檢測以及追蹤軟件中存在的缺陷,是一種較為被動的技術類型。因此,開發者很容易準確的了解到軟件中軟件的類型,當發現新的漏洞是會添加相應的方法對工具進行擴展。檢測模型是在SGMs的基礎上可以表明漏洞產生的原因,以及與其他原因之間的關系【3】。其中SGMs將漏洞的模型運用樹狀結構來進行描述。
Mark Blackburn等曾經提出一種端對端的基于模型的全自動檢測方法,這種測試技術可以被運用到各個環境中,具有一定的廣泛性。它的基礎在于對安全函數的說明建立模型,Orale以及Interbase兩種數據庫引擎的在其中的運用幫助自動形成模型并做后續的測試。
2.3語法測試
對語法的定義在于軟件接受了輸入中的數據類型以及數據格式。語法測試的主要環節是可以根據軟件上相關的功能接口中的語法再生成相應的測試語法的輸入,在這樣的形式下來檢測軟件對輸入產生的反應,然后對輸入以及反應之間的聯系做出安全性的分析。語法測試比較適用于黑盒測試實驗中,根據相應的語法特征,產生正常和不正常的輸入方式,然后引發各種安全中的問題。不過它存在的缺點在于所需要測試的數據量極大,因此很難全部覆蓋到。Patrice Godefroid等通過研究,在語法的基礎上對非法輸入的形式作出描述,用這種方法是來提高白盒測試產生的效果,形成一種新的動態測試算法。
2.4基于故障注入的安全性測試
應用程序和其應用的環境兩者之間的交互包括用戶輸入、環境變量等,這些過程中產生的故障將被作為注入故障。人為的把故障注入到系統里,可以讓系統加速失效,與此同時也加強了對安全的排查。
Binbin Qu等學者曾經提出一種在客戶機和服務器模式下錯誤的注入方式,這種方式被用在對軟件組件的測試上。在API Hooking的基礎上設計的錯誤注入工具,這種工具中的GCDEFI是在客戶機—服務器模式的基礎上形成的,它的組成結構包括一個服務端以及多個客戶【4】。服務器可以控制住服務機,并且收集到需要的反饋信息然后與客戶機產生交互;客戶機的主要內容是可以管理API的攔截、系統中錯誤的信息等。客戶機在運行中會被注入到測試驅動范圍中。在GCDEFI開啟之后,用戶中的錯誤類型的信息通過控制器來得到,然后被保存到錯誤管理的模塊區域。控制器在工作后會觸發Activator,這種部件會將錯誤的信息傳遞到目標信息管理器中。當發生API攔截時,調用者的信息會被系統立即獲取,然后在系統中插在相應的堆棧以及組件列表,確認是否有相互匹配的組件,一旦沒有那么進入返回的模式,否則系統就會執行程序中的替代代碼,再執行設計的錯誤注入流程。這種技術產生的特用性也存在著一些問題,就是它只能適用于特點環境中的特定組件,這樣才能有較好的測試見過。Jinfu Chen也有提一種安全性測試工具,這種工具被稱為CSTS。它可以在迅速獲取COM組件的基礎上進行相關的分析,然后在系統中進行靜態分析組件漏洞,之后會自動的生成測試需要的腳本,生成測試需要的驅動等功能。但是經過檢驗,這種方法的評級標準較為模糊,還需要深入的細化。
2.5模糊測試
模糊測試的技術是在黑盒隨機測試的基礎上,運用隨機的變異程序輸入來檢查和確認程序中的響應狀況,然后在這種情形下發現漏洞,系統會在這個過程中用語法規則來進行系統正常的輸入,除此之外,還可以運用試探法來產生輸入變量。但是,模糊測試的一項最大的問題是它的代碼覆蓋率非常的低。Patrice Godefroid等學者在這種模式下提出了一種新型的白盒模糊測試的方法,這種式在象征性執行方法以及用例生成方法的啟發下所提出的。但是這種方法由于樣本尺寸的有限性依然存在著低代碼覆蓋率的情況。
2.6基于風險的安全性測試
系統中錯誤發生的概率以及產生的危害程度便形成了系統的潛在風險。考慮到風險的危害,這種安全測試的出發點都會以軟件安全風險為主,運行過程中對風險的分析、安全測試以及軟件開發的過程都進行系統化的處理,這種方法在軟件開發的階段中都會把風險的安全漏洞考慮其中,然后保持與軟件開發的進度一致。
3.結語
軟件安全性測試的方法由于研究的環境以及影響因素的復雜,各個種類的方法都還處于探索階段,也存在著技術上較多的限制,這些需要工作人員在軟件測試方面有豐富的操作經驗,以及更加全面的知識結構,才能將各個方法進行聯系操作。因此,測試人員的經驗需要包括對軟件安全漏洞的全面認知以及理解,另外在知識結構中還需要掌握好編程、數據庫等多種編譯知識,只有在強大知識儲備的基礎上才能夠根據用戶的需求高效的開發出有效的測試工具。
參考文獻:
[1]秦曉軍,甘水滔,陳左寧. 一種基于一階邏輯的軟件代碼安全性缺陷靜態檢測技術[J]. 中國科學:信息科學,2014,01:108-129.
[2]侯海燕,符志鵬. 軟件安全性檢測技術綜述[J]. 電腦知識與技術,2014,25:5847-5851+5854.
[3]倪濤. 基于靜態污點分析技術的軟件內核驅動安全性檢測[J]. 計算機應用與軟件,2015,05:262-266.