基于Mozilla的安全性漏洞再修復(fù)經(jīng)驗(yàn)研究

1、基于mozilla的安全性漏洞再修復(fù)經(jīng)驗(yàn) 研究張凱孫小兵彭鑫趙文耘復(fù)旦大學(xué)軟件學(xué)院復(fù)旦大學(xué)上海市數(shù)據(jù)科學(xué)重點(diǎn)實(shí)驗(yàn)室摘要：相較于其他類型的漏洞，安全性漏洞更容易發(fā)生再修復(fù)，這使得安全性漏洞需 要更多的開發(fā)資源，從而增加了這些安全性漏洞修復(fù)的成木。因此，減少安全性 漏洞再修復(fù)的發(fā)生的重要性不言而喻。對(duì)安全性漏洞再修復(fù)的經(jīng)驗(yàn)研究有助于減 少再修復(fù)的發(fā)生。首先，通過(guò)對(duì)mozilla工程中一些發(fā)生再修復(fù)的安全性漏洞的 安全性漏洞類型、發(fā)生再修復(fù)的原因、再修復(fù)的次數(shù)、修改的提交數(shù)、修改的文 件數(shù)、修改的代碼行數(shù)的增減、初始修復(fù)和再修復(fù)的對(duì)比等數(shù)據(jù)進(jìn)行分析，發(fā)現(xiàn) 了安全性漏洞發(fā)牛再修復(fù)是普遍存在的，且與漏洞

2、發(fā)牛原因的識(shí)別的復(fù)雜程度 和漏洞修復(fù)的復(fù)雜程度這兩個(gè)因素有關(guān);其次，初始修復(fù)涉及的文件、代碼的集 屮程度是影響再修復(fù)的原因z-,而使用更復(fù)雜、更有效的修復(fù)過(guò)程可有效避免 再修復(fù)的發(fā)生;最后，總結(jié)了幾種安全性漏洞發(fā)生再修復(fù)的原因，使開發(fā)人員有 效地識(shí)別不同類型的安全性漏洞再修復(fù)。關(guān)鍵詞： 安全性漏洞;再修復(fù);漏洞修復(fù);經(jīng)驗(yàn)研究;作者簡(jiǎn)介：張凱（1993-）,男，碩士生，主要研究方向?yàn)檐浖S護(hù)；作者簡(jiǎn)介：孫小兵（1985-），男，博士，主要研究方向?yàn)檐浖治?、維護(hù)與演 化；作者簡(jiǎn)介:彭鑫（1979-）,男，博-上，教授，ccf高級(jí)會(huì)員，主要研究方向?yàn)樾枨蠊こ?、自適應(yīng)軟件、軟件產(chǎn)品線、軟件維護(hù)、逆向

3、工 程;e-mail:pcngxinfudan. cdu. cn;作者簡(jiǎn)介：趙文耘（1964-），男，碩士，教授，ccf高級(jí)會(huì)員，主要研究方向 為軟件復(fù)用、軟件產(chǎn)品線、軟件工程。收稿日期:2016-10-07基金：國(guó)家自然科學(xué)基金(61402396, 61370079)empirical study of reopened security bugs on mozillazhang kai sun xiao-bing peng xin zhao wen-yunabstract：compared to other types of bugs, securi ty bug reopens more

4、 often, moreover, they need more development resources to fix it, which adds an extra cost to fix them. hence, the empirical study of reopened security bugs is important. our study collected the reopened security bugs from the mozilla project, and analyzed them from the times of their reopening and

5、commits, files which were modified to fix them, lines of added and deleted code, and compcirison of the original fixing and reopened fixing. the empiriccil resuits show that security bug reopening often happen and it rclates to the complexity of recognizing the reason that a security bug happens and

6、 fixing bugs. in addition, the locality of the files and code in the original security bug f ixi ng is one of the causes to in flue nee i ts re-fix ing for bug reopens, and using more complex and effective fixing process can help reduce the security bug reopens. finally, we summarized several causes

7、 for security bug reopens to help developers more easily identify the reopens of different types of security bugs.keyword：security bug; reopens; bug fixing; empirical study;received： 2016-10-071引言在軟件開發(fā)和維護(hù)過(guò)程中，開發(fā)人員常常遇到程序運(yùn)行狀態(tài)與預(yù)期不符的情況， 如輸出值不正確、程序死機(jī)、數(shù)據(jù)丟失等，這種現(xiàn)彖來(lái)源于程序的漏洞（bug）。 開發(fā)人員如果在程序中發(fā)現(xiàn)漏洞的存在，則必定會(huì)停止開發(fā)工作來(lái)修

8、復(fù)漏洞， 或者投入專門的人力和物力進(jìn)行漏洞修復(fù)。不論是哪種應(yīng)對(duì)方案，都會(huì)不可避免 地消耗開發(fā)資源，使開發(fā)成木變得更加昂貴，直接導(dǎo)致開發(fā)軟件的利潤(rùn)變得更 小，軟件競(jìng)爭(zhēng)力下降。在眾多漏洞類型中，安全性漏洞是軟件開發(fā)者在軟件維護(hù)與更新的過(guò)程中重要 的關(guān)注點(diǎn)之一1-3。安全性漏洞是指能被攻擊者利用，以在計(jì)算機(jī)系統(tǒng)中獲取 未經(jīng)授權(quán)的訪問(wèn)或進(jìn)行超岀權(quán)限的行為的一種軟件漏洞，會(huì)導(dǎo)致安全性缺陷， 使計(jì)算機(jī)系統(tǒng)陷入危險(xiǎn)z屮。安全性漏洞不一定會(huì)導(dǎo)致程序崩潰或停止運(yùn)行，但 其一旦被攻擊者利用，則可能會(huì)造成不可挽回的損失。有時(shí)，漏洞的修復(fù)不能一蹴而就，開發(fā)人員也不可避免地會(huì)發(fā)生修復(fù)漏洞錯(cuò)誤 的情況。開發(fā)人員完成漏洞修

9、復(fù)之后會(huì)關(guān)閉漏洞，但如果發(fā)現(xiàn)這個(gè)漏洞未被完全 修復(fù)，為了使之修復(fù)正確，需要重新打開(reopen)該漏洞來(lái)對(duì)其進(jìn)行再修復(fù)， 以避免在開發(fā)人員自認(rèn)為修復(fù)正確的情況下，安全性漏洞卻悄悄造成重大的損 失o zaman等人發(fā)現(xiàn)，安全性漏洞相比于其他漏洞更常發(fā)生再修復(fù)。因此，對(duì) 安全性漏洞的再修復(fù)進(jìn)行研究，找出再修復(fù)與初次修復(fù)的隱含關(guān)系，對(duì)于安全 性漏洞再修復(fù)的預(yù)測(cè)和提供修復(fù)意見十分重要。本文主要通過(guò)對(duì)mozillal程中發(fā)生再修復(fù)的安全性漏洞的各項(xiàng)數(shù)據(jù)進(jìn)行統(tǒng)計(jì) 分析，找到安全性漏洞在再修復(fù)時(shí)存在的各種修復(fù)規(guī)律，如修改文件和代碼較 為分散的安全性漏洞較容易發(fā)生再修復(fù)，一些類型的安全性漏洞再修復(fù)會(huì)包含 初

