以下的文章主要描述的是測(cè)試應(yīng)用之對(duì)定制軟件應(yīng)用執(zhí)行安全測(cè)試，以下就是對(duì)測(cè)試應(yīng)用之對(duì)定制軟件應(yīng)用執(zhí)行安全測(cè)試的相關(guān)內(nèi)容的描述，希望在你今后的學(xué)習(xí)中會(huì)有所幫助。以下就是文章的主要內(nèi)容講述。

Gartner，IBM和NIST的研究表明在設(shè)計(jì)/開發(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)工作。如果他們有的話，可能會(huì)對(duì)開發(fā)軟件的真正成本表示驚訝。查找和修復(fù)安全漏洞的過程中存在直接成本和間接成本。如果有漏洞被找到并利用在產(chǎn)品應(yīng)用中，那么對(duì)品牌的損害將無法估量且難以彌補(bǔ)。

直接成本我們尚可以計(jì)算。而編寫修復(fù)代碼的平均成本是最易于計(jì)算的：

編寫修復(fù)代碼的平均成本=(程序員的人數(shù)×每人的日需成本)+ 修復(fù)的漏洞數(shù)量。除了這一成本，還有些額外成本需要考慮：

系統(tǒng)安全測(cè)試成本

執(zhí)行成本

系統(tǒng)成本

后期成本

其他成本，如項(xiàng)目管理，文檔和停工期成本等。

當(dāng)涉及關(guān)鍵任務(wù)和受矚目的應(yīng)用時(shí)，這些成本也會(huì)水漲船高，可是卻不能讓使用互聯(lián)網(wǎng)應(yīng)用的客戶看到這種變化，如網(wǎng)上銀行的頁面。

因此，對(duì)于企業(yè)而言，在發(fā)布進(jìn)入生產(chǎn)環(huán)境之前就尋找和修復(fù)應(yīng)用軟件漏洞是更為明智的選擇。雖然對(duì)威脅建模，設(shè)計(jì)還有架構(gòu)有助于確保不會(huì)有設(shè)計(jì)以內(nèi)的高級(jí)別漏洞出現(xiàn)，但是安全測(cè)試可以保障執(zhí)行安全設(shè)計(jì)的時(shí)候不會(huì)有漏洞。有若干技巧可在測(cè)試某應(yīng)用安全性時(shí)使用。這些技巧從簡(jiǎn)單的程序員驅(qū)動(dòng)型單元安全測(cè)試，到專業(yè)安全團(tuán)隊(duì)的滲透測(cè)試不等。

測(cè)試階段

典型的軟件開發(fā)測(cè)試一般出現(xiàn)在多迭代階段。這些階段都可能存在安全和彈性測(cè)試，而且可以用下列詞語來表述：

單元測(cè)試

整合性測(cè)試

質(zhì)量保障測(cè)試

用戶接受度測(cè)試

單元測(cè)試

程序員對(duì)自己編寫的代碼執(zhí)行單元測(cè)試。單元測(cè)試是對(duì)代碼的質(zhì)量進(jìn)行整體測(cè)試且具有一定的安全優(yōu)勢(shì)。單元測(cè)試有助于阻止漏洞進(jìn)入更高級(jí)的測(cè)試階段。由于程序員比其他人更了解自己的代碼，所以簡(jiǎn)單的單元測(cè)試就足以保證測(cè)試的有效性。

程序員需要記錄下自己的測(cè)試情況，因?yàn)槭謩?dòng)測(cè)試的步驟很容易被忘記。程序員可以在單元安全測(cè)試中找到的以下內(nèi)容：

邊界條件

整數(shù)溢出/整數(shù)下溢

路徑長(zhǎng)度 (URL，文件)

緩沖溢出

用C語言編寫代碼和編寫其內(nèi)存管理事務(wù)時(shí)，所有相關(guān)計(jì)算都應(yīng)該被測(cè)試

程序員也可以用模糊測(cè)試(Fuzzing)技巧執(zhí)行直接的安全測(cè)試。模糊測(cè)試，簡(jiǎn)而言之，是將隨機(jī)數(shù)據(jù)發(fā)送到程序所依賴的應(yīng)用程序界面，再確定它是否會(huì)，何時(shí)會(huì)損壞軟件。模糊安全測(cè)試通常通過多重迭代完成，而且如果在數(shù)據(jù)結(jié)構(gòu)的關(guān)鍵部位有針對(duì)性的變化則可以獲得更好的效果。模糊測(cè)試是許多程序員都樂于使用的方法。而它也是識(shí)別安全漏洞最便宜，最快捷和最有效的方法，即便是拿下具備成熟SDLC安全性和彈性的企業(yè)也是如此。

手動(dòng)源代碼審查

