對定制軟件應用執行安全測試完整版
以下的文章主要描述的是測試應用之對定制軟件應用執行安全測試，以下就是對測試應用之對定制軟件應用執行安全測試的相關內容的描述，希望在你今后的學習中會有所幫助。以下就是文章的主要內容講述。
Gartner，IBM和NIST的研究表明在設計/開發階段清除應用的安全漏洞與在生產階段清除這些漏洞少花費30-60倍的成本。
在軟件開發生命周期內(SDLC)整合安全進程的關鍵目標是確保我們能查找并修復早期安全漏洞。
許多企業不了解尋找和修復軟件漏洞的成本，因為他們沒有跟蹤并權衡這項工作。如果他們有的話，可能會對開發軟件的真正成本表示驚訝。查找和修復安全漏洞的過程中存在直接成本和間接成本。如果有漏洞被找到并利用在產品應用中，那么對品牌的損害將無法估量且難以彌補。
直接成本我們尚可以計算。而編寫修復代碼的平均成本是最易于計算的：
編寫修復代碼的平均成本=(程序員的人數×每人的日需成本)+ 修復的漏洞數量。除了這一成本，還有些額外成本需要考慮：
系統安全測試成本
執行成本
系統成本
后期成本
其他成本，如項目管理，文檔和停工期成本等。
當涉及關鍵任務和受矚目的應用時，這些成本也會水漲船高，可是卻不能讓使用互聯網應用的客戶看到這種變化，如網上銀行的頁面。
因此，對于企業而言，在發布進入生產環境之前就尋找和修復應用軟件漏洞是更為明智的選擇。雖然對威脅建模，設計還有架構有助于確保不會有設計以內的高級別漏洞出現，但是安全測試可以保障執行安全設計的時候不會有漏洞。有若干技巧可在測試某應用安全性時使用。這些技巧從簡單的程序員驅動型單元安全測試，到專業安全團隊的滲透測試不等。
測試階段
典型的軟件開發測試一般出現在多迭代階段。這些階段都可能存在安全和彈性測試，而且可以用下列詞語來表述：
單元測試
整合性測試
質量保障測試
用戶接受度測試
單元測試
程序員對自己編寫的代碼執行單元測試。單元測試是對代碼的質量進行整體測試且具有一定的安全優勢。單元測試有助于阻止漏洞進入更高級的測試階段。由于程序員比其他人更了解自己的代碼，所以簡單的單元測試就足以保證測試的有效性。
程序員需要記錄下自己的測試情況，因為手動測試的步驟很容易被忘記。程序員可以在單元安全測試中找到的以下內容：
邊界條件
整數溢出/整數下溢
路徑長度 (URL，文件)
緩沖溢出
用C語言編寫代碼和編寫其內存管理事務時，所有相關計算都應該被測試
程序員也可以用模糊測試(Fuzzing)技巧執行直接的安全測試。模糊測試，簡而言之，是將隨機數據發送到程序所依賴的應用程序界面，再確定它是否會，何時會損壞軟件。模糊安全測試通常通過多重迭代完成，而且如果在數據結構的關鍵部位有針對性的變化則可以獲得更好的效果。模糊測試是許多程序員都樂于使用的方法。而它也是識別安全漏洞最便宜，最快捷和最有效的方法，即便是拿下具備成熟SDLC安全性和彈性的企業也是如此。
手動源代碼審查
當開發進程中有足夠的代碼進行審查時可進行手動源代碼審查。手動源代碼審查通常僅限于尋找代碼級的可能導致安全漏洞的疏漏。代碼審查不是用來揭示以下內容：
有關業務需求卻不能被安全執行的問題
有關應用特殊技術的選擇事項
可能導致漏洞的設計事項
源代碼審查通常不會擔憂漏洞被人利用。從審查中找到的結果會被通過其他方式找到的結果一樣對待。代碼審查對可用于非安全查找，只要它們有可能影響代碼的整體質量。代碼審查通常不僅會導致安全測試認證的問題，而且會導致無作用程式碼，冗余碼，不必要的復雜性或其他問題。所有查找出的結果都遵循自己的優先性，而這些優先性通常都被定義為企業內部的“漏洞優先矩陣”。漏洞報告通常包含一個特定的補救推薦措施以便程序員可以適當對其進行修復。
手動代碼審查的成本比較高，因為它設計許多手動操作且需要安全專家進行輔助審查。但是，就準確性和質量而言，手動審查物有所值。它們可以幫助我們識別自動靜態代碼分析器無法識別的邏輯漏洞。
源代碼審查通常被稱為“白盒”分析。這是因為這類審查對內部設計，威脅模式和其他有關應用的系統文檔都十分了解。而“黑盒”分析是從旁觀者的角度來審查應用，因此沒有應用的內部情況有詳細了解。“灰盒”分析是介于黑盒與白盒之間的一種分析，我們稍后會對此再做介紹。#p#
代碼審查進程
代碼審查進程始于項目管理團隊和開發團隊，目的是確保有足夠的時間和預算分配給SDLC來執行此類審查。所有程序員和審查員都應該有權使用有利于執行此類審查的工具。代碼審查進程包括圖8.1中列出的四個高級步驟：
代碼審查的第一步是了解被執行的應用，該應用的內部設計以及威脅模式。了解這些可以極大地幫助我們識別代碼中的關鍵組件并將優先權分配給它們。事實上，我們并不能保證每次都有足夠的時間對代碼進行逐行審查。因此，非常有必要了解代碼的關鍵所在并確保這些關鍵部分可以被全面審查。
第二步是在優先部分的基礎上對識別的關鍵部分進行審查。這樣的審查可以由不同團隊程序員來執行。另一個方法是讓相應開發團隊的程序員對所有代碼執行同級審查。 不管代碼審查是否完備，還是有必要將審查覆蓋到關鍵部分從而使程序員和安全專家都有機會看到這些部分。所有識別出的漏洞必須用企業的漏洞管理工具記錄在案，再對其分配合適的優先權。審查者必須將推薦的修復方案和這些漏洞一起記錄下來以確保這些錯誤不會進入最后的生產代碼中。
代碼審查的第三部是與應用代碼編寫者進行協調，幫助他們執行修復。這其中可能涉及已有的，可重復的安全測試組件的整合，或者它會提出代碼由簡化繁的請求以及后續審查。
最后一步是學習審查周期，吸取改進的部分。這樣可以讓下次代碼審查更有效。
要求進行深層驅動審查和分析的關鍵組件有：
用戶身份驗證和授權驗證
數據保護
從受信任的數據源接受并處理數據
數據驗證
涉及異常條件處理的代碼
操作系統資源和網絡的使用
低端架構代碼
嵌入式軟件組件
有問題的API的使用情況
由于手動分析耗時費力，企業還應該部署自動源代碼分析工具作為補充(但是不能替代手動審查的作用)。
自動源代碼分析
大中型企業不能保證每次執行代碼審查時對所有應用都逐一排查。相反，許多審查可能都依賴于自動源代碼分析器的幫助。
典型的軟件開發優先項包括日程，功能和質量——在大多數情況下，它們的先后順序就是如此。時間和市場的雙重壓力對軟件之類和彈性都有負面影響，有時甚至會推遲軟件新功能的增加。
負責軟件開發的企業經理通常都相信：對軟件質量的偏重會增加開發成本并延遲項目。對于軟件質量的研究則證明了這是悖論。具備成熟SDLC進程的企業通常因軟件質量和彈性所支付的額外費用并不多，而從代碼改進中節約的成本要大于因提高質量而付出的成本。
靜態源代碼分析器支持用查找和列出代碼庫潛在安全漏洞的方式保護程序的開發。它們提供了大量有關代碼庫安全趨勢的分析報告，而這些報告可作為一種有效機制來收集指示進程和軟件安全成熟度的矩陣。源代碼分析器的運行速度極快，可以節約大量人力。自動工具也為每個漏洞提供了風險級別，這樣有助于企業對補救措施進行優先。
更重要的是，自動代碼分析器可以幫企業在SDLC中早一點發現未覆蓋的漏洞，這樣便可以節省開支。
1 自動審查與手動審查作比較
盡管自動源代碼分析器可以在減少額外成本的情況下執行審查，可以捕捉典型的漏洞，可以擴展代碼還可以快速執行重復任務，但它仍然存在不足。自動工具會出現大量誤報的情況。有時可能會讓企業花上幾個月來調試工具以減少誤報，但是某些級別的誤報還是會存在。源代碼分析器在尋找業務邏輯漏洞方面的能力不足。某些自動分析不能查探出的攻擊類型是復雜的信息泄露，設計漏洞，主觀漏洞，如假冒的跨站點請求，居心不良的競態條件和多步驟進程攻擊。
2 有償/免費的源代碼分析器
下面是一些源代碼分析器，包括有償的，免費的和開源的軟件。
有償的軟件——多語言
Armorize Codesecure——帶網頁界面的工具，多種嵌入式語言，支持ASP.NET, VB.NET, C#, JAVA/J2EE, JSP, EJB, PHP, Classic ASP和VBScript。
Coverity Software Integrity——識別安全漏洞和代碼漏洞，支持C，C++，C#和Java。
Compuware Xpediter——適合基于主框架的應用，提供COBOL，PL/I，JCL， CICS，DB2，IMS和其他主流主框架語言的分析。
Fortigy 360——幫助程序員識別軟件安全漏洞，支持C/C++，NET，Java, JSP, ASP.NET, ColdFusion, Classic ASP, PHP, VB6, VBScript, JavaScript, PL/SQL, T-SQL和COBOL以及配置文件。
KlockworkInsight和適合Java程序員的Klockwork ——提供安全漏洞的檢查以及架構的分析，支持C，C++，C#和Java。
Ounce Labs——自動源代碼分析，可以讓企業識別并消除軟件中的安全漏洞，支持Java，JSP，C/C++，C#，ASP.NET和VB.NET。
開源軟件——多語言
以下是用于源代碼分析的開源產品。
O2——開源模式集合，有助于Web應用安全專家最大化自己的努力，通過自動化應用安全知識和工作流程，可以快速獲得應用安全文件的可視性。
RATS(安全粗審)——可以掃描用C，C++，Perl，PHP和Python源代碼。
YASCA——基于插件的掃描任意文件類型的架構，具備掃描C/C++，Java，JavaScript，ASP，PHP，HTML/CSS，ColdFusion，COBOL和其他文件類型的插件;融合了其他掃描器，包括FindBugs，Jlint，PMD和Pixy。
支持.NET的
FxCop——用于編譯CIL的Microsoft.NET程序的免費靜態分析，獨立且融合了一些微軟Visual Studio 版本。
StyleCop——分析C#源代碼以加強風格和連貫性;可在微軟Visual Studio內部運行或整合到MSBuild 項目中。
支持Java的
Checkstyle——除了可進行一些靜態代碼分析，還可以用來展示違反配置代碼標準的示例。
FindBugs——馬里蘭大學研發的用于Java語言的開源靜態代碼分析器(基于Jakarta BCEL)。
PMD——基于套件的Java源代碼靜態規則。以上的相關內容就是對測試應用：對定制軟件應用執行安全測試的介紹，望你能有所收獲。
【編輯推薦】