10、始修復(fù)的修改模式、修復(fù)過(guò)程和修改的文件與代碼。這些規(guī)律可為開發(fā)安全性 漏洞再修復(fù)預(yù)測(cè)和自動(dòng)化修復(fù)的工具提供經(jīng)驗(yàn)支持。本文第2節(jié)介紹經(jīng)驗(yàn)研究的一些背景知識(shí);第3節(jié)介紹研究的設(shè)計(jì)，包括數(shù)據(jù)來(lái) 源、研究的數(shù)據(jù)和數(shù)據(jù)分類方式;第4節(jié)給出對(duì)數(shù)據(jù)分析的結(jié)果以及得到的規(guī)律; 第5節(jié)介紹相關(guān)工作;最后總結(jié)全文。2背景知識(shí)2. 1漏洞生命周期一個(gè)漏洞通常遵循圖1 5所示的生命周期。圖1漏洞生命周期下載原圖一個(gè)漏洞在被發(fā)現(xiàn)后會(huì)被發(fā)現(xiàn)者報(bào)告出來(lái)，此時(shí)漏洞發(fā)牛的根木原因、漏洞類型 等信息還不確定，這便是未確認(rèn)(u7c0mftrmed)階段。下一階段就是通過(guò)錯(cuò)誤 信息對(duì)漏洞發(fā)生的原因進(jìn)行分析，如果是新的漏洞，就進(jìn)入這個(gè)

11、新漏洞的各種 信息獲取階段(new and assigned);如果與已有漏洞相同，就標(biāo)注為重復(fù) (duplicate)。獲取完漏洞信息之后，即對(duì)漏洞進(jìn)行修復(fù)，修復(fù)完成則進(jìn)入解決 (resolved)階段。解決階段之后就是對(duì)修復(fù)進(jìn)行驗(yàn)證(verified)的階段，該 階段主要負(fù)責(zé)驗(yàn)證修復(fù)是否正確，最后關(guān)閉(closed)漏洞。在解決階段和關(guān)閉階段之后，都有可能因?yàn)樾迯?fù)不正確或不完整需要重新打開 (reopened)漏洞來(lái)重新對(duì)其進(jìn)行修復(fù)。這個(gè)重新打開階段承擔(dān)的工作就是木文 要研究的安全性漏洞再修復(fù)。2. 2安全性漏洞分類osvdb (open sourced vulnerability dat

12、abase)是一個(gè)為安全性漏洞提供準(zhǔn)確、 詳細(xì)、及時(shí)、公正的信息的獨(dú)立且開源的數(shù)據(jù)庫(kù)。osvdb為安全性漏洞分類提供 了參考。結(jié)合對(duì)數(shù)據(jù)的分析及osvdb的參考分類，我們將研究中的安全性漏洞分 為7類回:信息泄露、拒絕服務(wù)攻擊、跨站腳本攻擊(xss)、緩存溢岀、內(nèi)存 泄露、使用非法內(nèi)存及其他。信息泄露是指在程序運(yùn)行過(guò)程中，一些數(shù)據(jù)應(yīng)該被保護(hù)或加密，未經(jīng)授權(quán)的用 戶不能得到這些數(shù)據(jù)，但這些數(shù)據(jù)在某些安全性漏洞存在的情況下會(huì)被惡意用 戶獲取，從而給系統(tǒng)或正常用戶造成損失。拒絕服務(wù)攻擊是指使目標(biāo)電腦的網(wǎng)絡(luò)或資源過(guò)載或耗盡，從而使服務(wù)暫時(shí)中斷 或停止，導(dǎo)致其對(duì)客戶不可用?？缯灸_本攻擊是代碼注入的一種，

13、指在網(wǎng)站應(yīng)用程序中存在安全性漏洞惡意用 戶通過(guò)這些漏洞在網(wǎng)頁(yè)中插入惡意代碼，而當(dāng)用戶進(jìn)入、使用該網(wǎng)站時(shí)惡意代碼 會(huì)被執(zhí)行。惡意代碼包括javascript, java等。惡意代碼執(zhí)行完之后，可能會(huì) 獲取更大的權(quán)限，竊取隱私信息等，給正常用戶造成影響和損失。程序在運(yùn)行時(shí)都會(huì)分配一定大小的緩沖區(qū)，而當(dāng)寫入的內(nèi)容超過(guò)緩沖區(qū)大小時(shí)， 就會(huì)造成緩存溢出。若這種緩存溢出未被系統(tǒng)或程序察覺，則攻擊者可能破壞程 序的運(yùn)行、獲得程序甚至系統(tǒng)的控制權(quán)，進(jìn)而運(yùn)行惡意代碼進(jìn)行一些破壞性的操 作。內(nèi)存泄露是指在程序中一些已經(jīng)使用過(guò)且不再需要的內(nèi)存未被釋放，使得程序 的可用內(nèi)存越來(lái)越少，最后導(dǎo)致程序因缺少內(nèi)存而使部分功能

14、被迫停止，甚至 程序崩潰。這種內(nèi)存的減少并不是物理上的內(nèi)存減少，而是可分配使用的內(nèi)存數(shù) 量越來(lái)越少。程序中經(jīng)常使用指針來(lái)儲(chǔ)存和操作數(shù)據(jù)，但如果這些指針是空指針、指向地址己 經(jīng)被釋放或指向程序堆棧之外即不屬于程序的內(nèi)存地址，則會(huì)使程序停止運(yùn)行 或崩潰，這就是使用非法內(nèi)存。通過(guò)這些安全性漏洞分類，可針對(duì)每類安全性漏洞進(jìn)行分析，研究各類安全性 漏洞自身的特點(diǎn)。2.3安全性漏洞的修改模式安全性問(wèn)題通常是因?yàn)楣粽叻欠▽?duì)數(shù)據(jù)進(jìn)行訪問(wèn)而引起的。在對(duì)安全性漏洞的 分析中，安全性漏洞的修復(fù)大多并不復(fù)雜，根據(jù)程序系統(tǒng)對(duì)數(shù)據(jù)處理的3個(gè)階 段(數(shù)據(jù)的預(yù)處理、數(shù)據(jù)處理、數(shù)據(jù)確保)對(duì)安全性漏洞的修復(fù)，總結(jié)了如表1 所列

15、的一些修改模式。表1安全性漏洞的修改模式下載原表在數(shù)據(jù)進(jìn)入程序階段，即數(shù)據(jù)預(yù)處理階段，通常會(huì)對(duì)數(shù)據(jù)做一些檢測(cè)和篩選, 來(lái)防止外部數(shù)據(jù)對(duì)程序進(jìn)行攻擊。在數(shù)據(jù)處理階段，即稈序?qū)?shù)據(jù)進(jìn)行操作的階段，需要保證數(shù)據(jù)被正確、安全地 處理。在數(shù)據(jù)被程序處理完成后，系統(tǒng)通常會(huì)根據(jù)這些數(shù)據(jù)輸出一些我們想要的結(jié)果， 而這些結(jié)果也可能因?yàn)樘幚磉^(guò)程的不理想而出現(xiàn)一些錯(cuò)誤。針對(duì)這種情況，需耍 進(jìn)行數(shù)據(jù)確保工作，以防止錯(cuò)誤的處理結(jié)果對(duì)程序造成影響。在數(shù)據(jù)確保階段， 最常用的修改模式是添加if模塊，對(duì)結(jié)果進(jìn)行判斷，確認(rèn)其為正確合法的結(jié) 果。安全性漏洞的修改模式相較于其他類型的漏洞更為簡(jiǎn)單，通常是針對(duì)數(shù)據(jù)的修 改。安全性漏洞

