基于AOP與SQL結構分析的SQLIAs動態(tài)檢測及防御

何成萬, ,,

(武漢工程大學 計算機科學與工程學院,武漢 430205)

0 概述

SQL注入漏洞[1]是網(wǎng)站中一種普遍存在的安全隱患。隨著Web應用程序的應用越來越廣泛,SQL注入攻擊(SQL Injection Attacks,SQLIAs)[2]成為Web應用系統(tǒng)當前面臨的最大威脅。文獻[3]統(tǒng)計出2013年十大Web應用安全隱患,SQLIAs名列第1位。SQLIAs指攻擊者通過惡意構造的輸入數(shù)據(jù)拼接到表單頁面的文本輸入框中,通過欺騙服務器執(zhí)行惡意構造的SQL命令而得到臟數(shù)據(jù)信息,從而達到攻擊的目的。之前典型的SQL注入[4]更多的是針對服務器端的數(shù)據(jù)庫,然而根據(jù)目前HTML5規(guī)范,攻擊者可以采用完全相同的辦法執(zhí)行 JavaScript 或其他代碼訪問客戶端數(shù)據(jù)庫從而竊取數(shù)據(jù)。因此,如何更加有效地防御SQLIAs成為十分重要的研究課題。

面向方面編程(Aspect-Oriented Programming,AOP)[5]的核心思想是以方面的形式捕捉橫切關注點,即以模塊化的方式、程序語言支持及工具支持來捕捉橫切關注點。AOP在方面的定義上引入通知、切入點、連接點等機制以實現(xiàn)各個方面間的聯(lián)系[6]。其優(yōu)點是可有效地將目前糾纏在功能需求中的非功能需求代碼剝離出來,在代碼級別上實現(xiàn)關注點分離。

現(xiàn)有的多數(shù)SQLIAs檢測防御方法只對部分SQLIAs有效,不能檢測出所有的SQLIAs。為此,本文提出一種基于AOP與SQL結構分析的SQLIAs動態(tài)檢測及防御方法,借助AOP技術,結合靜態(tài)分析與動態(tài)捕獲的方式比較SQL語句的邏輯結構,從攻擊的根源對SQLIAs進行有效檢測和防御。

1 相關研究

之前,研究者們在SQLIAs的檢測與防御方面做了許多工作,提出了一些新的技術方案。具體情況如下:

文獻[7]提出的JDBC-Checker技術,能夠阻止的SQLIAs非常有限。文獻[8]提出SQLGuard模型,其原理是在運行過程中推導出SQL語句樹,并對比用戶輸入前后的 SQL 樹結構是否有變化。該方法直接生成2棵SQL語句樹進行匹配,優(yōu)點是不需要對語句樹設置唯一標識,缺點是生成了多個源樹。文獻[9]針對基于Java的Web應用程序,如jsps、servlets、Frankl 等提出一種自動移除SQLIAs的工具,該技術通過靜態(tài)分析與程序轉(zhuǎn)換相結合的方式,在代碼中自動修復SQL注入漏洞。文獻[10]提出一種智能動態(tài)查詢評估技術,通過學習和預測用戶輸入的SQL查詢目的,將已經(jīng)確定的SQL結構與用戶輸入之后生成的查詢結構進行比較,以此檢測可能的攻擊。文獻[11]提出一種認證機制,其使用先進的加密標準來阻止SQLIAs,該加密標準使用哈希函數(shù)保存密碼和用戶ID,使每個用戶在服務器端都保存有用戶名、密碼和密鑰這3個重要參數(shù)。該技術的缺點是重用性低。文獻[12]提出一種基于錯誤和異常檢測技術的SQLIAs檢測框架,該框架的主要思想是通過分析被提交到數(shù)據(jù)庫的合法查詢行為創(chuàng)建一個文件,根據(jù)這些合法的行為特征識別可能的SQLIAs。文獻[13]提出使用逆向代理和MD5算法檢測用戶輸入的SQLIAs,使用語法表達式的規(guī)則檢測URL地址中的SQLIAs。文獻[14]針對SQLIAs提出一種新策略,即代碼指針屏蔽(CPM),該策略先實施正確的語義代碼指針,然后依據(jù)CPM 監(jiān)控指針的變化,以此轉(zhuǎn)移應用程序控制流。

