基于攻擊反饋模型的SQL注入漏洞滲透測試方法

劉 磊 許 靜* 朱靜雯 陳 亮 李 潔

1(南開大學(xué)人工智能學(xué)院 天津 300350) 2(南開大學(xué)軟件學(xué)院 天津 300350) 3(國網(wǎng)天津市電力公司電力科學(xué)研究院 天津 300384)

0 引 言

SQL注入漏洞(SQLIV:SQL Injection Vulnerability)多年以來被列為危害最嚴(yán)重的Web安全漏洞之一[1],它可能會(huì)導(dǎo)致諸如信息泄露或認(rèn)證繞過[2]等多種嚴(yán)重的Web安全問題。滲透測試由于其高效、易用等特點(diǎn),已成為最為重要的SQLIV測試技術(shù)之一。它是一種黑盒動(dòng)態(tài)測試技術(shù),其是在實(shí)際攻擊發(fā)生之前通過測試者的模擬攻擊來檢測Web應(yīng)用漏洞[3]。

傳統(tǒng)的SQL注入漏洞主要是將Web頁面響應(yīng)中顯示的數(shù)據(jù)庫或系統(tǒng)報(bào)錯(cuò)信息作為判定標(biāo)志來進(jìn)行識別的,然而近年來涌現(xiàn)出了多種新型的基于推斷的SQL注入漏洞,其主要又包括基于反饋頁面相似度分析和基于頁面響應(yīng)時(shí)間分析的SQL注入漏洞。它們須通過不同的模擬攻擊策略及頁面反饋信息推斷的方法來進(jìn)行識別,因此其測試的復(fù)雜性和難度隨之急劇增加[3-4]。由于黑盒滲透測試是通過分析模擬攻擊測試HTTP請求的響應(yīng)反饋來檢測漏洞,不同測試用例及其特定響應(yīng)反饋之間具有較為復(fù)雜的攻擊反饋規(guī)律,因而可能造成傳統(tǒng)基于<測試用例(Test Case),預(yù)測結(jié)果(Test Oracle)>鍵值對及用例庫枚舉測試的滲透測試手段的覆蓋度和準(zhǔn)確性的不足,尤其體現(xiàn)在較高的漏報(bào)(FN:False Negative)和誤報(bào)(FP:False Positive)方面[4]。

以往的研究多集中在通過提高對測試響應(yīng)的分析能力來提高SQLIV滲透測試的覆蓋率和準(zhǔn)確度[3,5-6]。其中動(dòng)靜態(tài)檢測相結(jié)合的技術(shù)可以通過白盒方式分析和修改源代碼或后臺(tái)服務(wù)器設(shè)置來增強(qiáng)對反饋響應(yīng)的分析能力[6-7],但是其對于源代碼的依賴極大地限制了它在許多不能訪問到后臺(tái)服務(wù)或源代碼的實(shí)際場景中的應(yīng)用。許多黑盒滲透測試方法采用經(jīng)驗(yàn)錯(cuò)誤模式或特征提取技術(shù)來進(jìn)行反饋響應(yīng)的分析,這些方法通常將測試用例或測試模式作為外部條件因素進(jìn)行考慮,往往采用測試用例順序枚舉的方式進(jìn)行測試[8-10]。然而這種傳統(tǒng)的枚舉式黑盒滲透測試方法已難以應(yīng)對日益增加的測試響應(yīng)反饋規(guī)律的復(fù)雜性。與此同時(shí),隨著測試用例和響應(yīng)反饋之間對應(yīng)規(guī)則模型的不斷增多,極大地增加了測試整體的規(guī)模,也帶來了覆蓋度、準(zhǔn)確性和測試效率之間的權(quán)衡問題[3,11]。