16、的修改模式不涉及對(duì)軟件功能性的修改，只是對(duì)可能產(chǎn)生安全性 問(wèn)題的數(shù)據(jù)在程序傳播的各個(gè)階段進(jìn)行檢查、確認(rèn)，針對(duì)不同的安全問(wèn)題與傳播 階段添加相應(yīng)的防護(hù)機(jī)制，使數(shù)據(jù)的使用變得更加安全。同時(shí)，安全性漏洞的修 改模式更具通用性，能夠?qū)⑾嗤男薷哪Ｊ綉?yīng)用于不同的安全性漏洞的修復(fù)， 而非安全性漏洞則難以總結(jié)出一些統(tǒng)一的修改模式，只能針對(duì)不同的功能模塊 得出不同的修改方法。針對(duì)以上修改模式，可以觀察安全性漏洞再修復(fù)與初始修復(fù)使用的修改模式之 間的區(qū)別和聯(lián)系。3研究設(shè)計(jì)本文的研究主要圍繞以下兒個(gè)問(wèn)題展開：仃)安全性漏洞再修復(fù)的發(fā)生是否頻繁，以及與什么因素有關(guān)？(2) 哪種類型的安全性漏洞容易發(fā)生再修復(fù)且修復(fù)的

17、難度較大？(3) 初始修復(fù)與再修復(fù)在修改模式、修復(fù)過(guò)程、修改內(nèi)容方面有什么聯(lián)系?3.1數(shù)據(jù)來(lái)源 本文選定mozilla作為研究安全性漏洞再修復(fù)的數(shù)據(jù)來(lái)源，它維護(hù)的全部都是 mozilla產(chǎn)品的安全性漏洞，且信息全面、清晰，還能在git上找到對(duì)應(yīng)的提交 信息，使得研究數(shù)據(jù)豐富且全面。在對(duì)安全性漏洞的修復(fù)工作屮，moz訂la維護(hù)了一個(gè)安全性漏洞管理的社區(qū)，管 理了 2005年至今mozilla發(fā)現(xiàn)的所有安全性漏洞的相關(guān)信息。漏洞報(bào)告中包含許多信息，其中對(duì)研究有用的是以下兒類信息:漏洞id、漏洞描 述、漏洞修改歷史記錄、漏洞修復(fù)評(píng)論。在漏洞修復(fù)評(píng)論中，可以了解到修復(fù)人員的思考過(guò)程，從中得岀該安全性漏

18、洞 產(chǎn)生的原因、修復(fù)時(shí)對(duì)錯(cuò)誤信息的分析、使用該種修復(fù)方式的原因、對(duì)漏洞再修 復(fù)的原因、修復(fù)完成后進(jìn)行了何種測(cè)試等信息。通過(guò)對(duì)這些信息進(jìn)行分析，明確 了安全性漏洞修復(fù)的全過(guò)程，從而得出安全性漏洞的類型、漏洞再修復(fù)的原因、 漏洞每次修復(fù)使用的修復(fù)方式及原因、每次修復(fù)之間的關(guān)系等。漏洞修改歷史記錄（見圖2）中包含在每個(gè)吋間點(diǎn)該漏洞處于何種狀態(tài)的信息， 圖2屮表的第5列出現(xiàn)“reopen”表示該安全性漏洞被再修復(fù)，而在接下來(lái)的狀 態(tài)中第5列出現(xiàn)“fixed”則表示該再修復(fù)完成。圖2 bug修改歷史下載原圖對(duì)安全性漏洞再修復(fù)進(jìn)行分析時(shí)，每次修復(fù)吋代碼的提交信息是必不可少的。mozilla將他們的項(xiàng)目提交

19、到git上，通過(guò)git可以得到mozilla工程每次提交 的漏洞id、代碼、提交者、提交時(shí)間、修改的文件、本次提交與上次提交的代 碼更改信息、修改相關(guān)信息等。但是，git上的moz訂la工程只持續(xù)到2011年, 因此能得到的提交信息年份為2005-201 lo通過(guò)mozilla安全性漏洞社區(qū)和git 項(xiàng)目數(shù)據(jù)，總共獲取到48個(gè)可用的發(fā)生過(guò)再修復(fù)的安全性漏洞的相關(guān)數(shù)據(jù)，這 些安全性漏洞的id范圍為312278-672485。3.2研究?jī)?nèi)容對(duì)這些安全性漏洞數(shù)據(jù)的分析主要包括3方面:漏洞的整體情況、初始修復(fù)和再 修復(fù)的對(duì)比數(shù)據(jù)、修復(fù)過(guò)程中用到的數(shù)據(jù)。漏洞的整體情況數(shù)據(jù)包括:漏洞的id,漏洞的類型，發(fā)

20、生再修復(fù)的原因，在gil 上這個(gè)漏洞的修復(fù)提交的總次數(shù)，所有修改的文件數(shù)，所有修改增加和減少的 代碼行數(shù)，發(fā)生再修復(fù)的次數(shù)。這些數(shù)據(jù)有助于分析安全性漏洞的慕本信息中隱 含的修復(fù)規(guī)律。初始修復(fù)與再修復(fù)的對(duì)比數(shù)據(jù)包括:兩次修復(fù)時(shí)間的長(zhǎng)短對(duì)比，兩次修復(fù)使用的 修改模式的對(duì)比，修改者的對(duì)比，兩次修復(fù)使用的修復(fù)過(guò)程的對(duì)比，兩次修復(fù) 修改的文件和文件中修改內(nèi)容的對(duì)比。通過(guò)這些修復(fù)的對(duì)比數(shù)據(jù)可以得到再修復(fù) 和初始修復(fù)之間的關(guān)系，可通過(guò)初始修復(fù)推斷再修復(fù)的修改模式、修改文件與內(nèi) 容、修復(fù)時(shí)需要注意的事項(xiàng)，從而提供更方便的再修復(fù)方法。而通過(guò)修復(fù)過(guò)程的數(shù)據(jù)（如評(píng)論、提交的代碼）對(duì)比，可以得到修復(fù)者的思路， 并可從

21、中找出安全性漏洞類型、再修復(fù)原因、修改模式、修復(fù)過(guò)程等。以上兩方 面數(shù)據(jù)，有些通過(guò)對(duì)修復(fù)過(guò)程中的數(shù)據(jù)進(jìn)行統(tǒng)計(jì)和分析獲得。木文研究通過(guò)兩種方式進(jìn)行分類:安全性漏洞的類型和安全性漏洞再修復(fù)的原 因。根據(jù)安全性漏洞的分類方式，可以統(tǒng)計(jì)安全性漏洞再修復(fù)發(fā)生的次數(shù)、再修復(fù)的 原因、這類安全性漏洞提交的總次數(shù)、總的文件修改數(shù)、增加的代碼行數(shù)和刪除 的代碼行數(shù)。在這些數(shù)據(jù)的支持下，對(duì)以下問(wèn)題進(jìn)行研究:安全性漏洞整體情況 的分析;不同類型的安全性漏洞較容易發(fā)牛哪種再修復(fù);不同類型的安全性漏洞 在修改時(shí)修改文件、修改的代碼數(shù)量等有什么規(guī)律。通過(guò)對(duì)安全性漏洞再修復(fù)的原因進(jìn)行分類，收集初始修復(fù)與再修復(fù)兩方面的數(shù) 據(jù)

22、:使用的修改模式，修復(fù)過(guò)程，修復(fù)所用的時(shí)間，修改者，兩次修改對(duì)文件及 代碼的影響。通過(guò)收集到的數(shù)據(jù)，研究如下問(wèn)題:安全性漏洞再修復(fù)的原因;再修 復(fù)和初始修復(fù)使用的修復(fù)過(guò)程有什么聯(lián)系;兩次修復(fù)的修改時(shí)間和修改者有什么 聯(lián)系;兩次修復(fù)使用的修改模式有什么聯(lián)系;兩次修復(fù)修改的文件和內(nèi)容有什么 聯(lián)系。4數(shù)據(jù)分析4.1基礎(chǔ)數(shù)據(jù)統(tǒng)計(jì)實(shí)驗(yàn)共收集到721條安全性漏洞信息和48條發(fā)牛再修復(fù)的安全性漏洞。在 mozillal程中，安全性漏洞發(fā)生再修復(fù)的概率約為6. 7%,再修復(fù)的概率較高 i41o安全性漏洞在所有id和時(shí)間段都有發(fā)生再修復(fù)，由此可見，安全性漏洞發(fā)生再 修復(fù)是一個(gè)普遍存在且發(fā)生概率比較高的問(wèn)題。通過(guò)

