牛霜霞　呂　卓　張　威,2　莫堅(jiān)松,2

1(國(guó)網(wǎng)河南省電力公司電力科學(xué)研究院　河南 鄭州 450000)2(河南恩湃高科集團(tuán)有限公司　河南 鄭州 450000)

?

改進(jìn)的基于代碼污染識(shí)別安全警告的算法

牛霜霞1呂卓1張威1,2莫堅(jiān)松1,2

1(國(guó)網(wǎng)河南省電力公司電力科學(xué)研究院河南 鄭州 450000)2(河南恩湃高科集團(tuán)有限公司河南 鄭州 450000)

由于靜態(tài)代碼審計(jì)工具具有自動(dòng)化、不容易出錯(cuò)的特點(diǎn)，開(kāi)發(fā)人員經(jīng)常使用它來(lái)檢測(cè)代碼漏洞，但是檢測(cè)出的代碼漏洞的結(jié)果會(huì)產(chǎn)生大量的警告信息，開(kāi)發(fā)人員必須手動(dòng)進(jìn)行檢查和糾正。此工具的缺點(diǎn)是浪費(fèi)開(kāi)發(fā)人員大量的時(shí)間。通過(guò)對(duì)用戶的輸入以及敏感數(shù)據(jù)流的追蹤來(lái)確定警告的缺陷是否真的被利用，從而減少靜態(tài)檢測(cè)工具產(chǎn)生的大量警告數(shù)量。同時(shí)提供給開(kāi)發(fā)者更多真正能對(duì)軟件產(chǎn)生威脅的警告信息。針對(duì)靜態(tài)代碼審計(jì)工具的缺點(diǎn)，研究三種不同的方法來(lái)提高靜態(tài)代碼審計(jì)工具的性能。第一，對(duì)于商業(yè)性的靜態(tài)代碼分析工具Coverity，重新分析它的結(jié)果，并且從安全的角度創(chuàng)建一組具體的相關(guān)警告。第二，對(duì)開(kāi)放的源代碼分析工具Findbugs進(jìn)行修改，并只對(duì)被用戶輸入所污染的代碼進(jìn)行分析。第三，研發(fā)灰盒代碼審計(jì)工具，此工具側(cè)重于Java代碼中的跨站腳本攻擊XSS(Cross Site Scripting)，使用數(shù)據(jù)流分析的方法來(lái)確定漏洞的切入點(diǎn)。實(shí)驗(yàn)結(jié)果證明工程B使警告數(shù)量降低了20%，工程E只產(chǎn)生了2%的警告，降低了工具產(chǎn)生警告的數(shù)量，為開(kāi)發(fā)人員提供更多的信息來(lái)區(qū)分此警告是否是真正的安全威脅。

CoverityFindbugsXSS漏洞

0　引　言

在眾多的研究[1-3]中，自動(dòng)化的靜態(tài)代碼分析工具作為在開(kāi)發(fā)早期檢測(cè)漏洞的工具被提出，發(fā)揮了極大的作用，減少了程序員人工檢查代碼的時(shí)間。微軟安全開(kāi)發(fā)生命周期[4]也將靜態(tài)代碼審計(jì)工具作為軟件開(kāi)發(fā)中的一個(gè)重要組成部分。然而，行業(yè)研究顯示靜態(tài)代碼分析工具在使用的過(guò)程中存在一些問(wèn)題。在研究和觀察中得知開(kāi)發(fā)人員往往沒(méi)能意識(shí)到這些安全警告，同時(shí)也沒(méi)有對(duì)其進(jìn)行糾正[5]。靜態(tài)代碼分析工具產(chǎn)生的報(bào)告中含有大量的警告信息使得這一問(wèn)題變得更加嚴(yán)重[6]。本文同樣發(fā)現(xiàn)當(dāng)開(kāi)發(fā)人員試圖糾正一些錯(cuò)誤的警告時(shí)，又產(chǎn)生了新的安全漏洞。研究表明，一些主流的靜態(tài)分析工具產(chǎn)生的報(bào)告中只有約5%的警告是安全威脅。

