SQLMVED：基于多變體執行的SQL 注入運行時防御系統

馬博林，張錚，劉浩，鄔江興

（1.信息工程大學，河南 鄭州 450001；2.網絡通信與安全紫金山實驗室，江蘇 南京 211100）

1 引言

隨著“互聯網+”新業態的快速發展，傳統行業向網絡服務發生轉變，海量的數據存儲在數據庫中，互聯網用戶可以通過結構化查詢語句（SQL,structured query language）隨時隨地訪問網絡服務數據。數據庫遵循國際標準化組織（ISO,International Organization for Standardization）、國際電工委員會（IEC,International Electrotechnical Commission）等發布的統一標準，雖然提高了網絡服務間數據格式的一致性，但易被利用的特性也使網絡服務數據面臨越來越多的安全威脅。

目前，SQL 注入攻擊（SQLIA,SQL injection attack）是危害網絡服務數據安全的主要威脅之一，“OWASP TOP 10”項目最近三次發布的The Ten Most Critical Web Application Security Risks報告顯示，SQLIA 在所有統計的安全威脅分類中連續多年排名首位。

文獻[1]提出了一種基于指令集隨機化的SQLIA 防御方法，通過對SQL 進行隨機化變化，使攻擊者不能預知應用程序的SQL 形式，無法完成SQLIA。該文獻推動了SQLIA 防御方法由SQL 運行前的檢測技術向運行時的主動防御技術轉變，其中的隨機化方法在黑盒環境下能夠有效抵御SQLIA，但是攻擊者一旦通過社會工程學或者在白盒環境下掌握了隨機化方法，調整注入代碼，便能實現有效的SQLIA。

為了解決該問題，本文改進文獻[1]的技術思路，提出了一種基于多變體執行技術的SQLIA防御方法。結合多變體執行與隨機化防御思路，構建SQLIA 運行時防御系統架構，并根據數據的讀、寫操作設計針對性的表決方法，基于Web 服務實現了原型系統SQLMVED（SQL multi-variant execution defense）。安全性評估和實驗測試表明，該方法無論在攻擊者是否掌握了防御機制的情況下，均能夠有效抵御SQLIA。

2 SQL 注入攻擊研究

2.1 SQL 注入攻擊原理

SQL 是用于數據庫查詢、更新和管理的高級非過程化編程語言，最初由IBM 公司研制開發，目前廣泛地應用于程序設計開發中。圖1 給出了典型的Web 服務架構[2]。客戶端通過應用層協議向服務器端發送請求（步驟1)）。服務器通過CGI/FastCGI格式將請求轉發至CG（Icommon gateway interface）應用程序進行解析處理（步驟2)）。執行目標程序，目標程序若執行回調功能代碼，則重復步驟3)；若執行數據庫操作功能代碼，則進行步驟4)，例如程序調用PHP-CGI 中的mysqli_query、oci_execute 等函數；若執行具有系統命令調用功能的代碼，則進行步驟5)。最終，通過步驟6)和步驟7)將服務器端的響應結果返回至客戶端。

圖1 典型的Web 服務架構

SQLIA 的語句執行在步驟4)，攻擊者在用戶輸入中構造惡意SQL，由CGI 將其與目標程序中的SQL 拼接后發送至數據庫執行，從而實現非法操作。相較于發生在步驟3)的代碼注入攻擊和發生在步驟5)的命令注入攻擊，SQLIA 不依賴于操作系統以及應用程序運行環境，在漏洞存在的情況下攻擊實施的門檻較低。

2.2 SQL 注入攻擊威脅

SQLIA 是針對數據庫的攻擊技術，攻擊者利用應用程序開發階段的漏洞或缺乏對輸入驗證，向應用程序中注入惡意SQL，從而達到查詢、更改或刪除數據的目的。根據網絡空間安全[3]的框架劃分，SQLIA 主要是利用應用層的漏洞或后門，破壞數據層的安全性，SQLIA 主要將以下網絡服務特性或功能作為攻擊目標。

1) 繞過身份驗證。網絡服務通常設置身份驗證過程，以用戶輸入與數據庫查詢結果比對的方式實現，攻擊者通過SQLIA 可繞過比對過程，使用非法用戶成功繞過身份驗證。