針對上文所述的基于推斷的新型SQL注入漏洞以及傳統(tǒng)滲透測試方法對其測試的準(zhǔn)確度及效率不佳的問題,提出一種基于攻擊樹[12]及反饋分析的攻擊反饋模型AFM(Attack Feedback Model)和滲透測試框架AFTF(Attacking Feedback Testing Framework)。該方法通過自底向上的反饋信息流以進(jìn)行啟發(fā)式的動(dòng)態(tài)SQL注入漏洞滲透測試,從而解決攻擊反饋推斷分析過程中的攻擊策略模擬和反饋時(shí)序分析的問題。該模型由多個(gè)基于反饋的測試階段FT Stage(Feedback based Test Stage)所構(gòu)成的攻擊樹,其每一階段包含一系列基于攻擊子樹的反饋測試單元FT Unit(Feedback based Test Unit)。每個(gè)反饋測試單元是由模擬攻擊測試及其反饋構(gòu)成的攻擊樹模型,對應(yīng)于某個(gè)具體類型的SQL注入漏洞滲透測試,其用于進(jìn)行底層的HTTP測試請求和響應(yīng)的執(zhí)行和分析。

1 基本背景與定義

SQL注入漏洞是通過對基于數(shù)據(jù)庫交互的Web應(yīng)用程序的輸入進(jìn)行篡改而引發(fā)的,當(dāng)經(jīng)過攻擊者惡意編輯過的SQL子句被注入到SQL查詢并被傳輸?shù)胶笈_(tái)數(shù)據(jù)庫時(shí),就會(huì)造成SQL注入漏洞[5-6]。SQL注入漏洞可以存在于URL參數(shù)(GET方法)、網(wǎng)頁表單輸入(POST方法)、HTTP Cookie或Header參數(shù)中。

假設(shè)某網(wǎng)站頁面鏈接中存在SQL注入漏洞“HTTP://www.URL.com/test?customer=Geng&id=123 AND 1=1--”,其注入點(diǎn)位于URL中的參數(shù)“id=123”中,測試用例(注入有效負(fù)載)為“AND 1=1--”,而其最終傳輸?shù)胶笈_(tái)數(shù)據(jù)庫的SQL查詢?yōu)?“ SELECT * FROM Costumers WHERE customer=Geng AND id=123 AND 1=1--”。原始的SQL查詢沒有包含測試用例“AND 1=1--”的部分。因?yàn)橹匮允阶泳洹癆ND 1=1--”不能更改SQL語句的邏輯,顯然注入的SQL查詢邏輯與原始查詢邏輯相同。如果我們將測試用例更改為“AND 1=2--”,HTTP響應(yīng)將會(huì)因矛盾子句“AND 1=2--”引起的邏輯變化而發(fā)生變化。通過對HTTP響應(yīng)相似性變化的觀察,我們可以得知該注入點(diǎn)是否存在SQLIV。

滲透測試是在實(shí)際應(yīng)用中最為常見的SQL注入漏洞黑盒動(dòng)態(tài)測試技術(shù)之一,其主要是通過模擬攻擊者的思路和輸入來對SQL注入漏洞進(jìn)行測試。由于缺少后臺(tái)系統(tǒng)和數(shù)據(jù)庫的詳細(xì)信息,滲透測試通過分析模擬攻擊測試的HTTP響應(yīng)反饋來發(fā)現(xiàn)該注入點(diǎn)是否存在SQLIV。從測試反饋分析方法及手段的角度來看,主要可以將SQL注入漏洞的檢測分為基于頁面相似度、基于數(shù)據(jù)庫錯(cuò)誤和基于頁面反饋時(shí)間這三種類型[5]:

1) 基于反饋頁面相似度(Similarity-Based):分析目標(biāo)SQL查詢的邏輯變化導(dǎo)致測試反饋頁面的相似度變化。

2) 基于反饋的數(shù)據(jù)庫錯(cuò)誤(Error-Based):分析滲透測試中由于違反SQL語法而導(dǎo)致測試反饋頁面包含數(shù)據(jù)庫報(bào)錯(cuò)。

3) 基于反饋時(shí)間延遲(Time-Based):分析由于注入的時(shí)間延遲指令或后臺(tái)計(jì)算指令導(dǎo)致的頁面反饋時(shí)間延遲。