少量真正有意義和大量晦澀難懂的警告信息雜糅在一起造成了開(kāi)發(fā)者忽視靜態(tài)檢測(cè)工具產(chǎn)生的結(jié)果這一模糊情形。從某種角度，開(kāi)發(fā)者認(rèn)為這些警告不能帶來(lái)麻煩或者產(chǎn)生真正的危害，從而認(rèn)為警告信息沒(méi)什么意義。本文將展示如何通過(guò)已有的靜態(tài)代碼檢測(cè)工具進(jìn)行一些限定，使得產(chǎn)生的結(jié)果報(bào)告更高效簡(jiǎn)潔。本文通過(guò)限定檢測(cè)的對(duì)象為任何受到外部源影響的源代碼，來(lái)降低產(chǎn)生的警告數(shù)量并且準(zhǔn)確的定位由用戶數(shù)據(jù)產(chǎn)生的源代碼漏洞。

1　背　景

雖然目前有很多關(guān)于靜態(tài)代碼分析技術(shù)和一些關(guān)于靜態(tài)檢測(cè)效果的文獻(xiàn)，但是很少有文獻(xiàn)研究靜態(tài)分析工具是如何用于企業(yè)和會(huì)給企業(yè)帶來(lái)什么樣的問(wèn)題。文獻(xiàn)[6]羅列出了大量的警告，但是這些警告很難進(jìn)行歸類[5]，因此，開(kāi)發(fā)人員很難分辨出與安全相關(guān)的警告。有必要確定一個(gè)外部攻擊的警告的子集，這樣可以使得開(kāi)發(fā)人員更容易確定哪些警告對(duì)于安全性來(lái)說(shuō)是重要的。

在開(kāi)發(fā)過(guò)程中，代碼審計(jì)工作者很早就用各種自動(dòng)化靜態(tài)代碼審計(jì)工具對(duì)代碼進(jìn)行漏洞分析，因此，不需要花費(fèi)很多的精力去研究這些漏洞。但是，代碼審計(jì)工作者也希望靜態(tài)代碼分析工具可以檢測(cè)出代碼中真正的安全漏洞[6]，這就需要對(duì)從靜態(tài)分析工具中得到的警告進(jìn)行嚴(yán)格的審查并記錄成報(bào)告。代碼審計(jì)工作者可以觀察到哪些警告被開(kāi)發(fā)人員糾正，哪些沒(méi)有被糾正，同時(shí)也清晰地發(fā)現(xiàn)哪些漏洞容易被忽略，哪些漏洞永遠(yuǎn)不會(huì)對(duì)其進(jìn)行修正。被忽略的漏洞通常是大量相似的不會(huì)形成安全威脅的警告，因?yàn)闆](méi)有用戶數(shù)據(jù)利用警告進(jìn)行攻擊。開(kāi)發(fā)人員只會(huì)將這些警告看作是錦上添花的更正信息，因?yàn)殚_(kāi)發(fā)人員不可能進(jìn)入警告信息所需要的狀態(tài)。因此這類漏洞容易被忽視并且永遠(yuǎn)不會(huì)被糾正。這種忽略警告的行為最早是在一個(gè)關(guān)于審查開(kāi)發(fā)人員能否正確地從靜態(tài)分析工具中識(shí)別安全警告的能力的研究[5]中發(fā)現(xiàn)的。

從對(duì)這類文獻(xiàn)的研究來(lái)看，在產(chǎn)業(yè)化開(kāi)發(fā)中，對(duì)靜態(tài)代碼工具的使用策略以及檢測(cè)報(bào)告的正確評(píng)估是很有必要的。

2　研究方法