2 方法步驟

基于AOP與SQL語句結構分析的SQLIAs動態(tài)檢測及防御方法,核心是對源碼中的SQL語句在參與到查詢前后的邏輯結構進行比較,通過校驗被構造出的SQL語句邏輯結構是否一致來判斷SQL注入的發(fā)生。本方法分為2個步驟,即代碼靜態(tài)分析和SQL語句動態(tài)捕獲,其中,代碼靜態(tài)分析借助代碼分析工具獲取程序中包含的所有SQL語句結構;SQL語句動態(tài)捕獲借助AOP技術在程序執(zhí)行過程中自動獲取包含用戶輸入數(shù)據(jù)的SQL語句。對上述2個SQL語句的邏輯結構進行分析比較,如果結果一致,即靜態(tài)SQL模型值與動態(tài)捕獲的SQL串完全匹配,則為一次正常請求;如果結果不一致,則表示此次請求已被惡意構造改變了原有SQL語句的邏輯結構,可以將其視為一次SQLIAs。

在詳細介紹本文方法之前,先以一個簡單的示例來說明方法的基本思想。在接收用戶輸入后參與構造SQL語句的程序代碼如下:

public static User findUser(String userName,

String password){

User user=null;

String sq1=“select * from user_qw where”;

Connection conn=DBUtil.getConnection();

Statement stmt=conn.createStatement();

sq1+=“username=′”+userName+“′ and pwd=′”+password+“′”;

ResultSet rs=stmt.executeQuery(sq1);

…

}

對上述代碼進行靜態(tài)分析后得到SQL語句結構:select * from user_qw where username=′′and pwd=′′。

如果用戶輸入合法的用戶名(如“guest”)和密碼(如“123”),則程序構造的SQL語句為select * from user_qw where username=′guest′ and pwd=′123′。由于該SQL語句結構和上述通過代碼分析得到的SQL語句結構一致,因此判斷該查詢不包含SQLIAs。

如果用戶試圖發(fā)動攻擊,輸入含特殊字符的用戶名(如“′or 1=1--”),則構造后的SQL語句為select * from user_qw where username=′′or 1=1--′ and pwd=′′。由于該SQL語句結構和上述通過靜態(tài)分析得到的SQL語句結構不一致,因此判斷該查詢是一次SQLIAs。

本文方法的整體結構框架如圖1所示。

圖1 SQLIAs檢測及防御方法框架

2.1 靜態(tài)分析

靜態(tài)分析的主要功能是通過分析得到源程序中要執(zhí)行的每個SQL語句所對應的靜態(tài)語句串,保存該靜態(tài)語句串,其中SQL語句中出現(xiàn)的變量參數(shù)以空字符串表示,同時記錄下每個SQL語句執(zhí)行點對應的執(zhí)行周圍環(huán)境,包括執(zhí)行點位置信息、Signature簽名信息。靜態(tài)分析部分要在Web應用程序第一次部署的時候完成,其流程如圖2所示。

圖2 靜態(tài)分析流程

靜態(tài)分析具體步驟如下:

1)分析Web應用程序中JDBC函數(shù)庫與數(shù)據(jù)庫之間實現(xiàn)交互的函數(shù)接口特征,并定位應用程序中出現(xiàn)的交互點,即含有變量且將被送往數(shù)據(jù)庫被執(zhí)行的SQL語句點。

2)通過靜態(tài)分析獲取每個交互點的位置信息、Signature信息及靜態(tài)SQL語句模型。

3)將以上獲取到的信息保存至本地文件中,保存的順序為交互點位置信息、Signature信息、靜態(tài)SQL語句模型。

2.2 動態(tài)捕獲