2) 竊取數據。網絡服務中的大量數據存儲在數據庫中，如身份證號、手機號、銀行卡號等信息，攻擊者通過SQLIA 獲取敏感信息，是竊取數據的主要途徑。

3) 破壞可用性。攻擊者通過SQLIA 不僅可以竊取數據，還可以更改或刪除數據，破壞數據完整性，甚至停止數據庫服務，達到拒絕服務的目的。

4) 數據庫指紋識別。攻擊者通過SQLIA 識別數據庫類型、版本等信息，為發起針對性的0day或APT（advanced persistent threat）攻擊做準備。

5) 繞過輸入檢查。網絡服務為了抵御SQLIA，選擇性地部署外掛式防御措施，對用戶輸入檢查是否存在注入語句，攻擊者通過構造特殊的SQLIA繞過輸入檢查。

2.3 SQL 注入攻擊分類

本節主要介紹目前已知的SQLIA 類型，由于無法窮舉每種攻擊類型的所有變化形式，表1 以用戶查詢為場景，為每種SQLIA 類型提供了代表性的示例語句。真實的網絡對抗中，攻擊者通常組合使用多種SQLIA 類型來完成對特定目標的攻擊。

1) 重言式。此類攻擊在條件語句中構造注入代碼，使SQL 的判定結果永遠為真，從而繞過條件語句中的驗證過程。

2) 批量查詢。此類攻擊利用查詢分隔符，注入額外的SQL，使原始語句完成操作后，繼而執行注入的批量語句。

3) 錯誤回顯。數據庫錯誤消息通常包含有用信息，此類攻擊向服務端注入語法錯誤、類型轉換錯誤或邏輯錯誤的SQL，利用錯誤回顯獲得數據庫關鍵信息。更進一步地，攻擊者將錯誤語句與查詢語句拼接，利用錯誤信息回顯查詢結果。

4) 聯合查詢。此類攻擊注入UNION 語句，改變返回的數據結果，從而繞過驗證過程或獲得敏感數據。

5) 存儲過程。此類攻擊屬于數據庫中設置的額外抽象層，可以由開發人員進行編程，因此同樣遭受SQLIA 威脅。攻擊者可以注入SHUTDOWN、DROPTABLE 等語句，造成數據破壞或拒絕服務。

6) 盲注。當應用程序隱藏了數據庫的不安全錯誤消息而不再產生錯誤回顯時，攻擊者既可以采用布爾盲注方法，利用應用程序的正確或錯誤響應，判斷注入語句的執行結果；也可以采用時間盲注方法，利用sleep、benchmark 等函數配合if-then 語句，通過響應時間判斷注入語句的執行結果，從而獲得有效信息。

7) 交替編碼。攻擊者使用交替編碼（例如十六進制、ASCII、Unicode）修改注入查詢語句，從而繞過輸入過濾器的檢測。

2.4 SQL 注入攻擊防御方法

根據防御發生的時機，Shar 等[4]將SQLIA 防御技術在廣義上分為防御性編碼、運行前分析和運行時防御3 類。

防御性編碼是在開發階段約束開發者的代碼編寫習慣，要求開發者在實現過程中更多地采用參數化查詢或存儲過程轉義所有用戶提交的參數、數據類型校驗、白名單篩選等防御性編碼方式。Mcclure 等[5]和Cook 等[6]創新地提出了SQL 開發模式，開發者通過提供的API，能夠自動實現具有數據類型校驗、輸入過濾和轉義的SQL，消除大量可能導致SQLIA 發生的編碼問題。此類防御技術盡管是有效的，但需要開發者使用新的編程方式，并且不會對已存在的應用程序提供安全防護，應用范圍狹窄。因此，防御性編碼類的SQLIA 防御技術未受到國內外學者的持續關注，研究成果有限。