上述三種類型主要是基于SQL注入漏洞攻擊或測試過程中的反饋信息分析方式進(jìn)行定義的。類型1)定義的是基于相似度分析的SQL注入漏洞,在對這種漏洞進(jìn)行判斷識別的時(shí)候一般以原始頁面與測試反饋頁面的相似度變化情況為參照進(jìn)行分析。類型2)的SQL注入漏洞在進(jìn)行漏洞判斷的時(shí)候,是以反饋頁面信息中的數(shù)據(jù)庫錯(cuò)誤為標(biāo)志進(jìn)行分析判斷的。類型3)的漏洞在測試過程中通過發(fā)送時(shí)間延遲的SQL命令并分析測試反饋的返回時(shí)間的延遲情況來判斷是否存在相應(yīng)的漏洞。其中,類型2)是早期最為經(jīng)典的SQL注入漏洞反饋分析方法,而類型1)和類型3)是基于推斷的漏洞判定方法,其發(fā)生頻率不斷增加,且相應(yīng)的漏洞種類也演變得越來越豐富和多樣,因而給SQL注入漏洞的滲透測試帶來了巨大的挑戰(zhàn)。以上述三種反饋分析技術(shù)為基礎(chǔ),本文提出了基于攻擊反饋模型AFM(Attacking Feedback Model)的SQL注入漏洞滲透測試方法,首先我們對基于攻擊反饋的滲透測試策略進(jìn)行了總結(jié)分析,引入了6個(gè)符號以描述基本的測試反饋狀態(tài),如表1所示。符號“EOR”(ERROR)和“NEOR”(NO ERROR)是基于數(shù)據(jù)庫報(bào)錯(cuò)的反饋分析標(biāo)志,例如對字符型注入點(diǎn)注入轉(zhuǎn)義字符“′”可能造成形如“You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ″Geng″”的數(shù)據(jù)庫報(bào)錯(cuò)。這個(gè)錯(cuò)誤不但暴露了該SQL注入漏洞,而且還泄露了數(shù)據(jù)庫類型MySQL和關(guān)鍵詞“Geng”。利用這些竊取到的敏感信息,攻擊者可以進(jìn)一步實(shí)施更為準(zhǔn)確并且危害更大的攻擊,因而其經(jīng)常被作為信息收集和判斷注入點(diǎn)的重要手段。

表1 SQLIV滲透測試響應(yīng)反饋符號定義

符號“SIMI”(SIMILAR)和“CHG”(CHANGE)是基于響應(yīng)頁面相似性的反饋分析標(biāo)志。基于頁面相似度的SQL注入漏洞是根據(jù)注入后的反饋頁面與原始頁面是否相似來判斷是否是一個(gè)漏洞。例如,當(dāng)注入形如“AND 1=1”的重言式時(shí),測試反饋響應(yīng)與原始反饋響應(yīng)相似,其反饋標(biāo)志為“SIMI”;而當(dāng)注入“AND 1=2”的矛盾式時(shí),反饋頁面分析結(jié)果為不相似,其反饋標(biāo)志位“CHG”?；诜答來撁嫦嗨贫鹊腟QL注入漏洞也被稱為“SQL盲注入漏洞”。

符號“DLY”和“NDLY”是基于響應(yīng)時(shí)間的反饋分析標(biāo)志。基于頁面反饋時(shí)間的SQL注入漏洞是根據(jù)注入后的頁面響應(yīng)時(shí)間是否延遲來進(jìn)行判斷的。例如當(dāng)注入形如“SLEEP(n)”的注入語句時(shí),頁面響應(yīng)時(shí)間會(huì)有n秒的反饋延遲,該類型漏洞也被稱為“時(shí)間延遲注入漏洞”。

本文還引入了兩個(gè)符號“V”(Vulnerability)和“NV”(No Vulnerability)來表示測試單元和測試階段的中間檢測結(jié)果?！癡”表示該測試單元或測階段檢測出SQL注入漏洞,“NV”表示無證據(jù)表明在這個(gè)測試單元或測試階段存在SQL注入漏洞。

2 攻擊反饋模型

2.1 基于攻擊反饋的測試單元