因?yàn)殚_(kāi)發(fā)人員經(jīng)常會(huì)忽略或誤解安全警告，本文需要想辦法來(lái)區(qū)分那些非?？赡鼙婚_(kāi)發(fā)人員誤認(rèn)為是安全相關(guān)的標(biāo)識(shí)的警告，需要將源代碼分割成很多部分。這些分割后的代碼可以直接或者間接地被用戶數(shù)據(jù)所影響，同時(shí)代碼并不能被外部非用戶數(shù)據(jù)來(lái)源所影響。本文通過(guò)研究流程敏感分析、過(guò)程間分析和上下文相關(guān)的數(shù)據(jù)流分析方法解決上述問(wèn)題。由于這種方法非常詳細(xì)和精確，在某些情況下可以使用更簡(jiǎn)單、快速的分析方法，但是為了簡(jiǎn)單起見(jiàn)在本文所有的分析中都是用相同的分析方法。數(shù)據(jù)流分析通常用于編譯器的優(yōu)化[7]中，在這個(gè)領(lǐng)域中，有無(wú)數(shù)的課題和研究利用了此種方法。因?yàn)楸疚年P(guān)注已經(jīng)被分析但還沒(méi)有統(tǒng)一化的C++和Java代碼，所以本文采用了幾種已知的流分析方式和程序模塊化方式，而并不是用自己定義的方法去解決。

圖1　污點(diǎn)輸入源層次結(jié)構(gòu)圖

為了更好地篩選安全警告，首先，本文必須確定源代碼中的數(shù)據(jù)入口點(diǎn)。入口點(diǎn)可以是任何類型的用戶數(shù)據(jù)、甚至套接字、文件操作或其他的用戶輸入的操作。這是通過(guò)在不同的特定輸入源中進(jìn)行簡(jiǎn)單的詞法分析來(lái)實(shí)現(xiàn)的。然而，仍有一些局限需要被解決。第一，對(duì)所有可能的輸入源做數(shù)據(jù)流分析往往會(huì)導(dǎo)致大部分代碼都被標(biāo)記為污染代碼，因此，有必要將輸入源限定為特定的輸入類型或者追蹤那些被不同的輸入源污染所影響的代碼。本文通過(guò)結(jié)合這兩種方法并且允許審核者決定如何處理輸入源才能得到最好的結(jié)果。第二，由于面向?qū)ο蟮某绦蛟O(shè)計(jì)往往只有一個(gè)程序類，并且該程序類執(zhí)行了由詞法分析所確定的套接字操作，因此有必要繼續(xù)進(jìn)行分析并確定哪些代碼或類使用了基礎(chǔ)套接字類。這個(gè)操作可以創(chuàng)建輸入源的層次結(jié)構(gòu)[8]，并且可以更加充分將結(jié)構(gòu)展示給開(kāi)發(fā)人員，以便開(kāi)發(fā)人員能夠確定威脅的根源。圖1展示了這種層次結(jié)構(gòu)。在這個(gè)例子中，輸入源B和C是開(kāi)發(fā)人員所關(guān)心的，而輸入源A只是一個(gè)基類。

在確定了一個(gè)輸入源之后，數(shù)據(jù)流分析將表明用戶數(shù)據(jù)是如何通過(guò)源代碼進(jìn)行傳播的。因?yàn)楸疚年P(guān)心那些可以被服務(wù)軟件用戶所利用的漏洞，所以只需要在網(wǎng)絡(luò)中檢查輸入源。一些檢查器將用戶數(shù)據(jù)所影響到的每一行都將被標(biāo)記成被污染的代碼，并對(duì)被污染的源代碼進(jìn)行專門的標(biāo)記。比如，一個(gè)循環(huán)執(zhí)行N次取決于用戶輸入變量的大小，然而，用戶輸入本身從來(lái)沒(méi)有在循環(huán)內(nèi)使用過(guò)。因此循環(huán)并不會(huì)直接被污染，與此同時(shí)緩沖區(qū)溢出檢查器也會(huì)檢查被污染的代碼。