運行前分析一般是通過對應用程序進行漏洞掃描、自動化測試等來發現SQLIA 漏洞，從而確保應用程序是安全可靠的，或者是在SQL 執行之前利用數據挖掘、黑白名單等技術手段對輸入檢查，來保證用戶輸入不含有SQLIA 代碼。在漏洞測試方面，Kiezun 等[7]開發了ARDILLA 工具，能夠根據應用程序自動生成SQLIA 語句，從而檢測應用程序是否存在SQLIA 漏洞；孫歆等[8]設計了基于缺陷注入的模糊測試方法，服務代理獲取用戶請求后轉發至模糊測試引擎，引擎采用DOM4J 解析XML偽碼配置，生成測試用例進行注入測試。針對輸入檢測，防御方法通常設計在防火墻層面[9-12]或CGI層面[13-15]。在防火墻層面的相關研究較豐富，Kar等[9]提出的SQLiGoT 采用令牌圖和支持向量機能有效地識別SQLIA 語句；韓宸望等[10]提出了基于SQL 語法樹的過濾方法，在用戶請求進入服務端前對比輸入語句的SQL 語法樹特征是否與合法特征一致，有效抵御SQLIA；趙宇飛等[11]基于長度、連接頻率和特征串對網絡流量進行分析，有效檢測SQLIA。在CGI 層面，張慧琳等[13]提出利用編碼值判斷SQL 中敏感字符的來源、轉義非可信敏感字符，基于 PHP 的 Zend 引擎實現了原型系統PHPGate，阻止SQLIA 發生。運行前分析類的SQLIA 防御技術，無論是通過生成測試用例進行自動化測試，還是構建合法或非法的語句特征進行輸入檢測，其核心思想是在掌握惡意輸入規則、語法漏洞集合或者建立有效白名單的前提下實施有效防護，當新型的攻擊出現時，此類技術保證的攻守平衡會被打破，繼而再努力解決新的問題，產生新的研究成果。

表1 SQLIA 類型及示例

運行時防御在運行前分析的基礎上，一方面在程序運行時進行監控，確保應用程序的行為始終在信任狀態，Halfond 等[16]提出了AMNESIA 工具，該工具運行在CGI 層，將靜態分析和運行時防御相結合，在靜態部分創建語句模型，然后在運行時監測這些動態生成的語句，一旦不符合設置的合法語句模型，該工具將阻止語句發送至數據庫；何成萬等[17]提出了一種基于AOP（aspect-oriented programming）和動態污點分析的檢測方法，通過污點標記方法區分可信與非可信數據源，在JDBC 中解析發現非可信語法。另一方面改變攻擊者對目標系統的認知，使注入代碼失效，Boyd 等[1]基于SQL的隨機化設計了SQLRand 系統，對SQL 關鍵字進行隨機化處理，例如，原始未隨機化的SQL 為SELECT account FROM users WHERE login=“AND pass=”，采用key 為“123”隨機化后的SQL 為SELECT123 account FROM123 users WHERE123 login=“AND123 pass=”，這樣可以使攻擊者不能預知應用程序的SQL 形式，SQLRand 系統架構如圖2所示。在CGI 與數據庫之間增加代理，用于解析語句和去隨機化處理，如果解析語句發現含有未隨機化的SQL 關鍵字，則進行異常處理，不予執行，從而實現SQLIA 的有效防御。

圖2 SQLRand 系統架構

SQLRand 系統在黑盒環境下能夠有效抵御SQLIA，但是存在被猜解的威脅，目前通過hashcat[18]工具暴力破解，在GPU 破解速度為9×109次/s 的條件下，每秒可以嘗試900 萬種組合，攻擊者在秒級時間內就可以完成對4 位標簽的猜解。而攻擊者在白盒環境下能夠準確掌握SQL 關鍵字的隨機化方法，隨即調整注入代碼，立刻實現有效的SQLIA。本文提出了一種基于多變體執行的SQLIA 運行時防御方法，多變體間采用互不相同的隨機化方法，即使在攻擊者掌握了隨機化方法的情況下，非法SQL也最多只能被某一變體解析成功，利用表決機制對多變體的響應結果或解析結果進行表決，實現SQLIA 的有效防御。

3 基于多變體執行的SQLIA 防御方法

3.1 多變體執行技術研究