23、對(duì)安全性漏洞再修復(fù)的信息 進(jìn)行分析，找到減少再修復(fù)、預(yù)測(cè)再修復(fù)、幫助再修復(fù)的方法，有助于提高程序 的安全性，減少開發(fā)、維護(hù)的資源消耗，使得程序員在對(duì)安全性漏洞進(jìn)行修復(fù)時(shí) 更加全而、正確，減少對(duì)安全性漏洞再次修復(fù)的次數(shù)。如表2所列，在48個(gè)發(fā)生再修復(fù)的安全性漏洞中，37個(gè)發(fā)生了 1次再修復(fù)，10 個(gè)發(fā)生了 2次再修復(fù)，只有1個(gè)發(fā)生了 3次再修復(fù)，未見超過(guò)3次的再修復(fù)。在 修復(fù)安全性漏洞時(shí)，發(fā)牛1次再修復(fù)可能是對(duì)漏洞的理解有遺漏;發(fā)牛2次再修 復(fù)就需要程序員特別注意自己的修復(fù)以及對(duì)漏洞的理解是否正確;唯一一次發(fā)生 了 3次再修復(fù)的漏洞是對(duì)漏洞進(jìn)行登記和測(cè)試，因此通常情況下不會(huì)發(fā)生超過(guò)2 次的再修復(fù)

24、。多次發(fā)生再修復(fù)不僅會(huì)對(duì)資源造成浪費(fèi)，還會(huì)加大系統(tǒng)的危險(xiǎn)性, 給攻擊者更多機(jī)會(huì)。表2安全性漏洞修復(fù)基礎(chǔ)數(shù)據(jù)統(tǒng)計(jì)下載原表發(fā)生2次再修復(fù)的安全性漏洞大多是緩存溢出，發(fā)生1次再修復(fù)的大多是跨站腳 本攻擊，其他的比例都比較接近。而這兒種類型的安全性漏洞git提交的平均次 數(shù)都比較接近，使用非法內(nèi)存修改的文件數(shù)最多，內(nèi)存泄露最少。在減少和增加 的代碼行數(shù)方面，內(nèi)存泄露和緩存溢岀分別為減少和增加代碼行最多的，緩存 溢出和內(nèi)存泄露分別為減少和增加代碼行最少的。緩存溢出和內(nèi)存泄露雖然涉及的文件數(shù)較少，但是修改的代碼行數(shù)卻較多，說(shuō) 明這兩類安全性漏洞問(wèn)題比較集中，修復(fù)時(shí)所涉及功能的關(guān)聯(lián)性比較強(qiáng)。而使用 非法內(nèi)存

25、和跨站腳木攻擊涉及的文件較多，但是修改的代碼行數(shù)較少，說(shuō)明這 兩種安全性漏洞涉及的功能較為分散，修改的文件范圍較廣，修復(fù)吋較容易有 遺漏，考慮得不夠全面。4.2安全性漏洞再修復(fù)的原因在對(duì)數(shù)據(jù)進(jìn)行分析后，得到以下兒個(gè)發(fā)生再修復(fù)的原因:加強(qiáng)漏洞填補(bǔ)（范圍加 強(qiáng)、強(qiáng)度加強(qiáng)）；減弱漏洞的填補(bǔ);填補(bǔ)原來(lái)沒有考慮到的漏洞（線性關(guān)系、并列 關(guān)系）；對(duì)修復(fù)進(jìn)行登記或測(cè)試；以前修復(fù)無(wú)效或錯(cuò)誤而重新修復(fù);懷疑修復(fù)造成 了錯(cuò)誤，后來(lái)發(fā)現(xiàn)不是（誤診）。實(shí)驗(yàn)中統(tǒng)計(jì)的48個(gè)發(fā)生了再修復(fù)的安全性漏洞中，每種類型的再修復(fù)數(shù)量如表 3所列。表3再修復(fù)類型統(tǒng)計(jì)下載原表從統(tǒng)計(jì)數(shù)據(jù)可知，除了減弱漏洞的修復(fù)數(shù)量較少以外，其他再修復(fù)的原

26、因數(shù)都 比較平均，再修復(fù)時(shí)一般會(huì)修復(fù)得比較適度或未修復(fù)完全，修復(fù)過(guò)強(qiáng)的情況比 較少。修復(fù)過(guò)強(qiáng)則表示安全性漏洞發(fā)牛的原因分析正確，且修復(fù)方式也正確，只 是限制過(guò)于強(qiáng)烈，避免這種再修復(fù)最好的方法是衡量好限制的強(qiáng)度與影響。而在 填補(bǔ)原來(lái)未考慮到的漏洞屮，線性關(guān)系的安全性漏洞也比較少，這種再修復(fù)的 發(fā)生是對(duì)數(shù)據(jù)源頭判斷得不準(zhǔn)確或未考慮數(shù)據(jù)的來(lái)源，修改比較簡(jiǎn)單，只要找 出數(shù)據(jù)的源頭并添加保護(hù)機(jī)制即可。上面的數(shù)據(jù)中有些類型再修復(fù)數(shù)據(jù)量較少， 對(duì)發(fā)現(xiàn)普遍性規(guī)律有一定的影響，使得偶然性大大增加。4. 2.1加強(qiáng)漏洞的填補(bǔ) 在修復(fù)安全性漏洞時(shí)，有時(shí)可能是臨時(shí)性填補(bǔ)，安全性還不夠高，還存在著一 些安全隱患，后續(xù)需

27、要對(duì)漏洞重新修復(fù)，從而提供更高的安全性防護(hù)；又或者可 能是修復(fù)的范圍不夠廣，同一個(gè)問(wèn)題在不同的地方岀現(xiàn)，此吋只要將修復(fù)延伸 至更大的范圍即可。這些再修復(fù)就是對(duì)漏洞填補(bǔ)的加強(qiáng)。加強(qiáng)漏洞的填補(bǔ)可根據(jù) 加強(qiáng)的再修復(fù)和原修復(fù)之間的關(guān)系分為強(qiáng)度加強(qiáng)和范圍加強(qiáng)?？梢詫?duì)安全性漏洞進(jìn)行臨時(shí)性填補(bǔ)是安全性漏洞修復(fù)的一個(gè)特點(diǎn)。臨時(shí)填補(bǔ)是為 了在沒有時(shí)間和資源進(jìn)行完全修復(fù)時(shí)，盡量減少安全性漏洞的作用力和危害， 甚至用一些非常糟糕、后期難以識(shí)別維護(hù)的修復(fù)來(lái)修復(fù)漏洞。當(dāng)然，這樣做只是 暫時(shí)使軟件能繼續(xù)運(yùn)行，不至于因?yàn)檐浖＿\(yùn)造成損失，在有時(shí)間和資源時(shí)重 新對(duì)漏洞進(jìn)行修復(fù)，以保證修復(fù)的完整性與安全性，這就是加強(qiáng)漏洞修復(fù)的