當(dāng)開發(fā)進(jìn)程中有足夠的代碼進(jìn)行審查時(shí)可進(jìn)行手動(dòng)源代碼審查。手動(dòng)源代碼審查通常僅限于尋找代碼級(jí)的可能導(dǎo)致安全漏洞的疏漏。代碼審查不是用來揭示以下內(nèi)容：

有關(guān)業(yè)務(wù)需求卻不能被安全執(zhí)行的問題

有關(guān)應(yīng)用特殊技術(shù)的選擇事項(xiàng)

可能導(dǎo)致漏洞的設(shè)計(jì)事項(xiàng)

源代碼審查通常不會(huì)擔(dān)憂漏洞被人利用。從審查中找到的結(jié)果會(huì)被通過其他方式找到的結(jié)果一樣對(duì)待。代碼審查對(duì)可用于非安全查找，只要它們有可能影響代碼的整體質(zhì)量。代碼審查通常不僅會(huì)導(dǎo)致安全測(cè)試認(rèn)證的問題，而且會(huì)導(dǎo)致無作用程式碼，冗余碼，不必要的復(fù)雜性或其他問題。所有查找出的結(jié)果都遵循自己的優(yōu)先性，而這些優(yōu)先性通常都被定義為企業(yè)內(nèi)部的“漏洞優(yōu)先矩陣”。漏洞報(bào)告通常包含一個(gè)特定的補(bǔ)救推薦措施以便程序員可以適當(dāng)對(duì)其進(jìn)行修復(fù)。

手動(dòng)代碼審查的成本比較高，因?yàn)樗O(shè)計(jì)許多手動(dòng)操作且需要安全專家進(jìn)行輔助審查。但是，就準(zhǔn)確性和質(zhì)量而言，手動(dòng)審查物有所值。它們可以幫助我們識(shí)別自動(dòng)靜態(tài)代碼分析器無法識(shí)別的邏輯漏洞。

源代碼審查通常被稱為“白盒”分析。這是因?yàn)檫@類審查對(duì)內(nèi)部設(shè)計(jì)，威脅模式和其他有關(guān)應(yīng)用的系統(tǒng)文檔都十分了解。而“黑盒”分析是從旁觀者的角度來審查應(yīng)用，因此沒有應(yīng)用的內(nèi)部情況有詳細(xì)了解。“灰盒”分析是介于黑盒與白盒之間的一種分析，我們稍后會(huì)對(duì)此再做介紹。#p#

代碼審查進(jìn)程

代碼審查進(jìn)程始于項(xiàng)目管理團(tuán)隊(duì)和開發(fā)團(tuán)隊(duì)，目的是確保有足夠的時(shí)間和預(yù)算分配給SDLC來執(zhí)行此類審查。所有程序員和審查員都應(yīng)該有權(quán)使用有利于執(zhí)行此類審查的工具。代碼審查進(jìn)程包括圖8.1中列出的四個(gè)高級(jí)步驟：

代碼審查的第一步是了解被執(zhí)行的應(yīng)用，該應(yīng)用的內(nèi)部設(shè)計(jì)以及威脅模式。了解這些可以極大地幫助我們識(shí)別代碼中的關(guān)鍵組件并將優(yōu)先權(quán)分配給它們。事實(shí)上，我們并不能保證每次都有足夠的時(shí)間對(duì)代碼進(jìn)行逐行審查。因此，非常有必要了解代碼的關(guān)鍵所在并確保這些關(guān)鍵部分可以被全面審查。

第二步是在優(yōu)先部分的基礎(chǔ)上對(duì)識(shí)別的關(guān)鍵部分進(jìn)行審查。這樣的審查可以由不同團(tuán)隊(duì)程序員來執(zhí)行。另一個(gè)方法是讓相應(yīng)開發(fā)團(tuán)隊(duì)的程序員對(duì)所有代碼執(zhí)行同級(jí)審查。 不管代碼審查是否完備，還是有必要將審查覆蓋到關(guān)鍵部分從而使程序員和安全專家都有機(jī)會(huì)看到這些部分。所有識(shí)別出的漏洞必須用企業(yè)的漏洞管理工具記錄在案，再對(duì)其分配合適的優(yōu)先權(quán)。審查者必須將推薦的修復(fù)方案和這些漏洞一起記錄下來以確保這些錯(cuò)誤不會(huì)進(jìn)入最后的生產(chǎn)代碼中。

代碼審查的第三部是與應(yīng)用代碼編寫者進(jìn)行協(xié)調(diào)，幫助他們執(zhí)行修復(fù)。這其中可能涉及已有的，可重復(fù)的安全測(cè)試組件的整合，或者它會(huì)提出代碼由簡(jiǎn)化繁的請(qǐng)求以及后續(xù)審查。

最后一步是學(xué)習(xí)審查周期，吸取改進(jìn)的部分。這樣可以讓下次代碼審查更有效。