針對已經(jīng)執(zhí)行過靜態(tài)分析的Web應用程序,借助AOP技術,首先聲明方面,然后在JDBC函數(shù)庫與數(shù)據(jù)庫交互的接口位置定義切入點,請求到達后執(zhí)行通知函數(shù)中的校驗流程,此即動態(tài)捕獲,其具體流程如圖3所示。

圖3 動態(tài)捕獲流程

動態(tài)捕獲具體步驟如下:

1)根據(jù)靜態(tài)分析得到的接口處方法名,在JDBC函數(shù)庫與數(shù)據(jù)庫交互的接口方法處自動生成切入點函數(shù),使得SQL語句在被送往數(shù)據(jù)庫服務器執(zhí)行之前,先執(zhí)行切入點的通知函數(shù)。

2)分別捕獲方法調(diào)用的Signature信息和方法調(diào)用上傳遞的參數(shù)值信息。

3)根據(jù)動態(tài)SQL語句的Signature信息唯一確定其對應的靜態(tài)SQL語句模型,將動態(tài)SQL語句串與靜態(tài)SQL模型的邏輯結構進行比較。如果結果一致,則提交數(shù)據(jù)庫,繼續(xù)后續(xù)操作;否則,視為一次SQLIAs行為。

3 方法實現(xiàn)

3.1 靜態(tài)分析實現(xiàn)

靜態(tài)分析部分具體實現(xiàn)過程如下:

1)先分析源應用程序的后臺代碼與數(shù)據(jù)庫的交互接口,查找當前所有的交互點,一般的Web應用程序利用JDBC函數(shù)庫與數(shù)據(jù)庫進行交互,通過分析庫函數(shù)的接口,如java.sql.Statement.execute Query(String sql),了解這些函數(shù)的Signature信息,進而得到需要執(zhí)行的SQL字符串在這些函數(shù)中的參數(shù)位置,即交互點[15]。其中如果所有SQL語句字符串執(zhí)行前后都不存在可變量,或者SQL字符串不會被提交到后臺數(shù)據(jù)庫,就不能將其算作交互點。

2)借助靜態(tài)分析工具JSA(Java String Analyzer[16],該工具是一個用于分析已編譯的類文件中字符流和字符串操作的開源工具),對所需應用程序編譯后的class文件進行靜態(tài)分析,即得到每個交互點的靜態(tài)SQL語句模型、Signature信息及交互點位置信息。調(diào)用JSA庫函數(shù)的一些核心代碼如下:

ObjectInputStream in = newObjectInputStream(new FileInput Stream(“sql.reg”));

…

Iterator hi = hotspots.iterator();

while (hi.hasNext()) {

…

String sf = sa.getSourceFile(e);

…

}

3)擴展JSA庫函數(shù),在其庫函數(shù)AnalyzeSQL類文件中添加寫入本地指定文件中的寫方法,即將靜態(tài)分析得到的交互點位置信息、Signature信息以及靜態(tài)SQL語句模型按照先后順序保存在本地文件中。由于除了保存靜態(tài)SQL語句模型,還有交互點位置和對應的Signature信息,因此可以唯一標識該靜態(tài)SQL語句模型。JSA庫函數(shù)擴展代碼如下:

String staticSQLModel=

quoteString(diff.getShortestExample(true));

String sqlStaticInfor=

line+“,”+sf+“,”+staticSQLModel.substring(1,staticSQLModel.length()-1);

File f = new File(“文件路徑名”);

BufferedWriter output = new BufferedWriter(new FileWriter(f,true));

output.write(sqlStaticInfor+“ ”);

output.close();

3.2 動態(tài)捕獲實現(xiàn)

動態(tài)捕獲部分具體實現(xiàn)過程如下:

1)借助AOP技術首先定義方面和切入點,使得SQL語句在被送往數(shù)據(jù)庫服務器執(zhí)行之前,先執(zhí)行切入點的通知函數(shù),在通知函數(shù)中獲取需要的信息。根據(jù)由靜態(tài)分析得到的SQL語句信息,判斷出對應該處執(zhí)行的數(shù)據(jù)庫交互函數(shù)的方法名,根據(jù)該方法名自動生成AOP程序的切點函數(shù)。