在SQLIV滲透測試中,可以通過使用一系列預(yù)先定義好的測試模式來識別漏洞,這些測試模式可能包括多個(gè)測試用例(有效載荷)及其對應(yīng)反饋的組合,如“AND 1=1→SIMI”和“AND 1=2→CHG”的鍵值對模式。傳統(tǒng)的SQLIV滲透測試模式多通過專家經(jīng)驗(yàn)總結(jié)得來,采用基于順序枚舉的方式進(jìn)行滲透測試,但這種測試往往并不充分,不適用于具有復(fù)雜測試序列或時(shí)序的情況。

在本文中,我們定義了基于攻擊反饋的測試單元AFT-Unit來描述SQLIV滲透測試的不同種類和模式,其可以用于描述和分析測試用例及其反饋響應(yīng)的復(fù)雜規(guī)律性,如圖1所示。本文基于攻擊樹的攻擊邏輯及反饋分析路徑給出了六種通用的攻擊反饋測試單元的示例,其包含了常見的SQL注入漏洞判定路徑與三種反饋分析方式的組合信息。每個(gè)測試單元是一個(gè)基于攻擊反饋決策的二叉攻擊樹,其中每個(gè)節(jié)點(diǎn)(除葉子節(jié)點(diǎn)之外)代表一個(gè)測試用例,樹的每條邊代表對于其父節(jié)點(diǎn)的某種反饋響應(yīng),葉節(jié)點(diǎn)代表該測試單元的中間檢測結(jié)果。葉節(jié)點(diǎn)包括“V”和“NV”,其也作為整個(gè)攻擊反饋模型AFM中的反饋響應(yīng)符號。某個(gè)到葉節(jié)點(diǎn)的路徑表示導(dǎo)致某種中間檢測結(jié)果的所有測試用例及其反饋響應(yīng)的組合,如圖1中測試單元S2中的“S20→SIMI→S21→CHG→V”表示某個(gè)基于反饋頁面相似度方式下基于數(shù)字計(jì)算的SQL注入漏洞檢測過程路徑。

圖1給出了反饋測試單元的舉例,包括基于報(bào)錯(cuò)的反饋測試單元(FT-Unit S0和FT-Unit S1),基于頁面相似度的反饋測試單元(FT-Unit S2和FT-Unit S3)和基于時(shí)間延遲的反饋測試單元(FT-Unit S4和FT-Unit S5)。例如,FT-Unit S3表示基于相似性重言式的測試單元,其包括測試用例“AND 1=1--”(S30)和“AND 1=2--”(S31和S32),并且其有兩條不同的測試路徑可以檢測出SQL注入漏洞,通過葉節(jié)點(diǎn)“V”(Vulnerability)來表示。并且本文在反饋測試單元FT-Unit的基礎(chǔ)上引入了基于攻擊反饋的測試階段(FT-Stage:Feedback based Test Stage)來表示包含一系列同類型測試單元的某個(gè)測試階段,如圖2所示。每個(gè)反饋測試階段都包含多個(gè)具有相似檢測方式和測試用例變體的測試單元,這里規(guī)定測試階段中的測試單元按照順序來執(zhí)行。

圖2 基于攻擊樹的攻擊反饋模型AFM(Attacking Feedback Model)

2.2 基于反饋的攻擊樹模型

本文攻擊反饋測試單元FT-Unit所組成的反饋測試階段FT-Stage基礎(chǔ)上,構(gòu)建了SQLIV滲透測試整體的攻擊反饋模型(AFM:Attacking Feedback Model),如圖3所示。

圖3 整體測試框架

本質(zhì)上,攻擊反饋模型是基于反饋測試階段的攻擊樹模型,其包括每個(gè)測試階段FT-Stage的執(zhí)行和每階段響應(yīng)反饋結(jié)果構(gòu)成的路徑,及其最終的測試結(jié)果信息。在攻擊樹模型AFM中,每個(gè)節(jié)點(diǎn)(不包括葉節(jié)點(diǎn))表示一個(gè)特定的測試階段,每一條邊表示前一個(gè)測試階段得到的響應(yīng)反饋,每個(gè)葉節(jié)點(diǎn)表示對于一個(gè)注入點(diǎn)進(jìn)行滲透測試的最終測試結(jié)果。

