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