改進的基于代碼污染識別安全警告的算法

牛霜霞　呂　卓　張　威,2　莫堅松,2

1(國網河南省電力公司電力科學研究院　河南 鄭州 450000)2(河南恩湃高科集團有限公司　河南 鄭州 450000)

?

改進的基于代碼污染識別安全警告的算法

牛霜霞1呂卓1張威1,2莫堅松1,2

1(國網河南省電力公司電力科學研究院河南 鄭州 450000)2(河南恩湃高科集團有限公司河南 鄭州 450000)

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

CoverityFindbugsXSS漏洞

0　引　言

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

少量真正有意義和大量晦澀難懂的警告信息雜糅在一起造成了開發者忽視靜態檢測工具產生的結果這一模糊情形。從某種角度，開發者認為這些警告不能帶來麻煩或者產生真正的危害，從而認為警告信息沒什么意義。本文將展示如何通過已有的靜態代碼檢測工具進行一些限定，使得產生的結果報告更高效簡潔。本文通過限定檢測的對象為任何受到外部源影響的源代碼，來降低產生的警告數量并且準確的定位由用戶數據產生的源代碼漏洞。

1　背　景

雖然目前有很多關于靜態代碼分析技術和一些關于靜態檢測效果的文獻，但是很少有文獻研究靜態分析工具是如何用于企業和會給企業帶來什么樣的問題。文獻[6]羅列出了大量的警告，但是這些警告很難進行歸類[5]，因此，開發人員很難分辨出與安全相關的警告。有必要確定一個外部攻擊的警告的子集，這樣可以使得開發人員更容易確定哪些警告對于安全性來說是重要的。

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

從對這類文獻的研究來看，在產業化開發中，對靜態代碼工具的使用策略以及檢測報告的正確評估是很有必要的。

2　研究方法

因為開發人員經常會忽略或誤解安全警告，本文需要想辦法來區分那些非常可能被開發人員誤認為是安全相關的標識的警告，需要將源代碼分割成很多部分。這些分割后的代碼可以直接或者間接地被用戶數據所影響，同時代碼并不能被外部非用戶數據來源所影響。本文通過研究流程敏感分析、過程間分析和上下文相關的數據流分析方法解決上述問題。由于這種方法非常詳細和精確，在某些情況下可以使用更簡單、快速的分析方法，但是為了簡單起見在本文所有的分析中都是用相同的分析方法。數據流分析通常用于編譯器的優化[7]中，在這個領域中，有無數的課題和研究利用了此種方法。因為本文關注已經被分析但還沒有統一化的C++和Java代碼，所以本文采用了幾種已知的流分析方式和程序模塊化方式，而并不是用自己定義的方法去解決。

圖1　污點輸入源層次結構圖

為了更好地篩選安全警告，首先，本文必須確定源代碼中的數據入口點。入口點可以是任何類型的用戶數據、甚至套接字、文件操作或其他的用戶輸入的操作。這是通過在不同的特定輸入源中進行簡單的詞法分析來實現的。然而，仍有一些局限需要被解決。第一，對所有可能的輸入源做數據流分析往往會導致大部分代碼都被標記為污染代碼，因此，有必要將輸入源限定為特定的輸入類型或者追蹤那些被不同的輸入源污染所影響的代碼。本文通過結合這兩種方法并且允許審核者決定如何處理輸入源才能得到最好的結果。第二，由于面向對象的程序設計往往只有一個程序類，并且該程序類執行了由詞法分析所確定的套接字操作，因此有必要繼續進行分析并確定哪些代碼或類使用了基礎套接字類。這個操作可以創建輸入源的層次結構[8]，并且可以更加充分將結構展示給開發人員，以便開發人員能夠確定威脅的根源。圖1展示了這種層次結構。在這個例子中，輸入源B和C是開發人員所關心的，而輸入源A只是一個基類。

在確定了一個輸入源之后，數據流分析將表明用戶數據是如何通過源代碼進行傳播的。因為本文關心那些可以被服務軟件用戶所利用的漏洞，所以只需要在網絡中檢查輸入源。一些檢查器將用戶數據所影響到的每一行都將被標記成被污染的代碼，并對被污染的源代碼進行專門的標記。比如，一個循環執行N次取決于用戶輸入變量的大小，然而，用戶輸入本身從來沒有在循環內使用過。因此循環并不會直接被污染，與此同時緩沖區溢出檢查器也會檢查被污染的代碼。

由于在面向對象的設計中，數據路徑分析往往會中斷和創建新的片段，分析將會從代碼中原始類或對象所使用的位置開始重新啟動。通過這種方式，本文可以將程序片段從開始到結束進行傳遞，如果數據流分析的過程中發現了已經被污染的代碼有相同的上下文內容，它將會終止分析跟蹤，以節省分析所消耗的時間。