對于該模型攻擊樹中的反饋邊,我們將其分為兩類:主動(dòng)反饋(包括EOR、CHG、LAG和V)和被動(dòng)反饋(包括NEOR、SIMI、NLAG和NV)。主動(dòng)反饋對應(yīng)的邊意味著其父節(jié)點(diǎn)對應(yīng)的階段至少有一個(gè)特定的測試單元包含該測試反饋結(jié)果。被動(dòng)反饋對應(yīng)的邊表示在前一個(gè)測試階段沒有發(fā)生該階段對應(yīng)的主動(dòng)反饋。攻擊反饋模型的每個(gè)測試階段都包含一組具有相同特征或功能的反饋測試單元,這些測試單元順序執(zhí)行,當(dāng)出現(xiàn)主動(dòng)反饋結(jié)果,或執(zhí)行完所有測試單元時(shí)結(jié)束該測試階段(此時(shí)若未出現(xiàn)該階段特定的主動(dòng)反饋,則該測試階段反饋結(jié)果為對應(yīng)的被動(dòng)反饋),如圖2右上角子圖所示。

攻擊反饋模型有三個(gè)預(yù)測試階段,包括“隨機(jī)字符串預(yù)測試階段”、“轉(zhuǎn)義字符預(yù)測試階段”和“基于相似度的預(yù)測試階段”,其決定了該模型應(yīng)該進(jìn)行哪種類型反饋測試階段。不同的測試階段以及其特定的反饋會(huì)引發(fā)相應(yīng)的測試策略。最終,每條路徑均包含對于整個(gè)測試的最終測試結(jié)果的葉節(jié)點(diǎn)。我們可以對每個(gè)被測注入點(diǎn)采用該模型進(jìn)行測試,從而在目標(biāo)Web站點(diǎn)中有效地檢測SQL注入漏洞。

2.3 基于攻擊反饋模型的測試框架

基于攻擊反饋模型,我們建立了其啟發(fā)式的SQL注入漏洞測試框架,其可以通過收集和分析測試攻擊反饋信息,并利用這些信息指導(dǎo)下階段信息?；诠舴答伳Ｐ偷恼w測試框架如圖3所示,包括三個(gè)層次:基于攻擊樹的反饋測試框架(AFT-Framework:Attacking Feedback based Test Framework)、用于執(zhí)行測試的攻擊反饋測試階段(FT-Stage:Feedback based Test Stage)和基于攻擊子樹的攻擊反饋測試單元(FT-Unit:Feedback based Test Unit)。

基于攻擊樹的攻擊反饋模型對應(yīng)于最上層的測試框架AFT-Framework,其中攻擊反饋測試模型決策模塊用于控制整個(gè)框架的測試過程,基于攻擊樹模型和攻擊反饋分析進(jìn)行反饋測試階段FT-Stage的篩選,調(diào)用測試階段的執(zhí)行模塊,并進(jìn)行每個(gè)測試階段的反饋結(jié)果分析,并根據(jù)上一階段的反饋結(jié)果對下一階段采用的測試階段和測試策略進(jìn)行選擇和控制。

從圖3中各模塊的整體關(guān)系來講,攻擊反饋測試框架三層之間是由左至右逐層循環(huán)調(diào)用執(zhí)行更為細(xì)粒度的測試,并在獲得細(xì)粒度的反饋信息后從右至左逐層反饋至上層模塊進(jìn)行綜合運(yùn)算和分析的過程。該測試框架利用攻擊樹模型選擇出當(dāng)前的反饋測試階段FT-Stage,每個(gè)反饋測試階段FT-Stage用于對某個(gè)測試階段所包含的攻擊反饋測試單元FT-Unit集合進(jìn)行控制,其枚舉執(zhí)行集合中的測試單元。當(dāng)某個(gè)測試單元執(zhí)行后出現(xiàn)主動(dòng)反饋結(jié)果時(shí),或者集合中所有測試單元執(zhí)行完畢,則停止該測試階段的測試,如圖2和圖3所示。測試單元執(zhí)行模塊則是對每個(gè)反饋測試單元FT-Unit進(jìn)行控制和實(shí)施,首先通過攻擊反饋測試單元控制模塊進(jìn)行攻擊子樹的分析,篩選出當(dāng)前的測試用例進(jìn)行注入語句拼接合成,并發(fā)送HTTP請求和接收HTTP響應(yīng),最終進(jìn)行響應(yīng)反饋分析,其反饋分析結(jié)果返回至單元控制模塊后用于指導(dǎo)下一次用于測試用例的篩選和執(zhí)行。