由于在面向?qū)ο蟮脑O(shè)計(jì)中，數(shù)據(jù)路徑分析往往會(huì)中斷和創(chuàng)建新的片段，分析將會(huì)從代碼中原始類或?qū)ο笏褂玫奈恢瞄_(kāi)始重新啟動(dòng)。通過(guò)這種方式，本文可以將程序片段從開(kāi)始到結(jié)束進(jìn)行傳遞，如果數(shù)據(jù)流分析的過(guò)程中發(fā)現(xiàn)了已經(jīng)被污染的代碼有相同的上下文內(nèi)容，它將會(huì)終止分析跟蹤，以節(jié)省分析所消耗的時(shí)間。

最終的結(jié)果將是一個(gè)包含被污染的和未被污染的源代碼樹(shù)，以及帶有可能污染路徑的層次結(jié)構(gòu)輸入源。

由于Coverity[9]工具是一個(gè)商業(yè)化的非開(kāi)源的源碼工具，不能對(duì)其代碼進(jìn)行修改來(lái)分析被污染的代碼。不過(guò)本文可以對(duì)Coverity工具分析的結(jié)果和污染源代碼進(jìn)行比較，如果一個(gè)警告存在于被污染的代碼部分，可以根據(jù)它們的輸入源進(jìn)行組合，忽略未被污染的源代碼中產(chǎn)生的警告。

本文可以改變Findbugs[10]工具的源代碼，用此工具對(duì)被污染的源代碼進(jìn)行數(shù)據(jù)流分析。為了確保所有的被需要的代碼都包括其中，還必須要加入變量初始化和其他的一些代碼以保證分析不會(huì)失敗。本文只對(duì)被污染的代碼進(jìn)行一個(gè)標(biāo)準(zhǔn)的Findbugs工具分析，來(lái)減少Findbugs工具分析時(shí)所必須檢查的行數(shù)。

3　研究結(jié)果

3.1Coverity工具的分析

Coverity 工具審計(jì)了兩個(gè)工程和一個(gè)類庫(kù)。本文的關(guān)注點(diǎn)是在遠(yuǎn)程安全漏洞上，因此忽略了本地輸入污染的影響。事實(shí)上，輸入污點(diǎn)分析的使用要求檢查器是特定的輸入或者大部分將被標(biāo)記為污染的源代碼。在表1和表2中，警告的數(shù)量和被輸入數(shù)據(jù)所污染的代碼百分比被分布到不同的輸入源中。通過(guò)比較代碼的行和警告的數(shù)目，推測(cè)出該代碼的差異。在大多數(shù)情況下，存在一個(gè)第一次創(chuàng)建的套接字類，然后其他的類使用這個(gè)基礎(chǔ)的套接字類來(lái)處理不同的協(xié)議。在這些情況下創(chuàng)建的初始的套接字類并未考慮到入口點(diǎn)，而是考慮使用基礎(chǔ)套接字類的協(xié)議。這樣做的目的是增強(qiáng)用戶的可讀性，而是采用了何種協(xié)議或命令來(lái)啟動(dòng)污點(diǎn)來(lái)作為重要的入口點(diǎn)而不是套接字類。在工程A中，頭兩個(gè)輸入源對(duì)它們的數(shù)據(jù)進(jìn)行的遍歷非常相似，得到的大多數(shù)的代碼和所有的警告都是相同的。然而，從工具中得到的報(bào)告警告的數(shù)量降到了只有總警告數(shù)的18%，明顯減少了來(lái)自開(kāi)發(fā)人員的負(fù)擔(dān)。第三個(gè)輸入源是一個(gè)新的協(xié)議，與其他的輸入源之間存在著很小的交互作用。盡管如此，結(jié)合用戶輸入的所有三個(gè)來(lái)源，得到報(bào)告中的警告在1600個(gè)警告總數(shù)中占24%這個(gè)結(jié)果。從這個(gè)改進(jìn)的報(bào)表中可以得出21%的漏洞是先前的研究中就被發(fā)現(xiàn)的，而剩余的則是通過(guò)非安全檢查器發(fā)現(xiàn)的漏洞。

表1　Coverity工具分析結(jié)果

表2　改進(jìn)的Findbugs工具結(jié)果