最終的結果將是一個包含被污染的和未被污染的源代碼樹，以及帶有可能污染路徑的層次結構輸入源。

由于Coverity[9]工具是一個商業化的非開源的源碼工具，不能對其代碼進行修改來分析被污染的代碼。不過本文可以對Coverity工具分析的結果和污染源代碼進行比較，如果一個警告存在于被污染的代碼部分，可以根據它們的輸入源進行組合，忽略未被污染的源代碼中產生的警告。

本文可以改變Findbugs[10]工具的源代碼，用此工具對被污染的源代碼進行數據流分析。為了確保所有的被需要的代碼都包括其中，還必須要加入變量初始化和其他的一些代碼以保證分析不會失敗。本文只對被污染的代碼進行一個標準的Findbugs工具分析，來減少Findbugs工具分析時所必須檢查的行數。

3　研究結果

3.1Coverity工具的分析

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

表1　Coverity工具分析結果

表2　改進的Findbugs工具結果

工程B明顯降低了警告的數目，使得開發者有意愿對每個警告進行檢查，而這些警告有可能危及產品的安全性或穩定性。但是與工程A進行對比，工程B的每行代碼同樣有較低數量的警告產生。由于污點分析，本文確保那些被忽略的警告并不是可利用的安全警告，因此，提高了靜態代碼分析工具的準確性。

3.2改進的Findbugs工具

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

與C/C++產品相比，Java產品只有少量的警告產生[13]。因為Java產品并未對用戶數據執行任何繁重的計算，這種設計也意味著會有較少的代碼受到用戶輸入的直接影響。這樣產生的少量的警告，使得審計者可以更加容易的對其進行核查。對于工程D來說，兩個輸入源盡管有著不同的代碼路徑，卻有著基本完全相同的警告。經過其數據流分析之后，工程E就只產生了先前2%的警告。

3.3灰盒靜態代碼審計工具

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

限制靜態代碼審計工具來報告所有代碼中可能的錯誤看上去好像很奇怪，然而，如果一個開發團隊處在一個輕量級的開發上，大量的警告并不會在每一個版本發布出來前被盡數更正。事實上，這樣一來靜態代碼審計產生的結果很難在項目開發中占有一個較高優先級的位置。對于靜態代碼審計工具來說，能將那些可以被認定為是安全威脅的警告與那些不可以被認定為是安全威脅的警告區分開來是非常重要的事情。不管是執行靜態分析前還是進行分析后，都可以通過執行污點分析的方法將安全漏洞從其他的漏洞中區分出來。當使用Coverity工具時，工程A出現的警告數超過了1600個。如果假設每檢查一個警告平均耗時3分鐘，那么，對所有的這些警告進行審查將要需要80個小時。在輕量級產品開發中，這是一個非常耗時并且不實用的開發。當使用3種不同的網絡協議對其進行處理后，確實將警告的總數量降到了24%。

面對一個少量一個大量的兩份報告，開發人員一般都會忽略掉數量大的報告，而選擇數量少的報告。相反地，根據不同的污染輸入源對這些警告進行分組處理。通過流分析方式，開發人員可以將注意力主要放在那些存在較高概率報告出漏洞的警

告上面。通過了解錯誤是如何進入源代碼中的這一問題，對警告進行審查的工作也變得比較簡單。

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

4　結　語

本文展示了靜態代碼分析過程中只對可能被外部用戶數據所影響的警告進行過濾分析的益處。通過執行數據流分析和只報告或者分析這些特定的源代碼，開發人員可以了解威脅的來源以獲取更多漏洞的信息。并且對那些有較高概率被標記為漏洞警告的優先級的確定和審查也比較容易識別，這主要是因為將那些不受來源影響的警告和受到安全來源影響的警告進行了區分。分析可得，如果只對被污染的源代碼進行分析，如降低四分之一被分析的代碼(未受污染的代碼)數量，就可以減少分析所消耗的時間，得出的警告的數量減少到了總數量的五分之一，漏洞的數量從5%增加到了將近25%。這樣減少了開發人員所必須審查的無用的警告的數量，從而提高了靜態代碼審核工具的準確性，為開發人員節省了審計漏洞的時間。

從開發人員對產生威脅的數據源和小型報告感興趣的情況來看，本文對警告進行優先級劃分的方法將使得開發者在快速開發周期中獲益，而在這樣的周期中開發者恰恰難以保證所有的警告都得到更正。

[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。江蘇省未來網絡創新研究院“未來網絡前瞻性研究項目”(BY2013095-4-05)。牛霜霞，高工，主研領域：信息安全。呂卓，工程師。張威，工程師。莫堅松，高工。

TP3

A

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