該攻擊反饋測試框架可對基于攻擊樹的攻擊反饋模型進(jìn)行具體的實(shí)施和應(yīng)用,進(jìn)行逐層次的攻擊反饋信息和控制信息傳遞,從而實(shí)現(xiàn)一種反饋信息流自底向上的啟發(fā)式動(dòng)態(tài)滲透測試過程,在提交測試覆蓋度和準(zhǔn)確度的基礎(chǔ)上降低了測試冗余度,從而提高整體的測試效率。

3 實(shí)驗(yàn)及結(jié)果分析

本文基于攻擊反饋測試框架開發(fā)了其原型測試工具,該工具基于“Visual Studio 2010 +.net 3.5+C#”環(huán)境進(jìn)行開發(fā),對攻擊反饋測試模型進(jìn)行了實(shí)現(xiàn)。該原型工具可以對目標(biāo)測試網(wǎng)站中的URL頁面包含的注入點(diǎn)進(jìn)行SQL注入漏洞檢測,這些注入點(diǎn)在實(shí)驗(yàn)之前由第三方的爬蟲工具進(jìn)行抓取。我們同時(shí)選取了兩種第三方SQL注入滲透測試工具進(jìn)行比較實(shí)驗(yàn),包括WVS Acunetix[13]和IBM Security Appscan[14]。Acunetix和Appscan是兩款著名的商用Web應(yīng)用安全測試工具,它們是目前具有代表性的兩款商用滲透測試工具。本文將這兩款測試工具表示為工具A和工具B(沒有特定的順序),并且設(shè)置為其最高級別檢測模式進(jìn)行測試。

為了進(jìn)行實(shí)驗(yàn)對比分析,本文基于開源Web應(yīng)用程序漏洞掃描器評估項(xiàng)目Wavsep(The Web Application Vulnerability Scanner Evaluation Project)[15]進(jìn)行擴(kuò)展,開發(fā)了用于實(shí)驗(yàn)的目標(biāo)漏洞測試系統(tǒng)VulPoc(Vulnerability Proof of Concept)。VulPoc可被用于評價(jià)Web應(yīng)用漏洞檢測工具的綜合檢測能力,基于“PHP 5+MySQL 5”開發(fā),包含7 215個(gè)URL,以及6種類型的158個(gè)植入的SQL注入漏洞,其中122個(gè)漏洞來源于Wavsep項(xiàng)目,另外36個(gè)漏洞由多名專業(yè)Web安全專家進(jìn)行開發(fā)和植入,VulPoc的詳細(xì)信息如表2所示。

表2 目標(biāo)測試系統(tǒng)VulPoc詳細(xì)信息

為了全面評價(jià)SQL注入漏洞的測試能力,本文從以下兩個(gè)方面展開實(shí)驗(yàn):準(zhǔn)確度(Accuracy)和效率(Efficiency)。檢測的準(zhǔn)確度可從召回率R和誤報(bào)FP情況來進(jìn)行評估。對于測試效率,我們是采用測試過程中的HTTP請求數(shù)量(HTTP Requests)作為評估指標(biāo)。之所以采用該指標(biāo),是由于在實(shí)際的SQL注入漏洞滲透測試過程中的網(wǎng)絡(luò)延遲和Web應(yīng)用負(fù)載限制等方面原因,對整體測試效率和時(shí)間影響最大的是其所發(fā)送的HTTP請求數(shù)量,因而可通過平均HTTP請求數(shù)(AHR:Average HTTP Requests)來進(jìn)行測試效率的評估。

召回率R描述了SQL注入漏洞滲透測試工具的檢測覆蓋度情況,其可通過式(1)來表示。其中,RC是召回漏洞數(shù)量,VUL是被測系統(tǒng)中實(shí)際存在的漏洞。

(1)