工程B明顯降低了警告的數(shù)目，使得開(kāi)發(fā)者有意愿對(duì)每個(gè)警告進(jìn)行檢查，而這些警告有可能危及產(chǎn)品的安全性或穩(wěn)定性。但是與工程A進(jìn)行對(duì)比，工程B的每行代碼同樣有較低數(shù)量的警告產(chǎn)生。由于污點(diǎn)分析，本文確保那些被忽略的警告并不是可利用的安全警告，因此，提高了靜態(tài)代碼分析工具的準(zhǔn)確性。

3.2改進(jìn)的Findbugs工具

對(duì)一個(gè)類庫(kù)進(jìn)行分析，是比分析一個(gè)工程更加困難的工作。如果整個(gè)API類庫(kù)被認(rèn)定為一個(gè)輸入源[11]，3.1節(jié)中方法將不再可用。通過(guò)限制其只對(duì)網(wǎng)絡(luò)類進(jìn)行污點(diǎn)分析仍然會(huì)檢測(cè)大量代碼并報(bào)出大量警告來(lái)，這就表明了對(duì)非服務(wù)器源代碼使用輸入污點(diǎn)分析是有限制性的。除了考慮到對(duì)API庫(kù)進(jìn)行處理時(shí)有限制性外，在進(jìn)行文件操作和數(shù)據(jù)庫(kù)的處理時(shí)，同樣有相當(dāng)大的問(wèn)題。這主要取決于當(dāng)這兩個(gè)操作被執(zhí)行時(shí)會(huì)丟失信息。數(shù)據(jù)流分析將會(huì)在數(shù)據(jù)庫(kù)進(jìn)行寫操作時(shí)結(jié)束，不會(huì)再繼續(xù)進(jìn)行分析[12]。但是，用戶數(shù)據(jù)卻可以被閱讀并且在代碼的不同部分中使用。如果在數(shù)據(jù)庫(kù)的讀操作進(jìn)行一輪新的污點(diǎn)分析，那么將會(huì)有大部分的代碼會(huì)包括在其中，不會(huì)達(dá)到預(yù)期的效果。因此本文需要對(duì)數(shù)據(jù)庫(kù)的使用執(zhí)行更加智能化的分析。Java靜態(tài)代碼分析工具Findbugs并不像Coverity工具一樣有大量的安全檢查器。因此，當(dāng)本文使用FindBugs工具對(duì)代碼進(jìn)行檢查分析的時(shí)候出現(xiàn)的安全相關(guān)警告的數(shù)量會(huì)比Coverity低。這主要是因?yàn)镴ava語(yǔ)言更加安全和FindBugs靜態(tài)代碼分析工具更加成熟。

與C/C++產(chǎn)品相比，Java產(chǎn)品只有少量的警告產(chǎn)生[13]。因?yàn)镴ava產(chǎn)品并未對(duì)用戶數(shù)據(jù)執(zhí)行任何繁重的計(jì)算，這種設(shè)計(jì)也意味著會(huì)有較少的代碼受到用戶輸入的直接影響。這樣產(chǎn)生的少量的警告，使得審計(jì)者可以更加容易的對(duì)其進(jìn)行核查。對(duì)于工程D來(lái)說(shuō)，兩個(gè)輸入源盡管有著不同的代碼路徑，卻有著基本完全相同的警告。經(jīng)過(guò)其數(shù)據(jù)流分析之后，工程E就只產(chǎn)生了先前2%的警告。

3.3灰盒靜態(tài)代碼審計(jì)工具