28、強(qiáng) 度。例如，對(duì)于安全性漏洞329385,攻擊者可以利用這個(gè)安全性漏洞進(jìn)行強(qiáng)制性鼠 標(biāo)操作。初始修復(fù)吋對(duì)ut進(jìn)行修改，使得與這個(gè)漏洞相關(guān)的ui界面暫吋停止相 關(guān)功能。這樣修復(fù)雖然可以解決問(wèn)題，但是會(huì)造成一些功能無(wú)法使用，且真正能 夠強(qiáng)制操控鼠標(biāo)操作的原因并沒有找到。而在再修復(fù)中找到了真止的原因，并對(duì) 其進(jìn)行了修復(fù)，也使得ui的相關(guān)功能得以正常運(yùn)行。另一種對(duì)漏洞修復(fù)的加強(qiáng)是范圍的加強(qiáng)，即對(duì)某個(gè)安全性漏洞的修復(fù)方式是正 確的，但是修復(fù)作用的范圍未完全包含所有岀問(wèn)題的地方，再修復(fù)吋只需要將 之前的修復(fù)作用于剩下的地方即可完成完整的修復(fù)。例如，對(duì)于安全性漏洞370127,其傳遞了某個(gè)不安全的方法作為新

29、方法的父方 法，而這個(gè)新方法如果被調(diào)用，則會(huì)由于父方法產(chǎn)生安全性問(wèn)題。一開始的判斷 是js代碼會(huì)調(diào)用到這個(gè)新方法，因此初始修復(fù)是在js調(diào)用該新方法時(shí)做一些安 全性防護(hù)，以保證調(diào)用時(shí)不會(huì)傳入不安全的父方法;后來(lái)卻發(fā)現(xiàn)不但js代碼會(huì) 調(diào)用該新方法，c+代碼某功能也會(huì)調(diào)用這個(gè)新方法，因此再修復(fù)要做的就是將 原來(lái)的防護(hù)方法作用于c+的調(diào)用，使得不論是哪種調(diào)用都能安全完成。4. 2.2減弱漏洞的填補(bǔ)與增強(qiáng)相反，減弱漏洞的填補(bǔ)也是安全性漏洞再修復(fù)的原因之一。在修復(fù)安全性 漏洞吋，如果對(duì)漏洞的防護(hù)太強(qiáng)，可能會(huì)導(dǎo)致一些功能被限制，一些合法數(shù)據(jù) 被阻攔過(guò)濾，這樣依舊會(huì)導(dǎo)致安全性問(wèn)題。例如，對(duì)于安全性漏洞4198

30、48, js通過(guò)導(dǎo)入一些腳本作為其內(nèi)容來(lái)使用，這樣 可能會(huì)導(dǎo)入不安全的腳本，在系統(tǒng)權(quán)限下對(duì)程序造成危害。因此，初始修復(fù)就對(duì) js能導(dǎo)入的腳本進(jìn)行了限制，使得某些的腳本不能被導(dǎo)入。但這種限制太 強(qiáng)，導(dǎo)致一些合法的腳木因含有相應(yīng)的url而不能被導(dǎo)入，程序不能正常運(yùn)行。 再修復(fù)就是導(dǎo)入一些程序必須但不能獲得系統(tǒng)權(quán)限的腳本，以保證程序安全地 正常運(yùn)行。4. 2.3填補(bǔ)原來(lái)沒有考慮到的漏洞 一個(gè)安全性漏洞的發(fā)生可能是因?yàn)槎鄠€(gè)地方有安全性問(wèn)題，這些不同地方的安 全性問(wèn)題導(dǎo)致了同樣的安全性漏洞。而在安全性漏洞的修復(fù)過(guò)程中，如果只修復(fù) 了其中一部分安全性問(wèn)題，另一部分未發(fā)現(xiàn)或被忽略，那么這個(gè)安全性漏洞就 是修

31、復(fù)不完整，因此會(huì)發(fā)生再修復(fù)。因?yàn)樘钛a(bǔ)原來(lái)沒有考慮到的漏洞而發(fā)生的安全性漏洞再修復(fù)，可以根據(jù)具體的 安全性問(wèn)題之間的關(guān)系分為兩種情況。1) 原修復(fù)和再修復(fù)是線性關(guān)系。這就好比一條河流發(fā)生洪水，如果在中流抗洪, 并不一定能達(dá)到最好的效果，而如果找到發(fā)生洪澇的源頭，在源頭治洪，效果 會(huì)好很多。例如，安全性漏洞312278發(fā)生的原因是某變量在未使用之前就被垃圾收集器釋 放了它所指向的內(nèi)存地址，因此在后面使用該變量時(shí)就是使用非法內(nèi)存。第一次 修復(fù)是在發(fā)現(xiàn)內(nèi)存被垃圾收集器釋放的地方管理那個(gè)變量，使之不能被釋放掉。 但是后來(lái)發(fā)現(xiàn)這個(gè)變量被釋放的源頭不是這里，變量在被管理起來(lái)之前就有可 能已被垃圾收集器釋放。

32、因此，再修復(fù)就是找到變量的源頭，在源頭對(duì)變量進(jìn)行 管理，使得變量不會(huì)被釋放。2) 初始修復(fù)與再修復(fù)是并列關(guān)系。初始修復(fù)和再修復(fù)解決的安全性問(wèn)題不是相 同的方法或功能，它們的修復(fù)方式可能不一樣，但是都會(huì)導(dǎo)致安全性漏洞。這些 并列的安全性問(wèn)題可能是因?yàn)殡y以全部找到或者經(jīng)常容易被忽略，從而導(dǎo)致再 修復(fù)的發(fā)生。例如，安全性漏洞360529是因?yàn)榭梢酝ㄟ^(guò)某些方法獲得瀏覽器的權(quán)限來(lái)運(yùn)行一 些惡意代碼，是跨站腳本攻擊。針對(duì)這個(gè)安全性漏洞的修復(fù)，自然是找出這些方 法并對(duì)它們進(jìn)行保護(hù)，防止其被攻擊者利用。初始修復(fù)是對(duì)array, prototype 和document, write進(jìn)行保護(hù)，并認(rèn)為成功修復(fù)了這個(gè)

33、漏洞。但是后來(lái)發(fā)現(xiàn) appcndchild ()和rcmovcattributc ()也會(huì)有這種問(wèn)題，因此第二次修復(fù)就 是對(duì)這些方法進(jìn)行保護(hù)，但其實(shí)對(duì)每個(gè)方法進(jìn)行保護(hù)的方式并不相同。這種再修復(fù)原因與加強(qiáng)漏洞修復(fù)的范圍的區(qū)別在于，用到的修復(fù)方式不同。加強(qiáng) 漏洞修復(fù)范圍中，初始修復(fù)和再修復(fù)運(yùn)用的修復(fù)方法是一樣的，只是作用的地 方發(fā)生了變化;而填補(bǔ)原來(lái)沒考慮到的漏洞(并列關(guān)系)則是初始修復(fù)和再修復(fù) 運(yùn)用的修復(fù)方式可能不同，針對(duì)的安全性問(wèn)題也不同，但是這些安全性問(wèn)題都 會(huì)導(dǎo)致同一個(gè)安全性漏洞。4. 2. 4對(duì)修復(fù)進(jìn)行登記或測(cè)試有時(shí)重新打開安全性漏洞并不是因?yàn)樵瓉?lái)的修復(fù)存在問(wèn)題，而是對(duì)完成的修復(fù) 進(jìn)行登