誤報(bào)FP(False Positives)表述的是檢測工具掃描出的假陽性漏洞,即錯(cuò)誤的掃描結(jié)果,其可通過誤報(bào)率FPR(False Positive Rate)來描述,其表示在所有掃描結(jié)果中誤報(bào)所占的比例,如式(2)所示。其中,FP為誤報(bào)結(jié)果數(shù)。

(2)

對于檢測工具誤報(bào)水平的評估,還可通過檢測每條URL的時(shí)候出現(xiàn)誤報(bào)的概率FPP(False Positive Probability)來衡量。

(3)

表3給出了本文對照實(shí)驗(yàn)的詳細(xì)結(jié)果數(shù)據(jù),其中AFM表示本文所述方法所開發(fā)的原型系統(tǒng),Tool A和Tool B分別表示的是WVS Acunetix和IBM Security Appscan(出于商業(yè)保護(hù)的目的,這里Tool A和Tool B與兩個(gè)工具名稱之間沒有特定的對應(yīng)順序)。可以看到,本文提出的攻擊反饋模型AFM檢測出的有效召回漏洞數(shù)量RC_Num數(shù)量為153,高于工具A和工具B的132和126個(gè),誤報(bào)結(jié)果數(shù)為6,而工具A和工具B的誤報(bào)數(shù)分別為37和22。

表3 實(shí)驗(yàn)結(jié)果數(shù)據(jù)詳細(xì)信息

圖4是在表2基礎(chǔ)上得到的柱狀分析圖,其中包括召回率RCR、誤報(bào)率FPR、誤報(bào)概率FPP、平均HTTP請求數(shù)AHR(Average HTTP Requests)的對比分析信息。圖4顯示出本文所述方法在植入漏洞的被測目標(biāo)系統(tǒng)中的測試召回率RCR為96.8%,誤報(bào)率FPR為3.8%,相較對比工具而言具有更高的召回率、更低的誤報(bào)率,更進(jìn)一步說明了本文所述模型的準(zhǔn)確性更高。

圖4 實(shí)驗(yàn)對比分析結(jié)果圖

同時(shí),AFM模型具有更低的誤報(bào)概率FPP=0.8‰及更低的平均HTTP請求數(shù)AHR=88,而這兩項(xiàng)指標(biāo)在對比工具中工具則最高達(dá)到了5.1‰和298。具有更低的誤報(bào)概率和更低的HTTP請求數(shù)顯示出在大數(shù)據(jù)量的URL測試環(huán)境下,AFM模型在測試每條URL的過程中產(chǎn)生的誤報(bào)較低,同時(shí)其測試效率更高,更加適用于當(dāng)前實(shí)際應(yīng)用中Web應(yīng)用系統(tǒng)規(guī)模和復(fù)雜度都越來越大的情況。

4 結(jié) 語

本文提出了一種基于攻擊反饋模型AFM的Web應(yīng)用系統(tǒng)SQL注入漏洞自動(dòng)化滲透測試方法,通過自底向上的反饋信息流實(shí)現(xiàn)了一種啟發(fā)式的動(dòng)態(tài)滲透測試方法。在攻擊反饋分析的基礎(chǔ)上建立整個(gè)測試模型的反饋測試單元FT-Unit,同時(shí)設(shè)計(jì)了基于反饋測試單元枚舉的反饋測試階段FT-Stage,最終在此基礎(chǔ)上提出了基于攻擊樹的攻擊反饋模型AFM,并設(shè)計(jì)了整體應(yīng)用的測試框架AFTF,從而實(shí)現(xiàn)了一種快速有效的Web應(yīng)用系統(tǒng)啟發(fā)式滲透測試模型。本文建立了基于攻擊反饋測試框架AFTF的實(shí)驗(yàn)原型系統(tǒng),并通過對比實(shí)驗(yàn)給出了其在目標(biāo)測試系統(tǒng)上的實(shí)驗(yàn)對比分析結(jié)果。實(shí)驗(yàn)結(jié)果表明,本文所述方法可在保證較高的測試效率前提下,有效提高Web應(yīng)用系統(tǒng)中SQL注入漏洞滲透測試的準(zhǔn)確度,具有較高的召回率和較低的誤報(bào)率。