最后，本文設(shè)計(jì)了一個(gè)新的靜態(tài)代碼審計(jì)工具，這個(gè)工具主要針對(duì)跨站點(diǎn)腳本攻擊(XSS)漏洞的識(shí)別。通過(guò)確定用戶輸入源和反饋給用戶的數(shù)據(jù)之間是否有數(shù)據(jù)流，就可以查找XSS漏洞。表2中只有工程D可能遭受到XSS漏洞的攻擊，F(xiàn)indbugs工具并不會(huì)對(duì)單一的XSS漏洞作出報(bào)告，而此靜態(tài)代碼審計(jì)工具檢測(cè)到了7個(gè)可能的XSS攻擊威脅，所有被發(fā)現(xiàn)的漏洞在代碼中都被利用進(jìn)行攻擊。由于在審查代碼時(shí)，首先進(jìn)行了輸入驗(yàn)證，因此在最終產(chǎn)品中并不存在被攻擊的情況。此代碼審計(jì)工具同樣對(duì)反射型XSS攻擊的檢測(cè)做了限制，反射型XSS通常會(huì)在一個(gè)錯(cuò)誤的頁(yè)面產(chǎn)生。而存儲(chǔ)型XSS首先將數(shù)據(jù)保存到一個(gè)儲(chǔ)存設(shè)施中，在將其發(fā)送給用戶之前先對(duì)數(shù)據(jù)進(jìn)行重新檢索。由于本文將從數(shù)據(jù)庫(kù)的檢索中得到的用戶輸入信息的污點(diǎn)設(shè)置為安全，因此代碼審計(jì)工具不會(huì)對(duì)數(shù)據(jù)庫(kù)的讀操作做任何的污點(diǎn)分析。在結(jié)果中，存儲(chǔ)型XSS漏洞不會(huì)被報(bào)告出來(lái)，這樣的分析是建立在準(zhǔn)確度和少量警告以及誤報(bào)之間的博弈。

限制靜態(tài)代碼審計(jì)工具來(lái)報(bào)告所有代碼中可能的錯(cuò)誤看上去好像很奇怪，然而，如果一個(gè)開(kāi)發(fā)團(tuán)隊(duì)處在一個(gè)輕量級(jí)的開(kāi)發(fā)上，大量的警告并不會(huì)在每一個(gè)版本發(fā)布出來(lái)前被盡數(shù)更正。事實(shí)上，這樣一來(lái)靜態(tài)代碼審計(jì)產(chǎn)生的結(jié)果很難在項(xiàng)目開(kāi)發(fā)中占有一個(gè)較高優(yōu)先級(jí)的位置。對(duì)于靜態(tài)代碼審計(jì)工具來(lái)說(shuō)，能將那些可以被認(rèn)定為是安全威脅的警告與那些不可以被認(rèn)定為是安全威脅的警告區(qū)分開(kāi)來(lái)是非常重要的事情。不管是執(zhí)行靜態(tài)分析前還是進(jìn)行分析后，都可以通過(guò)執(zhí)行污點(diǎn)分析的方法將安全漏洞從其他的漏洞中區(qū)分出來(lái)。當(dāng)使用Coverity工具時(shí)，工程A出現(xiàn)的警告數(shù)超過(guò)了1600個(gè)。如果假設(shè)每檢查一個(gè)警告平均耗時(shí)3分鐘，那么，對(duì)所有的這些警告進(jìn)行審查將要需要80個(gè)小時(shí)。在輕量級(jí)產(chǎn)品開(kāi)發(fā)中，這是一個(gè)非常耗時(shí)并且不實(shí)用的開(kāi)發(fā)。當(dāng)使用3種不同的網(wǎng)絡(luò)協(xié)議對(duì)其進(jìn)行處理后，確實(shí)將警告的總數(shù)量降到了24%。

面對(duì)一個(gè)少量一個(gè)大量的兩份報(bào)告，開(kāi)發(fā)人員一般都會(huì)忽略掉數(shù)量大的報(bào)告，而選擇數(shù)量少的報(bào)告。相反地，根據(jù)不同的污染輸入源對(duì)這些警告進(jìn)行分組處理。通過(guò)流分析方式，開(kāi)發(fā)人員可以將注意力主要放在那些存在較高概率報(bào)告出漏洞的警

告上面。通過(guò)了解錯(cuò)誤是如何進(jìn)入源代碼中的這一問(wèn)題，對(duì)警告進(jìn)行審查的工作也變得比較簡(jiǎn)單。

