SQL注入漏洞的自動化測試:輸入變異方法(半機翻有刪減)
Web服務越來越多地應用於各種領域,從nance和e-government到社交媒體。由於它們是基於Web技術構建的,因此它們也遭受了前所未有的攻擊和滲透。在這些攻擊中,那些針對SQL注入漏洞的攻擊在過去幾年一直排名第一。在上線Web服務之前進行測試以檢測此類漏洞至關重要。我們在本文中提出了一種自動化測試方法,即μ4SQLi,以及它的基礎變異運算元集。μ4SQLi可以產生有效的輸入,從而導致可執行和有害的SQL語句。可執行性是關鍵,否則不能利用注入漏洞。我們的評估表明,該方法對於檢測SQL注入漏洞併產生繞過現實世界中常見配置的應用程式防火牆是有效的。
介紹
在本文中,我們提出了一種針對SQLi漏洞的黑盒自動化測試方法,稱為 μ4SQLi。
從一般的初始測試用例開始,我們的方法應用了一組特定設計的變異運算元,以增加產生成功SQLi攻擊的可能性
更具體的說,這種新的攻擊模式是通過在同一輸入上應用多個變異運算元來生成。此外,我們的一些變異運算元旨在模糊注入的SQL程式碼片段以繞過安全過濾器,例如Web應用程式防火牆(WAF),而其他則旨在修復可能由先前突變引起的SQL語法錯誤。因此,我們的方法可以生成測試輸入,這些輸入可以生成語法正確且可執行的SQL語句,這些語句可以揭示SQL漏洞(如果存在)。通過產生繞過防火牆並導致可執行SQL語句的SQLi攻擊,我們確保找到可利用的漏洞而不是無法利用的漏洞,例如因為過濾器阻止了所有攻擊。此外,我們的方法產生的具體樣本攻擊可以幫助開發人員x原始碼或安全過濾器的配置。我們的方法是完全自動化的,並且由名為 Xavier3的工具提供支援。
我們已經在一些暴露Web服務介面的開源系統上評估了我們的方法。與稱為Std的基線方法相比,該方法由最新的137種已知SQLi攻擊模式組成,我們的方法更快,並且顯著更有可能在有限的時間預算內檢測漏洞。此外,當主題系統受到WAF保護時,Std產生的洩露漏洞的任何輸入都不能通過防火牆,而我們的方法仍然可以產生大量輸入,通過防火牆並顯示全部已知的漏洞。
本文的其餘部分安排如下:第2部分提供了有關SQLi漏洞和審查相關工作的背景知識。第3節介紹了我們提出的變異運算元和安全測試方法和工具。第4節介紹了評估以及對結果和有效性威脅的討論。最後,第5節總結了這項工作。
背景和相關工作
本節提供有關Web服務和SQLi漏洞的簡要背景,並回顧以前有關SQLi測試的工作。
背景
在使用資料庫的系統(例如基於Web的系統)中,用於訪問後端資料庫的SQL語句通常由本機應用程式程式碼視為字串。這些字串是通過根據使用者選擇或應用程式的控制來連線不同的字串片段而形成的流。一旦形成SQL語句,就會使用特殊函式將SQL語句傳送到要執行的資料庫伺服器。例如,SQL語句形成如下(在案例研究中,我們的一個Web服務的簡化示例):
$sql = "Select * From hotelList where country ='"; $sql = $sql . $country; $sql = $sql . '"'; $result = mysql_query($sql) or die(mysql_error());
變數$country
是使用者提供的輸入,它與SQL語句的其餘部分拼接,然後儲存在字串變數$sql
中。字串然後傳遞給函式 mysql_query 查詢,該查詢將SQL語句傳送到要執行的資料庫伺服器。
SQLi是一種攻擊技術,攻擊者將惡意SQL程式碼片段注入這些輸入引數。當輸入引數直接在SQL語句中使用而沒有經過適當的驗證或消毒時,這種攻擊是可能的。攻擊者可能以改變生成的SQL語句行為的方式構造輸入值,使攻擊者能夠對資料庫執行操作,而不是應用程式開發人員所希望的操作。這些操作可能導致敏感資料暴露,未經授權插入或更改資料,丟失資料,甚至控制資料庫伺服器。
在前面的示例中,如果輸入$country
的值為 ‘ or 1 = 1 – 生成的SQL語句將是:
Select * From hotelList where country='' or 1 = 1 --'
第一個引號閉合原語句中的引號,最後的雙短劃線註釋掉原語句最後的一個引號,使得結果SQL語句在語法上有效。子句 or 1 = 1 是重言式,即條件將始終為真,繞過where子句中的原始條件並返回表中的所有行。
為避免此類攻擊,應用程式開發人員使用過濾器來防止惡意輸入影響應用程式的行為。開發人員必須小心,不要阻止可能類似於惡意輸入的有效輸入。例如,使用拒絕單引號輸入的過濾器可以防止前一個示例中的攻擊。但是,過濾器也會拒絕單引號參與的有效輸入(例如,O’Brian)
Web服務是面向服務的體系結構的基本模組,它提供了在Web上輕鬆訪問和交換資訊的工具。每個Web服務都提供一組可由客戶端呼叫的操作。操作類似於傳統程式語言中的方法,它具有一組輸入引數並返回結構化輸出。 Web服務的介面和功能通常由公共可用的Web服務描述語言(WSDL)檔案描述。
在本文中,我們考慮被測服務的輸入引數的SQLi漏洞:如果輸入引數在服務實現的任何SQL語句中使用,並且通過此引數,攻擊者可以傳送,則輸入引數容易受到SQLi攻擊惡意輸入,可以更改SQL語句的預期邏輯。要利用此類漏洞,攻擊者必須提供導致可執行SQL語句的輸入。否則,結果語句將被資料庫拒絕,因此無法訪問或更改資料。
相關工作
之前關於SQLi檢測的研究使用了白盒和黑盒方法來檢測漏洞。幾種白盒方法使用汙點分析來識別無效輸入
進入SQL語句。 Fu和Qian 建議使用符號執行來識別需要滿足的約束以導致SQLi攻擊。 Shar等人。 使用原始碼的資料探勘來預測漏洞。除了要求訪問原始碼之外,正如我們之前提到的那樣,並非總是可能的,這些方法中的大多數在其演算法的某些方面依賴於一組已知的漏洞模式。
在生成測試用例時,現有的黑盒方法也依賴於已知的注入模式。Ciampa等提出了一種方法,分析合法和惡意測試用例的輸出,包括錯誤訊息,以瞭解有關後端資料庫的型別和結構的更多資訊。然後,此資訊用於製作更有可能成功揭示漏洞的攻擊輸入。 Antunes等還分析了使用惡意和合法輸入來檢測漏洞時應用程式行為的差異。黃等人使用了一種使用已知攻擊模式的測試生成方法。
各種學術和線上安全源已經列舉和討論了已知的 SQLi 模式。但是,依賴這些模式可能不足以測試應用程式,因為攻擊者總是找到利用漏洞的新技術。此外,對於相同的模式,可能存在大量不同的表示,例如,使用不同的編碼
一些方法提出了執行時預防技術 而不是測試技術。在大多數這些方法中,靜態分析用於收集程式可以生成的所有可能形式的SQL語句。在執行時,如果SQL語句的結構與這些收集的表單中的任何一個都不匹配,則該語句為被視為潛在的攻擊。 Sekar結合了汙點分析和策略來檢測執行時的注入攻擊。執行時預防方法是測試方法的補充,也可以用作測試的有效預言。
在我們之前的論文中,我們發現使用執行時預防技術為 oracle 提高了 SQLi 測試的檢測率。我們還確定了對更復雜的 oracle 的需求,該 oracle 可以推斷已發現漏洞的可利用性。在本文中,我們嘗試通過增強 oracle 來評估形成的攻擊的可執行性來解決這個問題。惡意輸入可以成功地規避所有安全機制,但由此產生的攻擊可能會產生不可執行的SQL語句,因此不會提供漏洞可利用的證據。
已經提出並廣泛研究了變異測試作為評估測試套件充分性的方法,其中測試程式被變異以模擬故障。 Shahriar和Zulkernine 定義了SQLi特定的變異運算元來評估測試套件在解決SQLi漏洞方面的有效性。 Fonseca等人也使用突變分析比較商業安全測試工具的有效性。我們在本文中提出的變異運算元會改變測試輸入,以增加觸發漏洞的可能性,而不是測試中的程式,以評估測試套件在發現故障時的有效性。
霍勒等人提出了一種名為 LangFuzz 的方法,通過改變輸入程式碼來測試直譯器的安全漏洞,例如記憶體安全問題。該方法已成功應用於發現 Mozilla JavaScript和PHP直譯器中的缺陷。但是,我們的方法在各方面都有所不同:
(1)我們針對需要不同變異運算元和測試生成技術的SQL注入漏洞; (2)在SQL漏洞的情況下,失敗的可觀察性比尋找崩潰更具挑戰性;
我們需要攔截SUT與其資料庫之間的通訊,以分析SQL語句的可執行性和漏洞檢測。
方法
我們提出了一種自動化技術,即 μ4SQLi,用於檢測SQLi漏洞。我們的技術依賴於一組變異操作符,這些操作符操縱輸入(合法的)以建立新的測試輸入以觸發SQLi攻擊。
此外,這些運算子可以以不同的方式組合,並且多個運算子可以應用於相同的輸入。這使得生成包含新攻擊模式的輸入成為可能,從而增加了檢測漏洞的可能性。
具體而言,我們希望生成可繞過Web應用程式防火牆並生成可執行SQL語句的測試輸入。WAF可能會阻止SQLi攻擊並阻止易受攻擊的Web服務被利用。因此,有效的測試輸入需要通過WAF才能到達服務。此外,它們應該導致可執行的SQL語句,否則不太可能出現安全問題,因為資料庫引擎會拒絕它們,因此不會洩漏或洩露任何資料。
本節介紹我們提出的用於生成測試資料的變異運算元。對於每個變異運算元及其定義,提供了一個具體的例子。在一些運算子中,我們還討論了它們關於輸入和先前應用的運算子的前提條件。然後,我們將討論我們的測試生成技術和我們開發的支援該技術的自動化工具。
變異運算元
變異操作符(MO)可以按其用途分為以下三類:行為改變,語法修復和混淆。表1提供了所有變異運算元的摘要。
表一:變異運算子摘要分為行為改變,語法修復和混淆運算子。
行為改變
- 向輸入新增OR子句
- 在輸入中新增AND子句
- 新增分號後跟另外的SQL語句
這類變異操作符會改變輸入,目的是在應用程式易受SQLi攻擊時更改應用程式的預期行為。例如,突變輸入可能導致應用程式返回比預期更多的資料庫行,從而將敏感資料暴露給未經授權的使用者。我們定義了以下改變行為的運算子:
運算子:MO_or
將 OR x = x 新增到SQL語句的WHERE子句中,其中x是隨機數或用單引號或雙引號括起來的字元。
示例:
來自原始輸入:1; MO_or 產生突變輸入:1 OR 1 = 1。因此,如果接受輸入的SQL語句預先定義為
"SELECT * FROM table WHERE id = "+ input
則輸入將更改語句的邏輯並將其轉換如下:
SELECT * FROM table WHERE id = 1 OR 1 = 1
運算子:MO_and
將 AND x = y 新增到SQL語句的WHERE子句中,其中x和y是隨機數或用單引號或雙引號括起來的單個字元,x不等於y。
示例:
原始輸入:1,突變輸入:1 AND 1 = 2。
例如,這將轉變為預定語句:
"SELECT * FROM table WHERE id ="+ input
變成:
SELECT * FROM table WHERE id = 1 AND 1 = 2
因此,否定原始語句的邏輯。
運算子:MO_semi
在輸入中新增分號(;)後跟另外的SQL語句。生成的查詢的格式為sql stmt1; sql stmt2,其中sql stmt1是原始SQL語句,sql stmt2是從預定列表中隨機選擇的SQL語句。
示例:
原始輸入:1,變異輸入:1; SELECT waitfor(5) FROM dual
這改變了預定語句:
"SELECT * FROM users WHERE id = "+ input
變成:
SELECT * FROM users WHERE id = 1; SELECT waitfor(5) FROM dual
語法修復
- 將括號附加到有效輸入
- 向輸入添加註釋命令( - 或#)
- 為輸入新增單引號或雙引號
如前所述,SQLi攻擊旨在通過注入惡意輸入來更改應用程式的行為。因此,惡意輸入本身應包含SQL語句片段。與常規有效輸入不同,這種型別的輸入在與其目標(即預定義的SQL語句)組合時可能導致SQL語法錯誤。
由於我們提出的方法是一種黑盒技術,因此測試生成器不知道預定義的SQL語句語法,因此生成不會導致語法錯誤的輸入很困難。這類變異操作符會改變輸入,目的是在遇到SQL語法錯誤時嘗試修復它們。我們在這個類中定義的變異運算子如下:
運算子:MO_par
在輸入的末尾附加右括號。
示例:
原始輸入:67,變異輸入:67).當用 MO_or MO_cmt 進一步突變輸入時,獲得的突變輸入將是:67)OR 1 = 1 -{}-。讓我們考慮一個預定語句:
"SELECT * FROM table WHERE character = CHR("+input+")"
其中函式CHR將整數轉換為其對應的Unicode字元。更改的SQL語句:
SELECT * FROM table WHERE character = CHR(67) OR 1 = 1 -)
運算子:MO_cmt
向輸入新增SQL註釋命令(雙短劃線和#)。註釋命令後面的任何SQL都不會執行。
示例:
原始輸入:67,在使用MO_or 和 MO_Par 變異後:67) or 1 = 1。這會將預定義語句
"SELECT * FROM table WHERE character = CHR("+input+")"
更改為組合語句,這會導致語法錯誤:
SELECT * FROM table WHERE character = CHR(67)OR 1 = 1 )
然後我們應用MO_cmt來獲得:67)OR 1 = 1# 最終的語句:
SELECT * FROM table WHERE character = CHR(67) OR 1 = 1#)
應用此突變會導致解析器忽略最後一個括號,從而避免由於括號數不均衡而導致的解析器錯誤。
運算子:MO_qot
向突變體新增單引號(’)或雙引號(“)。
示例:
原始輸入:Smith,用MO突變或:Smith OR 1 = 1。這會將預定語句:
"SELECT * FROM table WHERE name ='"+input+"'"
更改為組合語句,這不會導致所需的行為更改,因為將突變體視為字串文字:
SELECT * FROM table WHERE name ='Smith OR 1 = 1')
在使用MO_qot和 MO_cmt進一步變異後:Smith’ OR 1 = 1#,最終的語句是
SELECT * FROM table WHERE name ='Smith' OR 1 = 1#)
這在語法上是正確的並且改變了邏輯原始宣告。
混淆運算子
- 更改空格的編碼
- 更改用引號括起來的字元文字的編碼
- 將輸入的編碼更改為HTML實體編碼
- 將輸入的編碼更改為百分比編碼
- 重寫布林表示式,同時保留它的真值
- 通過隨機化大寫和插入註釋來混淆SQL關鍵字
一些應用程式使用輸入過濾器(例如,web應用程式防火牆)來防禦SQLi攻擊。本質上,WAF檢查每個輸入以檢查SQLi攻擊中通常使用的可疑字串模式,例如SQL關鍵字,並阻止它們。例如,WAF使用黑名單來定義禁止的字元或字串,以確定輸入是否可疑。在實踐中,許多安全關鍵系統受到這些過濾器的保護。例如,處理信用卡資料的軟體系統必須使用WAF來防止攻擊並符合行業安全標準。混淆變異操作符試圖通過將輸入變為語義上等效的輸入但是以不同的形式來避免過濾。這可能會阻止過濾器識別變異輸入中的禁用字元/字串。我們定義了以下混淆變異運算子:
運算子:MO_wsp
用語義等效字元(+,/**/ 或unicode編碼:%20,%09,%0a,%0b,%0c,%0d和%a0)替換空格。
示例:
原始輸入:1 OR 1 = 1,突變輸入:1 + OR + 1 = 1。這會更改預定義語句:
"SELECT * FROM table WHERE id ="+ input
為:
SELECT * FROM table WHERE id = 1 + OR + 1 = 1
運算子:MO_chr
用等效表示替換用引號(’c’)括起來的字元文字,其中c是任意可列印的ASCII字元。等效表示是:
- 短二進位制表示,例如,’a’被替換為b’1100001’。
- 長二進位制表示,例如,’a’被替換為二進位制’1100001’。
- Unicode表示,例如,’a’被替換為n’a’。
- 十六進位制表示,例如,’a’被替換為x’61’。
示例:
原始輸入:1,用 MO_or:1 OR’a’=’a’,進一步用 MO_chr突變:1 or ‘a’= x’61’。這改變了預定語句:
"SELECT * FROM table WHERE id ="+ input
為:
SELECT * FROM table WHERE id = 1 OR'a'= x'61'。
運算子:MO_html
使用HTML實體編碼更改突變體的編碼。在HTML實體編碼中,字元可以用兩種方式編碼:
(a)形式為&#N的數字字元引用,其中N是十進位制或十六進位制表示中使用的字符集中字元的程式碼位置; (b)形式為&SymbolicName的字元實體引用。例如,“是單引號字元(’)的編碼。
示例:
原始輸入:1,用 MO_or :1 OR’a’=’a’,進一步用 MO_html 突變:1 or “a”: = “a” 這將轉換預定語句:
"SELECT * FROM table WHERE id =" + input
為:
SELECT * FROM table WHERE id = 1 OR "a" = "a"。
運算子:MO_per
使用百分比編碼更改突變體的編碼:%HH,其中HH是指向字元ASCII碼的兩位十六進位制值。例如,單引號字元(’)編碼為%27。
示例:
原始輸入:1,用 MO_or:1 OR’a’=’a’,進一步用MO_Per進行突變:1 OR%20’a’=’a’。
這將轉換預定語句:
"SELECT * FROM table WHERE id ="+ input
為:
SELECT table WHERE id = 1 OR%20'a'='a'
運算子:MO_bool
用等效的布林表示式替換布林表示式。例如,布林表示式1 = 1在MO中使用或者可以被混淆為not false = !!1。兩個表示式都評估為true,在混淆之後保持突變體的相同語義。
示例:
原始輸入:1,用MO_or:1 OR 1 = 1,進一步用 MO_bool突變:1 OR not false = !! 1
這將預定義語句
"SELECT * FROM table WHERE id ="+ input
為:
SELECT * FROM table WHERE id = 1 OR not false = !! 1
運算子:MO keyw
使用不同的技術對SQL關鍵字和運算子進行混淆:隨機更改某些字母的大小寫,在關鍵字中間添加註釋或使用替代表示替換關鍵字。大多數SQL解析器都不區分大小寫,例如關鍵字 select,SELECT或SeLeCt都是有效的。一些解析器接受在關鍵字中間包含註釋的關鍵字(例如sel /comment here / ect.)。最後,一些關鍵字具有替代形式,例如OR也可以表示為 ||。
示例:
原始輸入:1,用MO_or:1 OR 1 = 1,MO鍵的進一步突變:1 || 1 = 1。這會更改預定義語句:
"SELECT * FROM table WHERE id ="+input
為:
SELECT * FROM table WHERE id = 1 || 1 = 1。
測試生成
可以將單個或多個不同型別的變異運算元應用於單個輸入引數以生成所需輸入。後一種情況旨在檢測細微的漏洞,這些漏洞只能通過組合多個變異運算元生成的輸入來觸發。例如,考慮一個通過搜尋可以使用其中一個行為改變運算子生成的已知攻擊模式來輸入輸入的應用程式。要形成成功的攻擊,必須首先應用行為改變運算子,然後應用一個或多個混淆運算子。
每個突變鏈都必須從一個有效的測試用例開始,這樣可以滿足被測應用程式的輸入驗證。從有效的測試用例開始,可以確保避免生成由於輸入或不太可能隨機生成的複雜輸入結構之間的依賴性而被應用程式直接拒絕的測試用例。
此外,有效的測試用例具有更有可能滿足輸入驗證併到達應用程式的關鍵部分(例如SQL查詢)的好處。例如,如果某個應用程式需要信用卡號碼以及我們希望改變的其他輸入,則信用卡號碼必須遵循一種良好的格式;否則測試用例會立即被拒絕。使用所提出的方法,可以重用現有功能測試套件中的有效測試用例,或者,如果不存在此類測試套件,則可以使用SoapUI4和類似工具手動建立有效的測試用例。
演算法1正式定義了測試生成演算法:從有效的測試用例開始,每個輸入都被預定的次數變異。apply_MO(第4行)函式隨機將一個或多個變異運算子應用於當前輸入。該函式使用一種簡單的語法,該語法定義了組合運算子的不同合法方法,並確保應用運算子的所有前提條件都得到滿足。然後使用更新的測試用例TC0呼叫被測操作。如果是oracle存在漏洞,則會檢查因呼叫而發出的所有SQL語句。如果可執行SQL語句的百分比(即,不包含語法錯誤的語句)高於預定閾值P,則將輸入報告為易受攻擊並儲存測試用例以幫助測試工程師進行除錯並解決漏洞(第5-8行在我們的實驗中,我們選擇P = 100%,這意味著所有觸發的SQL語句都必須是可執行的。
演算法1測試生成演算法:
輸入
TC:測試用例:ArrayOf(input)
OP:要測試的Web服務操作輸出
TS:針對SQLi漏洞的測試套件
V:易受攻擊的輸入集
下圖顯示了由我們的方法生成的SOAP訊息(測試用例)的示例。這裡引數minPrice,maxPrice和start的輸入值與原始測試用例保持一致,而引數country的輸入值已經變異以包含SQLi攻擊。
測試oracle
當惡意輸入傳送到目標系統時,如果成功,可能會導致系統出現異常。在大多數情況下,異常行為的表現可能是從目標系統返回的結果(例如,顯示非預期內容的網頁)或周圍環境(例如,崩潰,對作業系統的非法呼叫或對資料的非預期訪問)提供服務。在我們的實驗中,因為我們專注於SQL注入,所以我們部署了一個數據庫代理,它攔截目標系統與其資料庫之間的通訊,以識別輸入是否有潛在危害。例如,我們可以將 GreenSQL 用於此目的。之前的一項將GreenSQL 與類似工具進行比較的研究發現,它在檢測SQL注入攻擊方面是最有效的。
在我們之前的工作中已經討論了使用資料庫代理作為oracle的細節。通常,使用正常的資料庫訪問來部署和訓練資料庫代理。這些訓練資料是系統的常規使用或現有功能測試套件的執行的結果。基於訓練資料,代理學習合法SQL語句的規則模式。一旦經過培訓,代理將繼續觀察系統與其資料庫之間的流量,並在識別可疑資料庫查詢時發出警報。
每個警報對應一個數據庫SQL語句,一個測試用例可能導致多個SQL語句,從而導致多個警報。為避免因訓練不完整而導致誤報,可能需要手動檢查以驗證所有已標記的 SQL語句實際上指向了系統中的漏洞。
工具
提出的變異方法已經實現為Java工具,稱為Xavier6。它可用於測試基於SOAP的Web服務的SQLi漏洞。下圖顯示了該工具的關鍵元件(測試生成器和監視器)以及它在實踐中的使用方式。測試生成器將要測試的Web服務的WSDL檔案作為輸入,併為每個必須測試的Web服務操作提供示例測試用例。
這樣的樣本測試用例可以通過專業工具(如SoapUI)或現有方法輕鬆生成。然後,該工具檢查示例測試用例以查詢操作的所有輸入引數,並使用我們的突變方法生成的SQLi攻擊替換每個引數,一次一個。修改過的測試用例將被髮送到被測試的Web服務(圖中的SUT)。在某些設定中,可能會在測試生成器和SUT之間部署Web應用程式防火牆(WAF元件)。 oracle元件(gure中的DB代理元件)觀察SUT與其資料庫之間的互動以檢測惡意SQL語句。
最後,Xavier的Monitor元件不斷查詢 oracle 元件,以瞭解生成的輸入是否顯示SQLi漏洞。在Xavier中,我們集成了GreenSQL來攔截SQL語句。資料庫代理使用學習方法來檢測SQLi漏洞。因此,必須在學習階段對其進行培訓,以識別合法的SQL語句。在檢測階段,代理將所有先前未學習的截獲語句視為SQLi攻擊
如果它形成語法正確的SQL,則會進一步分析每個可疑的惡意語句。攻擊者只能利用SQLi漏洞,如果他能夠以產生的SQL語句沒有語法錯誤的方式注入惡意輸入。否則,攻擊者無法達到他的目標,例如,獲取/修改資料或改變應用程式的控制
如果沒有執行惡意宣告。 MySQL-Proxy7工具用於監視SQL語句是否已執行或執行期間是否存在錯誤。
結論
我們在本文中介紹了一種針對SQL注入漏洞的自動變異技術,該工具由一個工具支援,該工具專注於改變Web服務引數的輸入值。該技術利用一組變異運算元,能夠
(1)生成具有修改服務行為的高可能性的輸入,
(2)糾正輸入以消除由於突變導致的可能的語法錯誤
(3)混淆攻擊以增加他們通過防火牆進行攻擊的機會。
我們技術的最終目標是生成隨機輸入,以通過可執行的SQL語句檢測SQL漏洞,通過防火牆,並過度暴露或破壞資料庫中的資料。我們的實驗結果表明,我們的技術和工具比實踐狀態標準攻擊模式表現更好,並且檢測SQL注入漏洞的概率很高,即使存在防火牆,並且具有合理數量的測試每個服務中每個輸入引數的大小寫執行。