程序冗余執行的技術思路最早應用在程序調試、錯誤容忍等保證程序可靠性的領域中，后來研究者在程序冗余執行的基礎上，將冗余執行的軟件進行多樣化設計，從而解決軟件的安全問題，因此在軟件安全領域將冗余執行的多樣化程序稱為多變體。多變體執行最早由Knowlton[19]提出，分別將2 個功能邏輯等價程序的實現代碼分成小片段，然后利用跳轉指令，在保證程序語義不變的前提下，對代碼片段進行重組。2 個程序并行執行時，由CPU 檢查程序的執行語義是否相等，從而可以預防控制轉換越界、錯誤使用野指針等安全問題。

Cox 等[20]提出了較完整的軟件多變體執行架構N-Variant，如圖3 所示。該架構通過內存地址空間隨機化和指令集隨機化技術生成冗余變體，在不關注攻擊方式的情況下，實現了對信息泄露攻擊的有效防御，N-Variant 奠定了多變體執行技術的基礎，并總結出該技術面臨著變體生成、監控方法等關鍵問題。

圖3 N-Variant 系統架構

有關多變體執行技術的眾多研究中，Berger 等[21]提出了DieHard，其架構如圖4 所示。該架構對init_heap、malloc、free 函數進行重新設計，采用新的init_heap 和malloc 函數結合，使用隨機化技術為多變體生成不同的堆對象布局。多變體以獨立的進程運行，通過管道從主進程接收輸入，然后在新的free 函數中將輸出寫入共享空間的緩沖區中，調用表決進程對所有變體的輸出進行比較，從而有效抵御內存錯誤，保證內存安全。該團隊又在Diehard的基礎上，擴展內存分配機制，設計了Dieharder[22]系統架構，使變體能夠在不連續的內存頁面上隨機分配，解決了Diehard 中單個堆塊溢出后覆蓋其他堆塊空間的問題。

圖4 DieHard 系統架構

Novark 等[23]在DieHard 的基礎上，擴展提出了 Exterminator，如圖 5 所示。該架構改善了Diehard 的表決算法，能夠表決發現內存錯誤位置，并在運行時生成補丁進行適應性的修補，并且Exterminator 首次為多變體執行架構增加了動態反饋機制。

圖5 Exterminator 系統架構

以N-Variant、Diehard、Dieharder、Exterminator等架構為代表進行分析，多變體執行是在多樣化技術的基礎上，利用冗余、動態機制，解決軟硬件同質化帶來的安全問題。多變體只要在受保護的攻擊面中存在更小的重疊范圍，便可以作為變體的“源”來構建冗余執行架構。

我國鄔江興院士[24]提出了由構造決定安全的擬態防御理論，研究了冗余、異構、動態特性解決內生安全問題的有效性，系統地構建了動態異構冗余架構，如圖6 所示。該架構由輸入代理、異構組件池、異構執行體集、調度器、表決器組成。動態異構冗余架構下同時運行多個功能等價、結構相異的執行體，由于網絡攻擊對于目標環境的依賴性，不同執行體對具有攻擊行為的輸入會產生不一致的輸出，通過表決就能夠發現執行體產生的異常結果。因此，動態異構冗余架構能夠在不依賴先驗知識的情況下，有效防御針對已知或未知漏洞后門發起的攻擊。

圖6 擬態防御動態異構冗余架構

擬態防御相較于多變體技術，具有完備的理論體系，已發行多版中英文著作[25]。對比兩者的技術思路可以發現，多變體技術屬于擬態防御作為內生安全構造技術解決軟件安全的范疇。

本文基于多變體執行技術，設計實現了SQLIA運行時防御原型系統SQLMVED。基于本節的研究內容，SQLMVED 的衍生路線如圖7 所示。

圖7 SQLMVED 的衍生路線

3.2 SQLMVED 系統設計

大部分多變體執行架構采用Leader-Follower或者Master-Slave 設計，針對不予表決的系統調用，監控器將其分派至Leader/Master 變體執行，再將結果同步至Follower/Slave 變體中，這種方法能夠有效降低假陽性，卻增加了安全威脅，Leader/Master變體一旦被控制，多變體執行架構的防御有效性將大打折扣。本文提出基于多變體執行的SQLMVED系統，為避免Leader-Follower/Master-Slave 模式的安全威脅，采用同步模式，系統架構如圖8 所示，系統由用戶請求代理、負責處理請求的多變體、數據庫代理，以及數據庫組成。

圖8 SQLMVED 系統架構