本文集中對(duì)數(shù)據(jù)流分析的耗時(shí)進(jìn)行了研究，包括流程敏感分析、過(guò)程間分析和上下文相關(guān)的數(shù)據(jù)流分析。但是，對(duì)源代碼進(jìn)行的處理也應(yīng)該可以使用較少耗時(shí)的算法，事后，再用較多的時(shí)間對(duì)輸入源標(biāo)記的特殊的警告進(jìn)行驗(yàn)證研究。由于Coverity 分析過(guò)程往往會(huì)消耗多個(gè)小時(shí)，因此消耗額外的幾分鐘對(duì)數(shù)據(jù)流進(jìn)行分析并不影響分析的結(jié)果。相對(duì)于Findbugs工具的分析，Java源代碼量比較小，整個(gè)分析過(guò)程會(huì)在幾秒鐘完成，并且數(shù)據(jù)流分析也主要集中在對(duì)網(wǎng)絡(luò)輸入進(jìn)行處理的少量代碼上。而為了對(duì)數(shù)據(jù)庫(kù)進(jìn)行處理，需要傳輸更多的信息，因此污點(diǎn)分析變得更加的復(fù)雜。為了降低復(fù)雜性，可以主要研究軟件的設(shè)計(jì)。如果本文沒(méi)辦法對(duì)數(shù)據(jù)庫(kù)的輸入進(jìn)行區(qū)分，那么整個(gè)數(shù)據(jù)庫(kù)讀取流程將被認(rèn)定為是污染點(diǎn)。在這種情況下，污點(diǎn)分析可能將會(huì)對(duì)源代碼中的大量的代碼考慮使用別的分析方式，但是，如果能很好地區(qū)分，那么污點(diǎn)分析可以繼續(xù)執(zhí)行并且可以獲得比較好的結(jié)果。

4　結(jié)　語(yǔ)

本文展示了靜態(tài)代碼分析過(guò)程中只對(duì)可能被外部用戶數(shù)據(jù)所影響的警告進(jìn)行過(guò)濾分析的益處。通過(guò)執(zhí)行數(shù)據(jù)流分析和只報(bào)告或者分析這些特定的源代碼，開(kāi)發(fā)人員可以了解威脅的來(lái)源以獲取更多漏洞的信息。并且對(duì)那些有較高概率被標(biāo)記為漏洞警告的優(yōu)先級(jí)的確定和審查也比較容易識(shí)別，這主要是因?yàn)閷⒛切┎皇軄?lái)源影響的警告和受到安全來(lái)源影響的警告進(jìn)行了區(qū)分。分析可得，如果只對(duì)被污染的源代碼進(jìn)行分析，如降低四分之一被分析的代碼(未受污染的代碼)數(shù)量，就可以減少分析所消耗的時(shí)間，得出的警告的數(shù)量減少到了總數(shù)量的五分之一，漏洞的數(shù)量從5%增加到了將近25%。這樣減少了開(kāi)發(fā)人員所必須審查的無(wú)用的警告的數(shù)量，從而提高了靜態(tài)代碼審核工具的準(zhǔn)確性，為開(kāi)發(fā)人員節(jié)省了審計(jì)漏洞的時(shí)間。

從開(kāi)發(fā)人員對(duì)產(chǎn)生威脅的數(shù)據(jù)源和小型報(bào)告感興趣的情況來(lái)看，本文對(duì)警告進(jìn)行優(yōu)先級(jí)劃分的方法將使得開(kāi)發(fā)者在快速開(kāi)發(fā)周期中獲益，而在這樣的周期中開(kāi)發(fā)者恰恰難以保證所有的警告都得到更正。

[1] Brian Chess,Gary McGraw.Static Analysis for Security[J].IEEE Security and Privacy,2004,2(2):76-79.

[2] David Evans,David Larochelle.Improving Security Using Extensible Lightweight Static Analysis[J].IEEE Software,2002,19(1):42-51.

[3] John Viega,Gary McGraw,Tom Mutdosch,et al.Statically Scanning Java Code: Finding Security Vulnerabilities[J].IEEE Software,2000,17(5):68-77.