34、記，比如驗(yàn)證、加入實(shí)際項(xiàng)目中；又或者是對(duì)其進(jìn)行測(cè)試，以保證修復(fù)的 安全性與正確性。這種再修復(fù)不涉及到原修復(fù)的改動(dòng)，而是對(duì)原修復(fù)做一些操 作。例如，安全性漏洞410156的初始修復(fù)就已經(jīng)完全解決了安全隱患，重新打開漏 洞是為了添加一些測(cè)試，使修復(fù)能在更多條件下被檢驗(yàn)。4. 2.5以前修復(fù)無(wú)效或錯(cuò)誤而重新修復(fù)上面發(fā)現(xiàn)的一些再修復(fù)都是初始修復(fù)有一定正確性，能起到一定作用，且再修 復(fù)時(shí)不會(huì)完全推翻初始修復(fù)的修復(fù)方法。但是，有時(shí)候?qū)Π踩月┒吹男迯?fù)并不 那么簡(jiǎn)單，只要發(fā)生安全性漏洞的原因分析不正確或者修復(fù)方式錯(cuò)誤，都有可 能看似解決了問(wèn)題，但實(shí)際上只是暫時(shí)的假象，問(wèn)題不久又會(huì)再次發(fā)?；蛘哌€ 可能引起其他

35、錯(cuò)誤，因此要推翻初始修復(fù)進(jìn)行重新修復(fù)。這種安全性漏洞的再修 復(fù)一般會(huì)伴隨著對(duì)初始修復(fù)的回退，然后用正確的修復(fù)替換掉初始修復(fù)。例如，對(duì)于安全性漏洞349527,初始修復(fù)完成之后發(fā)現(xiàn)有編譯錯(cuò)誤，述可能產(chǎn) 生數(shù)據(jù)泄露的危險(xiǎn)，因此須對(duì)初始修復(fù)進(jìn)行改正，使因修復(fù)而產(chǎn)生的安全性問(wèn) 題都得到解決。4. 2. 6懷疑修復(fù)造成錯(cuò)誤，后來(lái)發(fā)現(xiàn)不是最后一種安全性漏洞再修復(fù)發(fā)生的原因其實(shí)是一種誤診。由于安全性漏洞的發(fā)生 原因復(fù)雜且難以找尋，因此如果初始修復(fù)后程序產(chǎn)生了某些問(wèn)題，開發(fā)人員可 能會(huì)對(duì)這個(gè)修復(fù)產(chǎn)生懷疑，認(rèn)為該修復(fù)造成了這些問(wèn)題。于是，程序員會(huì)對(duì)這個(gè) 修復(fù)進(jìn)行回退，回退之后如果發(fā)現(xiàn)問(wèn)題依舊存在，則說(shuō)明并不是修

36、復(fù)帶來(lái)的問(wèn) 題。因此，這種原因產(chǎn)生的再修復(fù)-般是先對(duì)初始修復(fù)進(jìn)行冋退，然后發(fā)現(xiàn)不是 修復(fù)存在問(wèn)題后又將初始修復(fù)恢復(fù)。4.3安全性漏洞的類型與再修復(fù)的原因通過(guò)統(tǒng)計(jì)安全性漏洞類型耳再修復(fù)的原因，即毎種類型對(duì)應(yīng)的再修復(fù)原因的數(shù) 量，可以得到哪種類型的安全性漏洞更容易發(fā)牛哪種再修復(fù)。通過(guò)表4所列統(tǒng)計(jì)結(jié)果得到如下規(guī)律:在7種安全性漏洞中，數(shù)據(jù)泄露和拒絕服 務(wù)攻擊沒有發(fā)生再修復(fù)的情況。首先，拒絕服務(wù)攻擊在安全性漏洞屮本就較少， 所以可能不會(huì)發(fā)生再修復(fù);另一方面，也說(shuō)明這兩種安全性漏洞比較簡(jiǎn)單、易于 修復(fù)或者修復(fù)方式是比較固定的，能夠輕易找出所有要修復(fù)的問(wèn)題并進(jìn)行正確 的修復(fù)，因此很少發(fā)牛再修復(fù)。由此可見，

37、在修復(fù)數(shù)據(jù)泄露和拒絕服務(wù)攻擊的安 全性漏洞時(shí)，如果能找到一個(gè)通用的發(fā)牛漏洞的原因、修復(fù)漏洞的方式，就能使 得這兩種安全性漏洞基本不會(huì)發(fā)生再修復(fù)。表4安全性漏洞類型與再修復(fù)原因統(tǒng)計(jì)下載原表跨站腳木攻擊發(fā)牛再修復(fù)的次數(shù)最多，內(nèi)存泄露發(fā)牛的次數(shù)最少，其他的都比 較平均?？缯灸_本攻擊發(fā)生再修復(fù)的原因中，剔除4個(gè)登記或測(cè)試和1個(gè)誤診, 基本上毎種再修復(fù)的原因都有涉及，說(shuō)明跨站腳本攻擊的安全性漏洞發(fā)生的原 因比較復(fù)雜，因此很容易出現(xiàn)遺漏或錯(cuò)誤，修復(fù)方式也難以做到全面保護(hù)，在 修復(fù)這類安全性漏洞吋需要投入更多的精力。特別地，僅有的3個(gè)減弱漏洞的填 補(bǔ)的再修復(fù)都是跨站腳本攻擊的漏洞，一方面說(shuō)明減弱漏洞的填補(bǔ)這

38、種再修復(fù) 本身就很少，另一方面也說(shuō)明了跨站腳本攻擊安全性漏洞的修復(fù)方式較其他類 型的安全性漏洞更容易發(fā)生修復(fù)過(guò)強(qiáng)的情況。在對(duì)跨站腳本攻擊漏洞進(jìn)行修復(fù)時(shí), 注意修復(fù)的強(qiáng)度與范圍，防止其影響到其他功能，有助于減少這種再修復(fù)的發(fā) 生。內(nèi)存泄露一般是因?yàn)閮?nèi)存使用和管理不當(dāng)而產(chǎn)生的，所以在內(nèi)存使用時(shí)必須進(jìn) 行分配與釋放。內(nèi)存泄露的安全性漏洞發(fā)生的原因并不復(fù)雜，修復(fù)方式也比較簡(jiǎn) 單，同時(shí)數(shù)量較少。由各種類型的安全性漏洞修改功能的集中度與各種再修復(fù)原因的分布范圍可以 看岀，安全性漏洞發(fā)生再修復(fù)的可能性與兩個(gè)因素有關(guān)：1）發(fā)生原因?qū)ふ业碾y 度，找到發(fā)生的是哪種類型的安全性漏洞，為什么會(huì)發(fā)生這種安全性漏洞，發(fā)

39、生錯(cuò)誤的代碼在什么文件、什么位置，這些信息越復(fù)雜，就越容易忽略或遺漏一 些信息而導(dǎo)致再修復(fù);2）修復(fù)方式的復(fù)雜程度，比如修改的文件的多少、這些修 改文件之間的聯(lián)系、修改的代碼行數(shù)、修復(fù)的次數(shù)，修復(fù)方式越復(fù)雜，修復(fù)時(shí)越 草率，發(fā)生再修復(fù)的可能性就越大。4.4初始修復(fù)與再修復(fù)的對(duì)比4. 4.1修復(fù)過(guò)程的對(duì)比根據(jù)表5統(tǒng)計(jì)的數(shù)據(jù)，基本上所有發(fā)生再修復(fù)的安全性漏洞在初始修復(fù)時(shí)都是 一次修改和提交，使用的修復(fù)過(guò)程是“修復(fù)一測(cè)試”，而在誤診的初始修復(fù)中， 使用了 “修復(fù)一部分修復(fù)”和“修復(fù)一更好的修復(fù)”兩種修復(fù)過(guò)程。這說(shuō)明，僅 僅使用“修復(fù)一測(cè)試”這種修復(fù)過(guò)程難以準(zhǔn)確、全面地進(jìn)行安全性防護(hù)，導(dǎo)致了 再修復(fù)的

