軟體安全效能測試（轉載）

標籤：使用   strong   資料   art   問題   cti   

近來，在我負責的公司某軟體產品的最後測試工作，經常被問到這樣一個問題：在做測試過程中，我們的軟體產品在安全性方面考慮了多少？應該怎樣測評一個軟體究竟有多安全？
　　這個軟體因為涉及客戶商業上重要的資訊資料，因此使用者關心的核心問題始終環繞“這個軟體安全嗎”。一個因為設計導致的安全性漏洞和一個因為實現導致的安全性漏洞，對使用者的終於影響都是巨大的。我的工作就是確保這個軟體在安全性方面能滿足客戶期望。
　　一、什麼是軟體安全性測試
　　（1）什麼是軟體安全
　　軟體安全屬於軟體領域裡一個重要的子領域。在曾經的單機時代，安全問題主要是作業系統easy感染病毒，單機應用程式軟體安全問題並不突出。可是自從互連網普及後，軟體安全問題愈加顯加突顯，使得軟體安全性測試的重要性上升到一個前所未有的高度。
　　軟體安全一般分為兩個層次，即應用程式層級的安全性和作業系統層級的安全性。應用程式層級的安全性，包含對資料或業務功能的訪問，在預期的安全性情況下，操作者僅僅能訪問應用程式的特定功能、有限的資料等。作業系統層級的安全性是確保僅僅有具備系統平台訪問許可權的使用者才幹訪問，包含對系統的登入或遠程訪問。
　　本文所講的軟體安全主要是應用程式層的安全，包含兩個層面：①是應用程式本身的安全性。一般來說，應用程式的安全問題主要是由軟體漏洞導致的，這些漏洞能夠是設計上的缺陷或是編程上的問題，甚至是開發人員預留的後門。②是應用程式的資料安全，包含資料存放區安全和傳輸資料安全兩個方面。
　　（2）軟體安全性測試
　　一般來說，對安全性要求不高的軟體，其安全性測試能夠混在單元測試、整合測試、系統測試裡一起做。但對安全性有較高需求的軟體，則必須做專門的安全性測試，以便在破壞之前預防並識別軟體的安全問題。
　　安全性測試（SecurityTesting）是指有關驗證應用程式的安全等級和識別潛在安全性缺陷的過程。應用程式級安全測試的主要目的是尋找軟體自身程式設計中存在的安全隱患，並檢查應用程式對非法侵入的防範能力，依據安全指標不同測試策略也不同。注意：安全性測試並不終於證明應用程式是安全的，而是用於驗證所設立策略的有效性，這些對策是基於威脅分析階段所做的如果而選擇的。比如，測試應用軟體在防止非授權的內部或外部使用者的訪問或有益破壞等情況時的運作。
　　二、軟體安全性測試過程
　　（1）安全性測試方法
　　有很多的測試手段能夠進行安全性測試，眼下主要安全測試方法有：
　　①靜態代碼安全測試：主要通過對源碼進行安全掃描，依據程式中資料流、控制流程、語義等資訊與其特有軟體安全規則庫進行匹對，從中找出代碼中潛在的安全性漏洞。靜態源碼安全測試是很實用的方法，它能夠在編碼階段找出全部可能存在安全風險的代碼，這樣開發人員能夠在早期解決潛在的安全問題。而正由於如此，靜態代碼測試比較適用於早期的代碼開發階段，而不是測試階段。
　　②動態滲透測試：滲透測試也是經常使用的安全測試方法。是使用自己主動化工具或者人工的方法類比駭客的輸入，相應用系統進行攻擊性測試，從中找出執行時刻所存在的安全性漏洞。這樣的測試的特點就是真實有效，一般找出來的問題都是正確的，也是較為嚴重的。但滲透測試一個致命的缺點是類比的測試資料僅僅能到達有限的測試驗，覆蓋率非常低。
　　③程式資料掃描。一個有高安全性需求的軟體，在執行過程中資料是不能遭到破壞的，否則就會導致緩衝區溢位類型的攻擊。資料掃描的手段一般是進行記憶體測試，記憶體測試能夠發現很多諸如緩衝區溢位之類的漏洞，而這類漏洞使用除此之外的測試手段都難以發現。比如，對軟體執行時的記憶體資訊進行掃描，看是否存在一些導致隱患的資訊，當然這須要專門的工具來進行驗證，手工做是比較困難的。
　　（2）反向安全性測試過程
　　大部分軟體的安全測試都是根據缺陷空間反向設計原則來進行的，即事先檢查哪些地方可能存在安全隱患，然後針對這些可能的隱患進行測試。因此，反向測試過程是從缺陷空間出發，建立缺陷威脅模型，通過威脅模型來尋找入侵點，對入侵點進行已知漏洞的掃描測試。優點是能夠對已知的缺陷進行分析，避免軟體裡存在已知類型的缺陷，可是對未知的攻擊手段和方法一般會無能為力。
　　①建立缺陷威脅模型。建立缺陷威脅模型主要是從已知的安全性漏洞入手，檢查軟體中是否存在已知的漏洞。建立威脅模型時，須要先確定軟體牽涉到哪些專業領域，再依據各個專業領域所遇到的攻擊手段來進行建模。
　　②尋找和掃描入侵點。檢查威脅模型裡的哪些缺陷可能在本軟體中發生，再將可能發生的威脅納入入侵點矩陣進行管理。假設有成熟的漏洞掃描工具，那麼直接使用漏洞掃描工具進行掃描，然後將發現的可疑問題納入入侵點矩陣進行管理。
　　③入侵矩陣的驗證測試。建立好入侵矩陣後，就能夠針對入侵矩陣的詳細條目設計相應的測試用例，然後進行測實驗證。
　　（3）正向安全性測試過程
　　為了規避反向設計原則所帶來的測試不完備性，須要一種正向的測試方法來對軟體進行比較完備的測試，使測試過的軟體可以預防未知的攻擊手段和方法。
　　①先標識測試空間。對測試空間的全部的可變資料進行標識，因為進行安全性測試的代價高昂，當中要重點對外部輸入層進行標識。比如，需求分析、概要設計、具體設計、編碼這幾個階段都要對測試空間進行標識，並建立測試空間跟蹤矩陣。
　　②精確定義設計空間。重點審查需求中對設計空間是否有明白定義，和需求牽涉到的資料是否都標識出了它的合法取值範圍。在這個步驟中，最須要注意的是精確二字，要嚴格依照安全性原則來對設計空間做精確的定義。
　　③標識安全隱患。依據找出的測試空間和設計空間以及它們之間的轉換規則，標識出哪些測試空間和哪些轉換規則可能存在安全隱患。比如，測試空間愈複雜，即測試空間劃分越複雜或可變資料群組合關係越多也越不安全。還有轉換規則愈複雜，則出問題的可能性也愈大，這些都屬於安全隱患。
　　④建立和驗證入侵矩陣。安全隱患標識完畢後，就能夠依據標識出來的安全隱患建立入侵矩陣。列出潛在安全隱患，標識出存在潛在安全隱患的可變資料，和標識出安全隱患的等級。當中對於那些安全隱患等級高的可變資料，必須進行詳盡的測試用例設計。
　　（4）正向和反向測試的差別
　　正向測試過程是以測試空間為根據尋找缺陷和漏洞，反向測試過程則是以已知的缺陷空間為根據去尋找軟體中是否會發生相同的缺陷和漏洞，兩者各有其優缺點。反向測試過程基本的一個長處是成本較低，僅僅要驗證已知的可能發生的缺陷就可以，但缺點是測試不完好，無法將測試空間覆蓋完整，無法發現未知的攻擊手段。正向測試過程的長處是測試比較充分，但工作量相對來說較大。因此，對安全性要求較低的軟體，一般按反向測試過程來測試就可以，對於安全性要求較高的軟體，應以正向測試過程為主，反向測試過程為輔。
　　三、常見的軟體安全性缺陷和漏洞
　　軟體的安全有非常多方面的內容，基本的安全問題是由軟體本身的漏洞造成的，以下介紹常見的軟體安全性缺陷和漏洞。
　　（1）緩衝區溢位
　　緩衝區溢位已成為軟體安全的頭號公敵，很多實際中的安全問題都與它有關。造成緩衝區溢位問題通常有下面兩種原因。①設計空間的轉換規則的校正問題。即缺乏對可測資料的校正，導致非法資料沒有在外部輸入層被檢查出來並丟棄。非法資料進入介面層和實現層後，因為它超出了介面層和實現層的相應測試空間或設計空間的範圍，從而引起溢出。②局部測試空間和設計空間不足。當合法資料進入後，因為程式實現層內相應的測試空間或設計空間不足，導致程式處理時出現溢出。
　　（2）加密弱點
　　這幾種加密弱點是不安全的：①使用不安全的密碼編譯演算法。密碼編譯演算法強度不夠，一些密碼編譯演算法甚至能夠用窮舉法破解。②加密資料時password是由偽隨機演算法產生的，而產生偽隨機數的方法存在缺陷，使password非常easy被破解。③身分識別驗證演算法存在缺陷。④客戶機和server時鐘未同步，給攻擊者足夠的時間來破解password或改動資料。⑤未對加密資料進行簽名，導致攻擊者能夠篡改資料。所以，對於加密進行測試時，必須針對這些可能存在的加密弱點進行測試。
　　（3）錯誤處理
　　普通情況下，錯誤處理都會返回一些資訊給使用者，返回的出錯資訊可能會被惡意使用者利用來進行攻擊，惡意使用者可以通過分析返回的錯誤資訊知道下一步要怎樣做才幹使攻擊成功。假設錯誤處理時調用了一些不該有的功能，那麼錯誤處理的過程將被利用。錯誤處理屬於異常空間內的處理問題，異常空間內的處理要盡量簡單，使用這條原則來設計能夠避免這個問題。但錯誤處理往往牽涉到易用性方面的問題，假設錯誤處理的提示資訊過於簡單，使用者可能會一頭霧水，不知道下一步該怎麼操作。所以，在考慮錯誤處理的安全性的同一時候，須要和易用性一起進行權衡。
　　（4）許可權過大
　　假設賦予過大的許可權，就可能導致僅僅有普通使用者權限的惡意使用者利用過大的許可權做出危害安全的操作。比如沒有對能操作的內容做出限制，就可能導致使用者能夠訪問超出規定範圍的其它資源。進行安全性測試時必須測試應用程式是否使用了過大的許可權，重點要分析在各種情況下應該有的許可權，然後檢查實際中是否超出了給定的許可權。許可權過大問題本質上屬於設計空間過大問題，所以在設計時要控制好設計空間，避免設計空間過大造成許可權過大的問題。
　　四、做好安全性測試的建議
　　很多軟體安全測試經驗告訴我們，做好軟體安全性測試的必要條件是：一是充分瞭解軟體安全性漏洞，二是評估安全風險，三是擁有高效的軟體安全測試技術和工具。
　　（1）充分瞭解軟體安全性漏洞
　　評估一個軟體系統的安全程度，須要從設計、實現和部署三個環節同一時候著手。我們先看一下CommonCriteria是怎樣評估軟體系統安全的。首先要確定軟體產品相應的ProtectionProfile（PP）。一個PP定義了一類軟體產品的安全特性模板。比如資料庫的PP、防火牆的PP等。然後，依據PP再提出詳細的安全功能需求，如使用者的身份認證實現。最後，確定安全性實體以及是怎樣滿足相應的安全功能需求的。因此，一個安全軟體的三個環節，哪個出問題都不行。
　　（2）安全性測試的評估
　　當做完安全性測試後，軟體是否可以達到預期的安全程度呢？這是安全性測試人員最關心的問題，因此須要建立對測試後的安全性評估機制。一般從下面兩個方面進行評估。①安全性缺陷資料評估。
　　假設發現軟體的安全性缺陷和漏洞越多，可能遺留的缺陷也越多。進行這類評估時，必須建立基準資料作為參照，否則評估起來沒有根據就無法得到正確的結論。②採用漏洞植入法來進行評估。漏洞植入法和可靠性測試裡的故障插入測試是同一道理，僅僅只是這裡是在軟體裡插入一些有安全隱患的問題。採用漏洞植入法時，先讓不參加安全測試的特定人員在軟體中預先植入一定數量的漏洞，最後測試完後看有多少植入的漏洞被發現，以此來評估軟體的安全性測試做得是否充分。
　　（3）採用安全測試技術和工具
　　可使用專業的具有特定功能的安全掃描軟體來尋找潛在的漏洞，將已經發生的缺陷納入缺陷庫，然後通過自己主動化測試方法來使用自己主動化缺陷庫進行轟炸測試。比如，使用一些可以類比各種攻擊的軟體來進行測試。
　　安全測試是用來驗證整合在軟體內的保護機制是否可以在實際中保護系統免受非法的侵入。一句通俗的話說：軟體系統的安全當然必須可以經受住正面的攻擊——可是它也必須可以經受住側面的和背後的攻擊