[4] Steve Lipner.The Trustworthy Computing Security Development Lifecycle[C]//Computer Security Applications Conference,2004:45-48.

[5] Baca Dejan,Petersen Kai,Carlsson Bengt,et al.Static Code Analysis to Detect Software Security Vulnerabilities—Does Experience Matter?[C]//Availability,Reliability and Security,2009:804-810.

[6] Baca D,Carlsson B,Lundberg L.Evaluating the cost reduction of static code analysis for software security[C]//Proceedings of the Third ACM SIGPLAN Workshop on Programming Languages and Analysis For Security (Tucson, AZ, USA, June 07-13, 2008). PLAS ’08. ACM, New York, NY, 2008:79-88.

[7] Attila Szegedi,Tamas Gergely,Arpad Beszedes,et al.Verifying the Concept of Union Slices on Java Programs[C]//Software Maintenance and Reengineering, European Conference on,11th European Conference on Software Maintenance and Reengineering (CSMR’07),2007:233-242.

[8] Cathal Boogerd,Leon Moonen.On the Use of Data Flow Analysis in Static Profiling, Source Code Analysis and Manipulation[C]//IEEE International Workshop on,2008 Eighth IEEE International Working Conference on Source Code Analysis and Manipulation,2008:79-88.

[9] http://www.coverity.com/services/.

[10] http://baike.so.com/doc/2150444.html.

[11] Hallem S,Chelf B,Xie Y,et al.A system and language for building system-specific, static analyses[C]//Proceedings of the ACM SIGPLAN 2002 Conference on Programming Language Design and Implementation,2002:69-82.

[12] Tok T B,Guyer S Z,Lin C.Efficient flow-sensitive interprocedural data-flow analysis in the presence of pointers[C]//15th International Conference on Compiler Construction (CC),2006:17-31.

[13] Gary McGraw.Software Security:Building Security In[J].IEEE Security & Privacy,2006,2(3):6.

IMPROVED SECURITY WARNING ALGORITHM BASED ON CODE POLLUTION IDENTIFICATION

Niu Shuangxia1Lü Zhuo1Zhang Wei1,2Mo Jiansong1,2

1(ElectricPowerResearchInstitute,StateGridHenanElectricPowerCompany,Zhengzhou450000,Henan,China)2(HenanEpriGaokeGroupCo.,Ltd,Zhengzhou450000,Henan,China)

Since static code auditing tools have the features of automation and less error-prone, developers often use them to detect code vulnerabilities. However the results of the vulnerabilities detected will generate a lot of warning messages, and have to be manually examined and corrected by developers. The disadvantage of such tools will waste a lot of time of them. In this paper, we determine whether the defects warned really be used or not by tracking user inputs and sensitive data flow, thereby reduce the number of numerous warnings generated in static detection tools. Meanwhile we provide developers with more real warning messages which actually threaten the software. For the shortcomings of the static code auditing tools, we study three different ways to improve the performance of them. First, for commercial static code analysis tool coverity, we re-analyse the results, and create a set of specific warnings from the security point of view. Secondly, we modify the open source code analysis tool Findbugs, and only analyse those codes to be tainted by user inputs. Thirdly, we develop an auditing tool for grey box, which focuses on XSS (cross-site scripting) vulnerabilities in Java code, and use data flow analysis to determine the entry point of vulnerabilities. Experimental results show that the project B reduces the warning numbers by 20% and the project E produces 2% of warnings only, the number of warnings produced by a tool is lowered, and this provides the developers with more information to discriminate whether the warning is a real security threat.

CoverityFindbugsXSSVulnerability

2015-01-12。江蘇省未來(lái)網(wǎng)絡(luò)創(chuàng)新研究院“未來(lái)網(wǎng)絡(luò)前瞻性研究項(xiàng)目”(BY2013095-4-05)。牛霜霞，高工，主研領(lǐng)域：信息安全。呂卓，工程師。張威，工程師。莫堅(jiān)松，高工。

TP3

A

10.3969/j.issn.1000-386x.2016.08.008