2)編寫call(Signature)和args([TypePatterns]|[Identifiers])切入點,在通知函數(shù)中使用this Joint Point類來捕獲方法調(diào)用上的Signature信息和傳遞的參數(shù)值信息,從而得到動態(tài)SQL語句串。核心實現(xiàn)代碼如下:

public aspect CaptureCallParametersPecipe {

pointcut captureCallParameters(String dSqlStr) :

call(java.sql.ResultSet

java.sql.Statement.executeQuery(String))

&& args(dSqlStr);

before(String dSqlStr):captureCallParameters(dSqlStr) {

…

String signature=thisJoinPoint.getStaticPart().getSignature();

String sourceLine=thisJoinPoint.getStaticPart().

getSourceLocation();

String dSql=dSqlStr;

String[] sourceLocationInfor=sourceLine.toString().split(“:”);

…

}

3)如上述代碼所示,動態(tài)捕獲到的信息有SQL執(zhí)行點的位置、源文件的類名、實時SQL語句串。此處SQL語句串中包含從外部輸入拼接進去的參數(shù),因此,在與靜態(tài)SQL語句模型進行比較之前需要先對動態(tài)SQL進行去參處理。由于靜態(tài)分析情況下得到的信息也按照上述順序依次保存,通過執(zhí)行點的位置信息和源文件的類名信息可以唯一確定執(zhí)行的SQL語句,因此只有三部分完全匹配才能證明該動態(tài)SQL語句串與靜態(tài)SQL模型值匹配成功。具體比較過程如下:

(1)對由動態(tài)捕獲到的SQL語句串進行去參處理。

(2)讀取經(jīng)過靜態(tài)分析生成的SQL語句模型文件,并依次遍歷其內(nèi)容。

(3)按照信息保存的順序,依次比較動態(tài)SQL語句串與靜態(tài)SQL模型值的SQL執(zhí)行點位置、源類文件名稱、SQL語句串值,只有三部分完全相同,才能說明該動態(tài)SQL語句值與靜態(tài)SQL值完全匹配,即SQL結構沒有被改變,然后繼續(xù)后續(xù)操作;否則,視為一次SQLIAs。

動態(tài)捕獲與SQL邏輯結構比較的偽代碼如下:

{

…

//存儲含有SQL攻擊行為對應的靜態(tài)SQL語句模型

String staticStr=“”;

if (常規(guī)校驗) {

//動態(tài)調(diào)用SQL查詢語句的環(huán)境信息

String[] sourceLocationInfor=thisJoinPoint. getStaticPart().getSourceLocation().toString().split(“:”);

//動態(tài)SQL串的完整信息

String dSqlInfor=sourceLocationInfor[1]+

“,”+sourceLocationInfor[0]+“,”+newDsqlStr;

//讀取靜態(tài)分析文件,查找對應的SQL并比對 BufferedReader reader= new BufferedReader(new FileReader(file);

…

//遍歷靜態(tài)模型值,與動態(tài)獲取的SQL串進行比較

for (int i = 0; i < staticSqlModelList.size(); i++) {

…

if (不完全匹配) {

…

//得到對應的靜態(tài)SQL串staticStr

return proceed(staticStr);

}

…

}

return proceed(dSqlStr);

…

}

4 實驗結果與分析

4.1 實驗準備

根據(jù)本文方法的介紹,靜態(tài)分析部分是在系統(tǒng)應用程序部署之前要提前執(zhí)行的。首先需要對測試對象的應用程序中與數(shù)據(jù)庫交互的Java類文件做靜態(tài)分析,用JSA分析工具分析其對應編譯后的class文件,并得到對應的執(zhí)行點以及該位置的Signature信息,為每一個執(zhí)行點生成對應的靜態(tài)SQL模型,并將這些語句串按照執(zhí)行點位置、源類文件及靜態(tài)SQL串的順序保存在本地文件中。在本次實驗中設計一個簡單的Web項目,包含用戶登錄頁面,其中與數(shù)據(jù)庫交互的UserDAO.java類文件中包含提交數(shù)據(jù)庫執(zhí)行的非安全編碼SQL查詢語句。針對本實驗的測試項目對所需類文件進行靜態(tài)分析的結果如圖4所示。

圖4 靜態(tài)分析結果

分析完UserDAO文件后,在其保存的文件中會執(zhí)行的SQL語句完整信息為:

26,UserDAO.java,select * from user_qw where username=′′and pwd=′′

解析完后會得到該文件中所有將執(zhí)行的SQL語句以及執(zhí)行點的位置和源類名。

在登錄界面動態(tài)構造重言式攻擊,即用戶名輸入“′or 1=1--”,密碼輸入“123”,點擊登錄,執(zhí)行后臺查詢用戶的方法,借助AOP技術在切入點的通知函數(shù)中動態(tài)捕獲到的SQL語句完整信息為:

26,UserDAO.java,select * from user_qw where username=′′or 1=1--′ and pwd=′′

由此可知,對由靜態(tài)分析與動態(tài)捕獲到的SQL串值按照執(zhí)行點位置、源類名、SQL語句值的順序依次進行比較,在構造重言式攻擊后得到的動態(tài)SQL語句值與靜態(tài)分析下得到的SQL語句不一致,因此,將其視為一次SQLIAs。

為了增強說服性,本次實驗共列舉了如表1所示的6種攻擊形式來構造測試用例,通過將靜態(tài)SQL模型值與動態(tài)獲取的SQL串進行匹配,根據(jù)匹配的結果判斷是否存在SQLIAs。

表1 不同攻擊類型的測試用例對應的防御結果

4.2 方法性能分析

4.2.1 測試用例設計

下面分別對本文方法在插入AOP程序前后2種情況下的執(zhí)行時間進行比較分析。首先,該方法的正常訪問執(zhí)行流程為:部署項目→瀏覽器輸入URL地址請求→根據(jù)請求訪問后臺action→調(diào)用DAO層的數(shù)據(jù)庫交互代碼→執(zhí)行SQL查詢命令。插入AOP程序后程序的執(zhí)行流程為:部署項目→瀏覽器輸入URL地址請求→根據(jù)請求訪問后臺action→調(diào)用DAO層的數(shù)據(jù)庫交互代碼→在executeQuery方法執(zhí)行之前執(zhí)行方面代碼→執(zhí)行SQL查詢命令。

針對以上執(zhí)行流程的介紹,考慮到測試一次的結果不穩(wěn)定且不具有代表性,因此,在前臺頁面處模擬多次提交URL地址請求,測試腳本代碼如下:

function test(){

var begin = new Date();

for(var i= 0; i < 500; i++){

document.getElementById("formId").submit();

}

var end = new Date();

console.log(end-begin);

}

在后臺DAO層與數(shù)據(jù)庫交互的代碼段前后添加時間標記代碼用于記錄執(zhí)行的時間差,測試代碼如下:

PerformanceMonitor.beginMethod();

rs=stmt.executeQuery(sql);

PerformanceMonitor.endMethod();

PerformanceMonitor.printPerformace();

PerformanceMonitor類主要用于監(jiān)控目標代碼在執(zhí)行前后所需要的時間差,其中包含3個方法,beginMethod用于標記開始時間,endMethod用于標記介紹時間,printPerformance用于輸出兩者的時間差。

4.2.2 數(shù)據(jù)分析與比較

本文采用4組實驗進行測試,前2組分別為插入AOP程序前正常請求與發(fā)生攻擊行為情況下的數(shù)據(jù)測試與記錄;后2組分別為插入AOP程序后正常請求與發(fā)生攻擊行為情況下的數(shù)據(jù)測試與記錄。每組實驗需要記錄的數(shù)據(jù)為測試單數(shù)執(zhí)行時間、測試多數(shù)執(zhí)行總時間。因為無論是正常請求還是發(fā)生注入攻擊時,SQL在數(shù)據(jù)庫中的查詢時間是固定的,僅受實驗平臺的影響,所以在記錄數(shù)據(jù)時考慮記錄下插入AOP程序前后的單次執(zhí)行時間。實驗詳細記錄情況如表2所示。

表2 執(zhí)行時間實驗結果 ms

根據(jù)表2所記錄的實驗結果,分別將1組、3組(正常請求下的響應時間)和2組、4組(發(fā)生攻擊下的響應時間)進行比較。首先由1組、3組時間值可看出,單次執(zhí)行情況下,插入AOP程序前后響應時間分別為1 ms和8 ms;執(zhí)行500次的情況下,插入AOP程序前后執(zhí)行總時間分別為2 656 ms和6 972 ms,此種情況下求得單次平均所需時間值分別為5.312 ms和13.944 ms。其次由2組、4組數(shù)據(jù)可看出,在發(fā)生攻擊行為的情況下,插入AOP程序前后單次響應時間分別為1 ms和7 ms;執(zhí)行500次的情況下,平均單次所需時間分別為5.462 ms和11.662 ms。不同組間數(shù)據(jù)相比較的柱狀圖如圖5和圖6所示。

圖5 1組、3組實驗時間比較

圖6 2組、4組實驗時間比較

通過圖5、圖6數(shù)據(jù)可以看出,不論是正常請求下還是發(fā)生攻擊行為時,插入AOP對程序的執(zhí)行響應時間影響并不大,單次增加值在6 ms～9 ms之間,這完全在用戶可以接受的范圍之內(nèi)。

通過對以上實驗數(shù)據(jù)的分析與比較,可知本文提出的基于AOP的SQLIAs檢測與防御方法在時間性能方面表現(xiàn)良好,沒有造成太大的性能開銷,所以,其不會影響到用戶的體驗。

4.3 與現(xiàn)有SQLIAs防御方案的比較

由于每種防御方案的實驗環(huán)境不一樣,有些源碼并不開放,在查閱了相關研究論文后分別從功能和性能兩方面對本文方法以及部分現(xiàn)有方法進行分析比較,每種防御方法防范能力的比較結果見表3,每種防御方法在實施時所需的部署要求以及自動化程度見表4。其中表3用3種不同類型標記符號表示不同的防御情況:“√”表示該防御方法可以成功阻止此種類型的所有攻擊行為;“×”表示該方法不能防御此種類型的攻擊;“*”表示該方法僅對此類基本的攻擊起到防御作用。

表3 不同防御方法攻擊種類比較

表4 不同防御方法部署要求比較

由表4可以看出,結合靜態(tài)、動態(tài)分析的SQLGuard和SQLChecker技術需要修改源代碼、管理密鑰,而且自動化程度不高;實現(xiàn)基于動態(tài)分析的CSSE系統(tǒng)需要事先修改PHP解釋器;AMNESIA在動態(tài)監(jiān)控部分需要插入監(jiān)控代碼,使得原應用程序性能大為降低,另外還需額外為每個SQL語句模型生成一個唯一的ID進行標識。

相比較而言,本文方法首先通過靜態(tài)分析得到每個SQL執(zhí)行點對應的SQL靜態(tài)模型值,該模型值包括執(zhí)行點位置以及Signature信息,兩者可以唯一確定一個SQL字符串,不需要額外的指定ID進行唯一標識;然后借助AOP技術對用戶輸入數(shù)據(jù)進行動態(tài)捕獲,將結果與之前靜態(tài)SQL模型值進行一一匹配,不存在生成多余SQL語句樹的情況。因此,本文給出的防御方法與現(xiàn)行的防御系統(tǒng)相比,具有易于部署、配置靈活、適用性強等優(yōu)點。

5 結束語

本文提出一種基于AOP與SQL結構分析的SQLIAs動態(tài)檢測及防御方法。根據(jù)代碼靜態(tài)分析的結果自動生成AOP連接點定義,在程序運行過程中動態(tài)獲取包含用戶輸入數(shù)據(jù)的SQL語句,將其與不包含用戶輸入數(shù)據(jù)的SQL語句邏輯結構進行分析比較,從而達到檢測和防御SQLIAs的目的。實驗結果表明,本文方法能有效檢測和防御不同類型的SQLIAs,同時具有容易部署、不需要修改源碼等優(yōu)點。同時實驗數(shù)據(jù)還表明,本文方法在時間性能方面表現(xiàn)良好,即插入AOP程序后不會產(chǎn)生太大的時間開銷。但是本文的研究工作還有不足,基于此,下一步將擴展本文方法,使其能夠適用于更多種類的攻擊類型,同時多比較不同靜態(tài)源碼分析工具的優(yōu)缺點,分析其得到的靜態(tài)信息并研究如何將其無差別地運用到本文方法中。

[1] LIM J,KIM S,KIM D,et al.A designated query protocol for serverless mobile RFID systems with reader and tag privacy[J].Tsinghua Science and Technology,2012,17(5):521-536.

[2] 張 卓.SQL注入攻擊技術與防范措施研究[D].上海:上海交通大學,2007.

[3] GOSWAMI S,KRISHNAN N R,VERMA M,et al.Reducing attack surface of a Web application by open Web application security project compliance[J].Defence Science Journal,2012,62(5):324-330.

[4] SHARMA P,JOHARI R,SARMA S S.Integrated approach to prevent SQL injection attack and reflected cross site scripting attack[J].International Journal of System Assurance Engineering and Management,2012,3(4):343-351.

[5] MENASCE D,GOMAA H,MALEK S,et al.SASSY:a framework for self-architecting service-oriented sys-tems[J].IEEE Software,2011,28(6):78-85.

[6] 洪 貴.面向方面軟件開發(fā)沖突問題的研究[D].長沙:國防科學技術大學,2007.

[7] GOULD C,SU Z,DEVANBU P.JDBC checker:a static analysis tool for SQL/JDBC applications [C]//Proceedings of International Conference on Software Engineering.Washington D.C.,USA:IEEE Press,2004:697-698.

[8] GREGORY B,BUEHRER,BRUCE W,et al.Using parse tree validation to prevent SQL injection attacks[C]//Proceedings of the 5th International Workshop on Software Engineering and Middleware.New York,USA:ACM Press,2005:106-133.

[9] MUI R,FRANKL P.Preventing SQL injection through automatic query sanitization with ASSIST[J].Electronic Proceedings in Theoretical Computer Science,2010,35:27-38.

[10] SELVAMANI K,KANNAN A.ISQL-IDPS:intelligent SQL-injection detection and prevention system[J].European Journal of Scientific Research,2011,51(2):222-231.

[11] KINDY D A,PATHAN A S K.A detailed survey on various aspects of SQL injection in web applications:vulnerabilities,innovative attacks and remedies[J].International Journal of Communication Networks and Information Security,2013,5(2):80-92.

[12] SHAIMAA E S,MOHAMED I M,LAILA M E,et al.Web anomaly misuse intrusion detection framework for SQL injection detection[J].International Journal of Advanced Computer Science and Applications,2012,3(3):123-129.

[13] HIDHAYA S F,GEETHA A.Intrusion protection against SQL injection attacks using a reverse proxy[C]//Proceedings of International Conference on Advanced Computer Science and Information Technology.Washington D.C.,USA:IEEE Press,2012:129-144.

[14] PHILIPPAERTS P,YOUNAN Y,MUYLLE S,et al.CPM:masking code pointers to prevent code injection attacks[J].ACM Transactions on Information and System Security,2013,16(1):1-27.

[15] 竺霞芳.雙層防御SQL注入攻擊的方法[D].武漢:華中科技大學,2011.

[16] LI D,LYU Y,WAN M,et al.String analysis for Java and Android applications[C]//Proceedings of Joint Meeting on Foundations of Software Engineering.New York,USA:ACM Press,2015:661-672.