40、發(fā)生。表5修復(fù)過(guò)程的對(duì)比下載原表在對(duì)漏洞進(jìn)行登記或測(cè)試的再修復(fù)中，基本只有一次修改和提交，因?yàn)樵傩迯?fù) 并不涉及代碼的修改。再修復(fù)屮除了使用“修復(fù)一測(cè)試”夕卜，其他修復(fù)過(guò)程大多 是以前修改錯(cuò)誤或無(wú)效而重新修改，因?yàn)檫@種再修復(fù)是推翻以前的修復(fù)進(jìn)行全 新的修復(fù)，相當(dāng)于修復(fù)一個(gè)新的安全性漏洞。通過(guò)使用這些修復(fù)過(guò)程來(lái)提高修復(fù) 的安全性，可避免二次再修復(fù)的發(fā)生。使用更復(fù)雜、更有效的修復(fù)過(guò)程有助于全面找到安全性漏洞發(fā)生的原因并進(jìn)行更 有效、更正確的修復(fù)，減小再修復(fù)發(fā)生的可能性。4. 4.2修改時(shí)間和修改者的對(duì)比根據(jù)表6統(tǒng)計(jì)的數(shù)據(jù)可知，除了以前修復(fù)無(wú)效或錯(cuò)誤而重新修復(fù)的安全性漏洞， 其他類型的再修復(fù)時(shí)間大多較

41、初始修復(fù)時(shí)有所減少。這說(shuō)明，初始修復(fù)只要不是 完全無(wú)用，都對(duì)再修復(fù)有著參考性的作用，可以幫助尋找被遺漏的安全性問(wèn)題， 提供修復(fù)方式的參考。表6修復(fù)時(shí)間與修復(fù)者的對(duì)比下載原表并列關(guān)系有一定數(shù)量的再修復(fù)吋間更長(zhǎng)的情況。并列關(guān)系其實(shí)是修復(fù)一些并列的 安全性問(wèn)題，且修復(fù)方式可能不同，導(dǎo)致安全性問(wèn)題的原因也可能不同，因此 需要更多的時(shí)間。在修改者對(duì)比方面，除了減弱漏洞的填補(bǔ)、對(duì)修復(fù)進(jìn)行登記或測(cè)試、誤診這3 種再修復(fù)基木上都是非同一修復(fù)者外，其他的再修復(fù)是同一修復(fù)者的占大部分。 這是因?yàn)槿绻粋€(gè)修復(fù)者進(jìn)行再修復(fù)就不用重新熟悉該安全性漏洞，對(duì)漏洞 發(fā)生的原因、原來(lái)的修復(fù)方式都有一定的了解，就可以有更高的再

42、修復(fù)效率，從 而節(jié)省時(shí)間與資源。4. 4.3修改模式的對(duì)比針對(duì)初始修復(fù)和再修復(fù)使用的修改模式進(jìn)行的統(tǒng)計(jì)分析如表7所列，可以通過(guò) 得岀的規(guī)律對(duì)再修復(fù)進(jìn)行修改模式的推薦。表7修改模式的對(duì)比下載原表對(duì)漏洞進(jìn)行登記或測(cè)試和誤診這兩種再修復(fù)基木上不涉及安全性修改，因此再 修復(fù)吋無(wú)修改模式的使用。加強(qiáng)漏洞的填補(bǔ)屮，范圍加強(qiáng)再修復(fù)使用的修改模式基本包含了初始修復(fù)的修 改模式，因?yàn)樵傩迯?fù)只是將初始修復(fù)的使用范圍變大，但修復(fù)方式不變。在填補(bǔ)原來(lái)沒有考慮到的漏洞中，線性關(guān)系的兩次修改模式基本相同，因?yàn)閮?次修復(fù)方式完全相同，只是作用于不同的地方。其他類型的再修復(fù)使用的修改模式與初始修復(fù)使用的可能相同也可能不同，因

43、 為再修復(fù)的修復(fù)方式與以前的不同，修改模式也可能不同。4. 4.4文件修改情況的對(duì)比 安全性漏洞的修復(fù)體現(xiàn)在文件、代碼的修改上。通過(guò)對(duì)比初始修復(fù)與再修復(fù)修改 的文件及其內(nèi)容之間的區(qū)別和關(guān)系來(lái)找出各種再修復(fù)修改時(shí)的特點(diǎn)。根據(jù)對(duì)數(shù)據(jù)(見表8)的分析，主要有5種文件修改的情況:相同文件，不同內(nèi) 容;相同文件，相似內(nèi)容;不同文件，不同內(nèi)容;不同文件，相似內(nèi)容;無(wú)修改。無(wú) 修改說(shuō)明再修復(fù)沒有對(duì)相關(guān)代碼進(jìn)行任何改動(dòng)。相同文件，相似內(nèi)容，說(shuō)明初始 修復(fù)與再修復(fù)修改的文件是相同的，對(duì)這些文件內(nèi)容的修改也是相似的。相同文 件，不同內(nèi)容，則是修改文件相同，但是對(duì)文件的修改是不同的內(nèi)容，對(duì)修復(fù) 的作用也不同。剩下兩

44、種都修改的是不同的文件，但修改的內(nèi)容和作用的區(qū)別與 上面的定義相似。對(duì)修復(fù)進(jìn)行登記或測(cè)試和誤診兩種再修復(fù)不涉及代碼修改。范 圉加強(qiáng)和線性關(guān)系則全是兩次修復(fù)修改相同文件、相似內(nèi)容，因?yàn)樗鼈兦昂蟮男?復(fù)方式相同，且安全性問(wèn)題比較集中。并列關(guān)系主要集中在“相同文件，不同內(nèi) 容”和“不同文件，不同內(nèi)容”兩種情況，說(shuō)明修復(fù)方式基木上是不同的。表8文件修改情況的對(duì)比 下載原表5相關(guān)工作pamela bhattacharya等人通過(guò)對(duì)漏洞報(bào)告和漏洞修復(fù)的經(jīng)驗(yàn)研究，識(shí)別出漏洞 報(bào)告的優(yōu)劣性，找岀了漏洞生命周期對(duì)漏洞修復(fù)的影響口1。michael gegick等 人則通過(guò)對(duì)漏洞報(bào)告自然語(yǔ)言的描述進(jìn)行自動(dòng)化分析，

45、能夠找出其屮的安全性 漏洞報(bào)告，避免了浪費(fèi)在尋找非安全性漏洞報(bào)告上的時(shí)間宜。這些研究給我們 漏洞報(bào)告的實(shí)驗(yàn)分析提供了研究方法的參考。丁羽等人回通過(guò)對(duì)學(xué)術(shù)界關(guān)于漏洞分類學(xué)(taxonomy)和漏洞分類 (classification)的調(diào)研，總結(jié)了安全性漏洞分類的幾個(gè)關(guān)鍵性問(wèn)題。li zhenmin等人10使用自然語(yǔ)言處理分類工具對(duì)兩個(gè)大型開源項(xiàng)r約29000個(gè)漏 洞進(jìn)行自動(dòng)化分析，找到了漏洞的一些特性和規(guī)律，并發(fā)現(xiàn)了安全性漏洞數(shù)量 正在增加且大部分會(huì)造成嚴(yán)重的損失。yonghee shin等人11通過(guò)9種復(fù)雜性 度量標(biāo)準(zhǔn)找到安全性漏洞與非安全性漏洞之間的區(qū)別，并對(duì)安全性漏洞進(jìn)行預(yù) 測(cè)。文章中提