用戶請求代理是網絡服務的出入口[26]，當接收到用戶發起的請求時，其將請求復制3 份再轉發至多變體；當接收到多變體的響應時，進行表決，若存在多數一致的響應，則返回至用戶，否則拒絕響應。用戶請求代理基于Nginx 實現，利用ngx_http_upstream_module 模塊的負載功能和本文3.3 節設計的算法1，實現同一用戶請求向多變體的轉發，以及同一用戶響應的表決。

多變體由Web 服務端、CGI 以及部署的應用程序組成，其中應用程序采用隨機化方法對SQL 進行隨機化變化，且變體之間采用的標簽是不同的。

數據庫代理由獨立地服務于各個變體的SQL語法解析器SQLParse 和負責比較其解析結果的表決器組成。SQL 語法解析器基于sqlparse/ keywords.py 文件，使tokens.Keyword 與隨機化標簽保持一致，完成解析隨機化SQL 和去隨機化的過程。由于只改變tokens.Keyword 的表現形式，不改變SQL 解析的正常流程，因此本文提出的SQL 隨機化方法不會影響SQL 解析器的正常功能。例如，變體E1采用的標簽為“123”，其對應的語法解析器為SQLParse1；變體E2采用的標簽為“456”，其對應的語法解析器為SQLParse2。以SQLSELECT a FROM b WHERE c=‘?’;（其中?為占位符）為例，當攻擊者掌握了隨機化標簽，調整輸入為admin’or123 ‘1’=‘1 時，SQLParse1解析的結果，在未經去隨機化處理時的結構如圖9 所示。由于攻擊者注入的“or123”符合變體E1的變化方法，因此在變體E1中注入攻擊成功。

圖9 注入成功時的SQL 語法樹

SQLParse2解析的結果，在未經去隨機化處理時的結構如圖10 所示。在變體E2中，攻擊者注入的“or123”不符合其變化方法，因此注入攻擊失敗。同理，在變體E3中，注入攻擊也失敗。

變體E1、E2、E3中的SQL 經去隨機化處理后由數據庫執行，變體E2和變體E3的執行結果一致，且不同于注入成功的變體E1的執行結果。

3.3 SQL 表決方法設計

表決作為多變體執行架構中的關鍵技術，決定著多變體系統能否發現異常。在多變體系統中，表決點要么設置在變體執行前對輸入進行表決，要么設置在變體執行后對輸出進行表決。考慮到數據庫服務中數據讀、寫操作的不同影響，SQLMVED 系統針對數據的讀、寫操作采取的處理方式也不同。

圖10 注入失敗時的SQL 語法樹

讀操作。數據的讀操作不會引起數據的變化，讀操作的表決點設置在用戶請求代理處，用戶請求代理對變體返回用戶的輸出進行表決，充分利用協議代理功能，保證參與一次表決的變體返回結果的同源性。

寫操作。數據的寫操作必然使數據產生變化，若表決點繼續設置在用戶請求代理處，當其發現不一致時還需要對數據進行還原操作，增加了系統的復雜度。因此，寫操作的表決點設置在數據庫代理處，表決器對經過隨機化語法解析器去隨機化的語句進行表決，只有通過表決的寫操作語句才會由數據庫執行。

結合3.2 節的SQLMVED 系統設計，系統處理用戶請求的流程如圖11 所示。

1) 用戶請求代理表決算法

用戶請求代理將請求復制，轉發至冗余多變體執行并獲取響應結果，對HTTP 響應數據結構的響應體[27]進行表決，用戶請求代理表決算法描述如算法1 所示，若存在多數一致的響應，則將其中的響應結果返回至用戶；若無法通過表決，則拒絕響應，返回錯誤狀態碼。

圖11 SQLMVED 系統流程

算法1用戶請求代理表決算法

2) 寫操作表決方法

數據庫代理負責將冗余的寫操作合并成一次請求轉發至數據庫執行，因此無法以用戶請求代理的方式處理。為保證參與表決的SQL 是由同一請求復制分發而來的，算法1 中的步驟4)～步驟6)采用唯一性標識碼和時間戳在請求的頭部對請求進行標記。在此基礎上，通過修改應用程序源代碼，將算法1 中的標記信息傳遞至應用程序的SQL 中，使數據庫代理通過該標識能夠識別不同變體的同一用戶請求。如示例程序1 所示，應用程序獲取請求頭部中的標記信息，之后通過變量將其以注釋的形式拼接至SQL 中。