要求進(jìn)行深層驅(qū)動(dòng)審查和分析的關(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的使用情況

由于手動(dòng)分析耗時(shí)費(fèi)力，企業(yè)還應(yīng)該部署自動(dòng)源代碼分析工具作為補(bǔ)充(但是不能替代手動(dòng)審查的作用)。

自動(dòng)源代碼分析

大中型企業(yè)不能保證每次執(zhí)行代碼審查時(shí)對(duì)所有應(yīng)用都逐一排查。相反，許多審查可能都依賴于自動(dòng)源代碼分析器的幫助。

典型的軟件開發(fā)優(yōu)先項(xiàng)包括日程，功能和質(zhì)量——在大多數(shù)情況下，它們的先后順序就是如此。時(shí)間和市場(chǎng)的雙重壓力對(duì)軟件之類和彈性都有負(fù)面影響，有時(shí)甚至?xí)七t軟件新功能的增加。

負(fù)責(zé)軟件開發(fā)的企業(yè)經(jīng)理通常都相信：對(duì)軟件質(zhì)量的偏重會(huì)增加開發(fā)成本并延遲項(xiàng)目。對(duì)于軟件質(zhì)量的研究則證明了這是悖論。具備成熟SDLC進(jìn)程的企業(yè)通常因軟件質(zhì)量和彈性所支付的額外費(fèi)用并不多，而從代碼改進(jìn)中節(jié)約的成本要大于因提高質(zhì)量而付出的成本。

靜態(tài)源代碼分析器支持用查找和列出代碼庫潛在安全漏洞的方式保護(hù)程序的開發(fā)。它們提供了大量有關(guān)代碼庫安全趨勢(shì)的分析報(bào)告，而這些報(bào)告可作為一種有效機(jī)制來收集指示進(jìn)程和軟件安全成熟度的矩陣。源代碼分析器的運(yùn)行速度極快，可以節(jié)約大量人力。自動(dòng)工具也為每個(gè)漏洞提供了風(fēng)險(xiǎn)級(jí)別，這樣有助于企業(yè)對(duì)補(bǔ)救措施進(jìn)行優(yōu)先。

更重要的是，自動(dòng)代碼分析器可以幫企業(yè)在SDLC中早一點(diǎn)發(fā)現(xiàn)未覆蓋的漏洞，這樣便可以節(jié)省開支。

1 自動(dòng)審查與手動(dòng)審查作比較

盡管自動(dòng)源代碼分析器可以在減少額外成本的情況下執(zhí)行審查，可以捕捉典型的漏洞，可以擴(kuò)展代碼還可以快速執(zhí)行重復(fù)任務(wù)，但它仍然存在不足。自動(dòng)工具會(huì)出現(xiàn)大量誤報(bào)的情況。有時(shí)可能會(huì)讓企業(yè)花上幾個(gè)月來調(diào)試工具以減少誤報(bào)，但是某些級(jí)別的誤報(bào)還是會(huì)存在。源代碼分析器在尋找業(yè)務(wù)邏輯漏洞方面的能力不足。某些自動(dòng)分析不能查探出的攻擊類型是復(fù)雜的信息泄露，設(shè)計(jì)漏洞，主觀漏洞，如假冒的跨站點(diǎn)請(qǐng)求，居心不良的競(jìng)態(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——識(shí)別安全漏洞和代碼漏洞，支持C，C++，C#和Java。

Compuware Xpediter——適合基于主框架的應(yīng)用，提供COBOL，PL/I，JCL， CICS，DB2，IMS和其他主流主框架語言的分析。

Fortigy 360——幫助程序員識(shí)別軟件安全漏洞，支持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——自動(dòng)源代碼分析，可以讓企業(yè)識(shí)別并消除軟件中的安全漏洞，支持Java，JSP，C/C++，C#，ASP.NET和VB.NET。

開源軟件——多語言

以下是用于源代碼分析的開源產(chǎn)品。

O2——開源模式集合，有助于Web應(yīng)用安全專家最大化自己的努力，通過自動(dòng)化應(yīng)用安全知識(shí)和工作流程，可以快速獲得應(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)容就是對(duì)測(cè)試應(yīng)用：對(duì)定制軟件應(yīng)用執(zhí)行安全測(cè)試的介紹，望你能有所收獲。

【編輯推薦】

1. 防火墻安全測(cè)試之?dāng)?shù)據(jù)包偵聽
2. 防火墻安全測(cè)試之漏洞掃描
3. 安全測(cè)試以及安全測(cè)試與滲透測(cè)試的區(qū)別
4. 在內(nèi)部應(yīng)用安全測(cè)試中使用模糊測(cè)試
5. 實(shí)戰(zhàn)Web安全測(cè)試之HTTP截?cái)?走私漏洞篇)