基于AOP與SQL結構分析的SQLIAs動態檢測及防御

何成萬, ,,

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

0 概述

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

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

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

1 相關研究

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

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

2 方法步驟

基于AOP與SQL語句結構分析的SQLIAs動態檢測及防御方法,核心是對源碼中的SQL語句在參與到查詢前后的邏輯結構進行比較,通過校驗被構造出的SQL語句邏輯結構是否一致來判斷SQL注入的發生。本方法分為2個步驟,即代碼靜態分析和SQL語句動態捕獲,其中,代碼靜態分析借助代碼分析工具獲取程序中包含的所有SQL語句結構;SQL語句動態捕獲借助AOP技術在程序執行過程中自動獲取包含用戶輸入數據的SQL語句。對上述2個SQL語句的邏輯結構進行分析比較,如果結果一致,即靜態SQL模型值與動態捕獲的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);

…

}

對上述代碼進行靜態分析后得到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。

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

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

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

2.1 靜態分析

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

圖2 靜態分析流程

靜態分析具體步驟如下:

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

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

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

2.2 動態捕獲

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

圖3 動態捕獲流程

動態捕獲具體步驟如下:

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

2)分別捕獲方法調用的Signature信息和方法調用上傳遞的參數值信息。

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

3 方法實現

3.1 靜態分析實現

靜態分析部分具體實現過程如下:

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

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

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

…

Iterator hi = hotspots.iterator();

while (hi.hasNext()) {

…

String sf = sa.getSourceFile(e);

…

}

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

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 動態捕獲實現

動態捕獲部分具體實現過程如下:

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

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

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

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

(2)讀取經過靜態分析生成的SQL語句模型文件,并依次遍歷其內容。

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

動態捕獲與SQL邏輯結構比較的偽代碼如下:

{

…

//存儲含有SQL攻擊行為對應的靜態SQL語句模型

String staticStr=“”;

if (常規校驗) {

//動態調用SQL查詢語句的環境信息

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

//動態SQL串的完整信息

String dSqlInfor=sourceLocationInfor[1]+

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

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

…

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

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

…

if (不完全匹配) {

…

//得到對應的靜態SQL串staticStr

return proceed(staticStr);

}

…

}

return proceed(dSqlStr);

…

}

4 實驗結果與分析

4.1 實驗準備

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

圖4 靜態分析結果

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

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

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

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

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

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

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

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

4.2 方法性能分析

4.2.1 測試用例設計

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

針對以上執行流程的介紹,考慮到測試一次的結果不穩定且不具有代表性,因此,在前臺頁面處模擬多次提交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層與數據庫交互的代碼段前后添加時間標記代碼用于記錄執行的時間差,測試代碼如下:

PerformanceMonitor.beginMethod();

rs=stmt.executeQuery(sql);

PerformanceMonitor.endMethod();

PerformanceMonitor.printPerformace();

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

4.2.2 數據分析與比較

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

表2 執行時間實驗結果 ms

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

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

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

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

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

4.3 與現有SQLIAs防御方案的比較

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

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

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

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

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

5 結束語

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

[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] 洪 貴.面向方面軟件開發沖突問題的研究[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.