示例程序1修改登錄用戶密碼

數據庫代理的表決器配置高速緩存，變體的SQL臨時存儲在緩存中，并設置超時時間，當未達到超時時間，若緩存中存在一致的3 條語句，則消除緩存記錄，轉發至數據庫執行一次；當達到超時時間，則直接消除緩存記錄，不予轉發至數據庫執行，返回空數據至多變體。多變體在得到數據庫代理返回的數據后，返回響應結果至用戶請求代理，此時用戶請求代理表決器再次對結果進行表決，由于寫操作的請求已經在數據庫代理處完成表決，因此多變體的響應結果在用戶請求代理處表決是一致的。

3.4 安全性評估

根據SQLMVED 系統的設計方法，在對其進行安全性評估時，需要滿足以下幾個條件。1) 多變體E1、E2、E3同時處理請求，都具有獨立執行SQL的能力；2) 多變體E1、E2、E3在不遭受SQLIA 時，均能夠正確地處理SQL；3) 多變體E1、E2、E3任意之間不存在協同或協作的聯系，假設用戶請求代理和數據庫代理的設計實現中沒有漏洞或后門，攻擊者無法以此為跳板協同多變體；4) 假設表決算法的設計實現中也不存在漏洞或后門，由此做出以下形式化推論。

圖12 IEO 模型

Ei使用的隨機化方法集合Vi中隨機化方法個數記為card(Vi)，，且card(ω)≤card(Vi)，τ為集合ω中的元素。假設對于任意一個變體Ei∈E，采用隨機化方法集合Vi中每個方法元素的概率是相等的。根據式(1)可得出，SQLMVED 系統在某種隨機化設計下被注入成功的概率為

由此可見，SQLMVED 系統的防御能力取決于變體之間隨機化方法的差異性，由于key1、key2、key3之間互不相同，因此變體之間不存在任何相互一致的隨機化方法，也就是card(ω)=0，因此攻擊者無法有效實施SQLIA。

4 實驗與分析

為驗證本文設計的SQLMVED 系統的有效性，本節主要從防御有效性測試和性能測試對其進行實驗與分析。

4.1 防御有效性測試

防御有效性測試中，采用VMware Workstation虛擬化環境搭建實驗平臺，普通未防護的環境為LAMP（Linux、Apache、MySQL、PHP）架構，施加防護的環境為本文提出的SQLMVED 架構，用戶請求代理、變體（E1、E2、E3）、數據庫代理、數據庫均采用虛擬機（VM,virtual machine）進行部署，具體配置如表2 所示。

表2 防御有效性測試環境

選取bWAPP、DVWA、SQLI-LABS 這3 種靶機應用程序中未實施安全防護策略的部分，采用sqlmap 工具與人工構造注入結合的方式分別對部署在LAMP 和SQLMVED 架構環境中的以上3 種靶機應用程序進行測試，測試結果如表3 所示。LAMP 架構環境對3 種靶機應用程序的全部40 個注入點沒有任何防御能力，而SQLMVED 架構環境能夠有效防御針對其中36 個注入點的攻擊。其中bWAPP 2.2 中SQLite、Stored SQLite、Blind SQLite 注入點無法防御是因為SQLMVED 基于MySQL 數據庫設計，暫且無法應用于其他類型數據庫；Drupal 屬于應用框架，目前SQLMVED 還未適用所有框架，因此無法有效防御此注入點。實驗表明，SQLMVED 架構能夠有效防御針對以上3 種靶機應用程序的大部分SQLIA。

表3 防御有效性測試環境

4.2 性能測試

SQLMVED 架構環境在變體E1、E2、E3中部署具有數據讀寫操作的測試頁面，讀寫測試語句如表4 所示，在LAMP 架構環境中也部署同樣的測試頁面。

表4 讀寫測試語句

為減小虛擬化的實驗環境對測試結果的影響，以及主要體現讀寫過程的性能損耗，測試方法采用在連續的100 次訪問中分別記錄測試頁面的響應時間。