46、供了安全性漏洞分類和漏洞在各修復(fù)階段的特點(diǎn)的參考1111。shahed zaman等人4針對(duì)firefox工程屮的漏洞，比較了安全性漏洞和功能性 漏洞在各方面的不同之處。研究發(fā)現(xiàn)，安全性漏洞修復(fù)得越快，修復(fù)時(shí)需耍的開 發(fā)人員越多，涉及到的文件也越多，再修復(fù)發(fā)生得越頻繁趙l這些研究都是對(duì) 安全性漏洞的特征、分類進(jìn)行了分析總結(jié)，而木文主要集中研究安全性漏洞再修 復(fù)的修復(fù)特征，因此這些研究可為我們提供經(jīng)驗(yàn)參考。最后，還有一些預(yù)測(cè)方法的研究，這些預(yù)測(cè)方法與本文角度不同，他們一般是 通過(guò)漏洞的各類靜態(tài)或運(yùn)行時(shí)信息來(lái)進(jìn)行再修復(fù)的預(yù)測(cè)，而本文則主要是通過(guò) 漏洞修復(fù)信息來(lái)尋找通用的預(yù)測(cè)方法。t zimmerm

47、ann等人12通過(guò)開發(fā)人員對(duì) 再修復(fù)原因的分類、漏洞報(bào)告、修復(fù)人員的關(guān)系等方面，利用靜態(tài)分析模型對(duì)漏 洞再修復(fù)的性質(zhì)與預(yù)測(cè)方式進(jìn)行研究，其中的分類與預(yù)測(cè)方法給本文研究提供 了參考性建議。管銘等人曲通過(guò)靜態(tài)分析和動(dòng)態(tài)分析兩種程序分析技術(shù)，研究 了在軟件開發(fā)周期屮安全性漏洞檢測(cè)的技術(shù)。到目前為止，對(duì)安全性漏洞的研究主要集屮在以下方面:識(shí)別安全性漏洞4, 13-14,預(yù)測(cè)安全性漏洞8, 15-16,對(duì)安全性漏洞進(jìn)行分類9-10, 17,對(duì) 安全性漏洞報(bào)告8、性質(zhì)18進(jìn)行研究與比較,安全模式的應(yīng)用19-20,安全 性檢測(cè)21-22等,而對(duì)再修復(fù)的研究卻寥寥無(wú)幾，基木上是通過(guò)漏洞的特征、 漏洞報(bào)告等信息

48、對(duì)漏洞的再修復(fù)進(jìn)行預(yù)測(cè)11型。但是因?yàn)獒槍?duì)的是所有漏洞, 安全性這個(gè)特點(diǎn)和其特殊性沒有重點(diǎn)考慮，因此對(duì)安全性漏洞再修復(fù)知識(shí)的研 究十分稀少。結(jié)束語(yǔ) 本文通過(guò)對(duì)mozilla工程中2005年-2011年共48個(gè)發(fā)生了再修復(fù)的安 全性漏洞的經(jīng)驗(yàn)進(jìn)行研究，分析安全性漏洞發(fā)牛再修復(fù)的原因、再修復(fù)的次數(shù)、 修改的提交數(shù)、修改的文件數(shù)、修改的代碼行數(shù)的增減、初始修復(fù)和再修復(fù)的對(duì) 比（使用的修改模式、使用的修復(fù)過(guò)程、修改的時(shí)間、修改者、修改文件內(nèi)容）等 數(shù)據(jù)，首先發(fā)現(xiàn)了安全性漏洞發(fā)生再修復(fù)是普遍存在的，且與漏洞發(fā)生原因的 識(shí)別復(fù)雜程度和漏洞修復(fù)的復(fù)雜程度這兩個(gè)因素有關(guān);其次，了解了初始修復(fù)的 文件、代碼的集

49、中程度是影響再修復(fù)的原因之一，并且使用更復(fù)雜、更有效的修 復(fù)過(guò)程可有效避免再修復(fù)的發(fā)生;最后，總結(jié)了幾種安全性漏洞發(fā)生再修復(fù)的原 因。本研究仍然存在一些未解決的問(wèn)題:未能很好地識(shí)別安全性漏洞再修復(fù)與初始修 復(fù)之間在修復(fù)方式上的區(qū)別，這對(duì)自動(dòng)化再修復(fù)的研究有一定的限制。未來(lái)可以 分析更新、更多的發(fā)生了再修復(fù)的安全性漏洞的數(shù)據(jù)，著重研究規(guī)律還不明確的 幾種再修復(fù)，嘗試找出它們的預(yù)測(cè)方式，并通過(guò)再修復(fù)的歷史數(shù)據(jù)找到前后兩 次修復(fù)在修復(fù)方式上存在的聯(lián)系與區(qū)別，從而得到自動(dòng)修復(fù)它們的方法，并開 發(fā)出再修復(fù)預(yù)測(cè)與自動(dòng)化修復(fù)的工具。參考文獻(xiàn)1 tan l, liu c, li z m, et al. bug

50、 characteristics in open source softwarejempirical software engineering, 2014, 19 (6) :1665-17052 haley c b, laney r, moffett j d, ct al. security requirements engineering:a framework for representation and analysisj1eee transactions on software engineering, 2008, 34 (1) :133-153.3 viega j, mcgraw g

51、. building secure software:how to avoid security problems the right waym. addison-wesley, new york, 2001.4 zaman s, adams b, hassan a e. security versus performance bugs:a case study on firefox c /zproceedi ngs of t he8 th work ing conf ere nee on mining software repositories. new york, ny, usa:acm,

52、 2011:93102.5 zeller a. why programs fail:a guide to system atic debuggingm. san francisco, ca, usa:morgan kaufmann publishers inc., 2005.8 geg1ck m, rotella p, xie t. identifying security bug reports via text mining:an industrial case study c /proceedings of the 7th international working conferenee

53、 on mining software repositories. washington dc, usa:ieee, 2010:11-20.9 ding y, zou w, wei t. research summarize of classificeition of security bugs in softwarcc/proceedings of the 5th conference on vulncrability analysis and risk assessment. 2012. (in chinese) 丁羽，鄒維，韋韜軟件 安全漏洞分類研究綜述c 信息安全漏洞分析與風(fēng)險(xiǎn)評(píng)估大會(huì)

54、.2012.10 lt z m, tan l, wang x h, et al. heive things changed now?an empirical study of bug charactcristics in modern opcn sourcesoftwarec/proceedings of the workshop on architectural and system support for improving software dependability.washington dc, usa:ieee, 2010:11-20.lllshin y, williams l. a

55、n empirical model to predict security vulncrabilitics using code complexity metricsc/proceedings ofinternational symposium on empirical software engineering and measurement. new york, ny, usa:acm, 2008:315-317.12 zimmermann t, nagappan n, guo p, et al. characterizing and predicting which bugs get re

56、openedc/proceedings of the 34th international conf ere nee on soft ware engin eer in g. weish ington dc, usa: ieee, 2012:1074-1083.13 guan m. the research of software security bug detection technology based on the analysis of applicationd.xi' an:northwestern polytechnical university, 2007. (in c

57、hinese)管銘.基于程序分析的軟件安 全漏洞檢測(cè)技術(shù)研究d西安:西北工業(yè)大學(xué)，2007.14 z1iang l, zeng q k the static detection tech no logy of software sccur ity bug j. software engineering, 2008, 34 (12) : 157-159. (in chinese)張林， 曾慶凱軟件安全漏洞的靜態(tài)檢測(cè)技術(shù)j計(jì)算機(jī)工程，200& 34(12) :157-159.15 thome j, shar l k, brtand l. security slicing for auditing xml, xpath, and sql injection vulnerabilitiesc/proceedings of the 26th ieeeinternational symposium on software reliability engineering. washington dc, usa:ieee, 2015:553-564.161shar l k, tan h b k, brtand l.mining sql injection and cross site scripting