讀數據測試結果匯總如圖13 和圖14 所示，SQLMVED 的平均響應時間為47.48 ms，LAMP 的平均響應時間為23.88 ms。SQLMVED 架構相較于LAMP 架構，平均響應時間增加約一倍，大部分響應時間控制在60 ms 以內，性能損耗可以接受。

圖13 SQLMVED 讀數據測試結果

寫數據測試結果匯總如圖15 和圖16 所示，SQLMVED 平均響應時間為4 870.63 ms，LAMP 的平均響應時間為20.6 ms。SQLMVED 的寫操作產生了較嚴重的性能損耗，這是由于SQLMVED 中寫數據的過程比讀數據更復雜。但是，通過防御有效性測試可以發現，SQLIA 通常發生在讀數據過程中，因此，若為減小性能損耗，即使只將讀數據采用多變體執行的方法設計，也能夠防御大部分SQLIA。

圖14 LAMP 讀數據測試結果

圖15 SQLMVED 寫數據測試結果

圖16 LAMP 寫數據測試結果

此外，SQLMVED 原型系統在設計實現中可能存在缺陷，包括防御有效性測試中發現的不足，SQLMVED 的局限性將在第5 節進行分析總結。

5 局限性分析

SQLMVED 原型系統的局限性主要體現在以下2 個方面。

1) 首先，SQLMVED 的多變體中需要對應用程序的SQL 進行隨機化變化，而SQL 具有跨代碼段、跨函數、跨文件等多種拼接方式，如何準確地識別應用程序中的SQL 并進行隨機化變化，可能需要對程序分析技術進行深入研究。其次，本文使用的隨機化方法不支持Hibernate、Mybatis 等開發框架，因此SQLMVED 的適用范圍局限于使用原生SQL開發的應用程序。

應用程序以網站為例，根據W3Techs 對Alexa排名前100 萬網站的類型統計結果來看，使用原生SQL 開發為主的PHP 網站數量占比達到了79%，說明SQLMVED 雖然不能適用于所有的應用程序，但也具備可觀的應用前景。

2) 本文在數據庫代理處采用高速緩存解決數據庫讀操作的表決問題。但在高并發數據流的背景下，若把所有請求語句都保存在緩存中進行表決處理，將會大大增加表決過程對存儲空間的消耗，本節基于Bloom filter[28]提出SQLMVED 的改進思路。

Bloom filter 是一種存儲空間高效的散列結構，被廣泛應用在P2P 網絡寫作、網絡緩存以及網絡測量等領域。Bloom filter 可以對待表決的語句集合采用位串表示，利用數據流冗余消除方式對語句進行表決，當判定某請求語句是冗余重復的數據，就認為該語句為3 冗余多變體中的多數一致語句，由數據庫代理轉發至數據庫執行，否則丟棄該語句。數據流冗余消除算法設計的關鍵問題是需要實時刪除達到最大計數值的過期元素，主要算法可以分為3 類，分別是基準窗口模式、滑動窗口模式、跳躍窗口模式，需要采用何種方式還需要進一步研究。

6 結束語

本文在研究了現有多變體執行技術和SQL 注入防御方法的基礎上，結合兩者的技術思路，提出了一種基于多變體執行的SQL 注入運行時防御方法。首先為應用程序在運行時構建多變體執行架構；其次通過隨機化方法對應用程序的SQL 進行變化，保證變體間隨機化方法的異構性；最后在用戶請求代理和數據庫代理處通過表決分別發現異常的數據讀操作結果和數據寫請求，使攻擊者即使在掌握了變體隨機化方法的情況下也無法實施有效的 SQLIA。基于該方法設計實現了原型系統SQLMVED，并通過形式化推論證明了SQLMVED的防御能力。性能測試結果顯示，由于該方法引入了請求的復制分發、語句解析、去隨機化、表決等處理過程，會降低程序性能，因此如何減小對性能的影響將是未來工作的重點之一。防御有效性測試雖然采用靶機應用程序和自動化注入工具構造的都是已知漏洞攻擊，但是該方法也可以有效防御利用未知漏洞的SQLIA，只要攻擊者構造的輸入數據中具有SQL 指令，就無法同時在多變體中正確執行，進而無法通過表決，防御利用未知漏洞的SQLIA。