SQL注入攻擊與防御研究

摘要：SQL注入攻擊是Web安全鄰域中最為常見且最具破壞性的攻擊之一。深入了解SQL注入攻擊的技術原理及其相應的防御措施對于增強Web應用的安全性尤為重要。基于此，文章闡述了SQL注入的概念及常用的注入方法并結合SQLi-Labs平臺上的實踐案例詳細展示了攻擊者利用SQL注入漏洞竊取敏感信息的過程，提出了一系列針對SQL注入攻擊的有效防御策略。文章為相關人員提供了理論借鑒和實踐參考，對于增強Web安全領域的防護能力具有重要意義。

關鍵詞：SQL注入；攻擊；防御；安全

中圖分類號：TP393.08 "文獻標志碼：A

0 引言

全球性安全組織（Open Web Application Security Project，OWASP）定期發布其著名的“OWASP Top 10”［1］清單，該清單列出了Web應用程序中最常見且最危險的十大漏洞。在“OWASP Top 10”中，結構化查詢語言（Structured Query Language，SQL）注入漏洞持續位居前列，這一事實凸顯了SQL注入攻擊的普遍性和高風險性，這已成為不容忽視的安全問題。因此，深入研究并熟練掌握SQL注入攻擊的機制及其防御措施，對于確保Web應用程序的安全至關重要。

1 SQL注入攻擊簡介

SQL注入攻擊［2］是一種由Web應用程序對用戶輸入數據處理不當的安全漏洞而引發的攻擊。攻擊者通過嵌入惡意SQL代碼，操控應用程序與數據庫之間的交互，實現非法操作。以下是一個簡化的SQL注入漏洞示例。

在某登錄界面，用戶須要輸入用戶名和密碼完成身份驗證。后臺認證程序中的SQL語句如下：String sql=\" select * from user_table where username='{$

_POST［username］}' and password='{$

_POST［password］}' \"，其中，username、password是前端傳入后端的參數。運行邏輯如下：用戶在前端界面輸入用戶名和密碼，通過POST請求將這些參數提交到服務器端進行驗證；服務器端接收到的username、password參數會被直接拼接到SQL語句中，在數據庫中執行查詢操作；若找到了匹配的條目，則身份驗證成功，否則，驗證失敗。

在正常情況下，用戶輸入用戶名admin和密碼123456，上述SQL語句將執行以下查詢：select * from user_table where username='admin' and password ='123456'。但如果攻擊者輸入用戶名為' or 1=1 #，密碼為abc，上述SQL語句將執行以下查詢：select * from user_table where username=' 'or 1=1 # ' and password='abc'。這里“#”用于注釋掉后續語句，使其后的密碼驗證失效；鑒于1=1恒為真，故而username=' 'or 1=1這一條件亦為真。綜上分析，無論密碼是否匹配，查詢均能獲取到匹配條目，攻擊者因此可以繞過身份驗證進入系統。更嚴重的是，攻擊者可能構造更具破壞性的SQL語句，比如：select * from user_table where username=' ' ; drop table user_table ; # ' and password=' ' ，這將導致災難性的后果。

產生SQL注入的主要原因在于，在數據交互過程中，后端在接收到從前端傳入的數據時，未能對數據的合法性進行嚴格過濾或判斷，導致惡意用戶將前端傳入的“數據”拼接進應用程序事前定義的SQL語句中。在管理員不知情的情況下，攻擊者可以實現非授權訪問、修改、刪除或泄露數據庫中敏感信息。

2 常用的SQL注入方法

2.1 依據傳入的參數類型分類

2.1.1 數字型注入

當輸入的參數為整型時，若存在注入漏洞，則為數字型注入［3］。例如，URL結構為http：//xxx.com/users.php？id=10的場景，其注入點id的類型為數字，且兩端不包含引號。這類SQL語句的原型通常是select * from user_table where id=x。在這種類型的注入中，可以使用經典的and 1=1，and 1=2來測試是否存在注入漏洞。

2.1.2 字符型注入

當輸入的參數為字符串時，若存在注入漏洞，則為字符型注入。字符型和數字型的最大區別在于，數字型不需要單引號來閉合，而字符串一般須要通過單引號來閉合［3］。例如，URL結構為http：//xxx.com/users.php？username=admin的場景，其中username為字符串參數，兩端包含引號。這類SQL語句的原型通常是select * from user_table where username='x'。在這種類型的注入中，可以使用經典的and '1'= '1'，and '1'='2'來測試是否存在注入漏洞。

2.2 依據HTTP請求的類型以及字段分類

2.2.1 GET注入

當使用GET方法提交數據時，URL中的參數可能被用作注入點。

2.2.2 POST注入

當使用POST方法提交數據時，請求體中的數據部分可能被用作注入點。

2.2.3 HTTP頭注入

HTTP請求頭部的特定字段，如User-Agent、Referer、Cookie以及X-Forwarded-For等，亦可能被用作注入點。

2.3 依據SQL語句執行結果分類

2.3.1 聯合查詢注入

聯合查詢注入，亦被稱作union聯合注入，是指攻擊者在SQL查詢中使用union關鍵字來提取信息。在進行union聯合注入之前，首先須要確定是數字型注入還是字符型注入。隨后，可以通過使用order by子句來猜測列數。以字符型注入為例，倘若id=1' order by 1#、id=1' order by 2 #與id=1' order by 3 #皆返回正常界面，但id=1' order by 4 #卻返回不同的界面，這表明第4列數據不存在，由此可斷定列數為3。確認列數后，利用union select語句識別可用于信息回顯的列，例如：id=-1' union select 1，2，3#，這將嘗試向各列插入數值，以判斷哪些列可以用于顯示信息。一旦辨明可用作信息回顯的列，即可在這些列中植入欲爆破的細節，例如id=-1' union select 1，version（），database（） #，這將試圖揭示數據庫的版本和名稱。

2.3.2 報錯注入

報錯注入技術依賴于數據庫的特殊函數和機制，通過刻意注入錯誤的請求來誘使數據庫報錯，而這些報錯信息中通常隱含著攻擊者渴望獲取的數據庫名、表名以及字段名等信息。以extractvalue（）函數為例，在確認存在數據庫報錯回顯的情況下，可以構造如下的查詢語句來進行注入：id=1' and extractvalue（1，concat（0x7e，database（），0x7e），3） #，此舉旨在嘗試爆破當前使用的數據庫名稱。

2.3.3 布爾注入

布爾注入通過反復向程序發送包含true或1判斷的SQL語句，根據應用程序返回的頁面情況來推斷出數據庫的相關信息。一般情況下，當發送的判斷語句結果為true時，頁面顯示正常；當判斷語句結果為1時，頁面顯示異常或不同。例如，可以使用以下語句逐一嘗試不同的n值來推測數據庫名稱的長度：id=1' and length（database（））=n#，當n依次取1、2、3、4時頁面顯示異常，而當n=5時頁面顯示正常，由此可以推斷數據庫名稱的長度為5。

2.3.4 時間注入

時間注入，亦被稱作延時注入，是一種運用if語句構造判斷條件，結合sleep函數刻意營造時間延遲，根據應用程序的響應時長來推測數據庫相關信息的技術。例如，可以構造語句id=1' and if（ascii（substr（database（），1，1））gt;n，sleep（6），0） #，來判斷數據庫名稱首字母的ASCII碼是否大于某個特定值n。在此語句框架中，若數據庫名稱首字母的ASCII碼大于n，則頁面響應會延遲6 s；否則，頁面會立即加載。通過逐一嘗試不同的n值，同時檢測頁面的響應時長，便可鎖定數據庫名稱首字母的ASCII碼。依次類推，即可推敲出其余字母，最終獲知整個數據庫名稱。

2.3.5 堆疊注入

堆疊注入是指將多個SQL語句疊加在一起執行的技術，每條語句末尾使用“；”表示語句的結束。在“；”結束一條SQL語句之后，可以繼續構造下一條語句，從而使多條語句順利執行。

3 SQL注入攻擊實踐案例

3.1 判斷是否存在SQL注入漏洞

根據頁面的提示信息，攻擊者向URL地址欄輸入參數id，并觀察返回信息的變化。攻擊者在URL中將參數id設置為1，觀察到頁面正常回顯了id值為1的用戶信息，如圖1所示。攻擊者嘗試注入id=1'，觀察到頁面出現了報錯信息，如圖2所示。此現象表明該頁面很可能存在SQL注入漏洞，且根據報錯信息，能夠推測出數據庫類型可能是MySQL。

3.2 判斷注入點

攻擊者輸入id=1' and '1'='1' #，并在URL中將#進行URL編碼為%23，構建了如下測試URL：http：//127.0.0.1/sqli-labs/Less-1/？id=1' and '1'='1' %23，經觀察發現頁面正常回顯。攻擊者輸入id=1' and '1'='2' #并以相同方式將#編碼為%23，經觀察發現頁面部分數據顯示不正常。基于以上測試結果，攻擊者可以確定此處為字符型注入。

3.3 判斷字段數

攻擊者使用order by子句來猜測列數，逐一嘗試不同的n值，輸入id=1' order by n #（此處n取值依次為1，2，3，…）并觀察頁面的響應。測試結果顯示，當n取值分別為1、2、3時，頁面正常顯示。當n=4時，頁面報錯，如圖3所示。根據上述測試結果，可以推測出查詢字段數為3。

3.4 判斷回顯位置

為了確定哪些字段可以在頁面上顯示信息，實驗使用聯合查詢來進行測試。輸入id=-1' union select 1，2，3 #并觀察頁面的響應。觀察圖4中的頁面回顯信息可知：2對應的是“Your Login name”，3對應的是“Your Password”。這意味著在這2個特定位置上，查詢結果得以可視化呈現。

3.5 爆破數據庫名

在3.4節中，攻擊者已成功確定了數據回顯的確切位置，此時可進一步利用這些已知位置來獲取更詳細的數據。例如，在標記為3的位置，攻擊者可以使用database（）函數來探查當前使用的數據庫名稱。當輸入id=-1' union select 1，2，database（）#時，可以在頁面上看到當前數據庫名稱為“security”，如圖5所示。

若要深入探索數據庫的架構細節，則可充分利用MySQL內嵌的系統數據庫information_schema，該數據庫存儲著關于整個MySQL實例的各種元數據信息，涵蓋數據庫、表、列、索引、約束、存儲過程、函數、觸發器等信息。例如，若要查詢所有數據庫名稱，可以利用information_schema數據庫中的schemata表，通過構造聯合查詢id=-1' union select 1，2，group_concat（schema_name） from information_schema.schemata #，使所有數據庫名稱在標記為3的回顯位置集中展現，各名稱間以逗號分隔。根據測試所得結果，服務器上包括“information_schema”和“security”數據庫。

3.6 爆破數據庫表名

若要查詢特定數據庫中所有的表名，則可利用information_schema數據庫中的tables表。例如，當欲獲取“security”數據庫中的所有表名時，可以輸入id=-1' union select 1，2，group_concat（table_name） from information_schema.tables where table_schema='security' #，根據測試結果可知“security”數據庫包含了“emails”“referers”“uagents”及“users”等表。

3.7 爆破字段名

若要查詢特定數據庫中某個表的所有字段名，則可利用information_schema數據庫的columns表。例如，當欲獲取“security”數據庫中的“users”表的所有字段名時，可以輸入id=-1' union select 1，2，group_concat（column_name） from information_schema.columns where table_schema='security' and table_name='users' #，根據測試結果可知“users”表涵蓋了“id”、“username”、“password”字段。

3.8 爆破用戶信息

當查詢“security”數據庫中“users”表的內容時，輸入id=-1' union select 1，2，group_concat（char（32，58，32），id，username，password） from users #。當欲查詢“users”表中特定id（例如id為2）的用戶信息時，輸入id=-1' union select 1， username ， password from users where id=2 #，可得id為2的用戶的用戶名和密碼，如圖6所示。

4 SQL注入的防御策略

4.1 使用預編譯語句執行參數化查詢

預編譯語句基本思想是將SQL語句和用戶輸入的數據分開處理，其工作原理是將SQL語句的結構預先定義好，其中變量部分用占位符表示。當須要執行這個SQL語句時，用戶輸入的數據會通過參數化的方式傳遞給SQL語句。數據庫服務器不會將參數的內容視為SQL指令的一部分來處理，而是在數據庫完成對SQL指令的編譯后才套用參數運行。這樣一來即使參數中含有惡意的指令，也不會被數據庫所運行［4］。

4.2 驗證和過濾輸入

在后端編程中，系統應嚴格驗證和過濾用戶輸入，以確保所接收的數據類型與預設的標準保持一致。通常系統可以通過運用白名單、正則表達式匹配或內置函數的手段來驗證和過濾用戶輸入。

4.3 轉義特殊字符

用戶輸入在經過驗證和過濾后、嵌入到SQL語句之前，對其中的特殊字符（'、\"、%、amp;、*、;等）進行轉義處理或編碼轉換。基本上所有的后端語言都有對字符串進行轉義處理的方法，比如lodash的lodash._escapehtmlchar庫［5］。

4.4 最小權限原則

安全管理人員應嚴格限制數據庫賬號權限，應用程序用來訪問數據庫的賬號須遵循最小權限原則，對不同權限的用戶只賦予其執行必要操作所需的最低權限。通過這種方式，即使發生了SQL注入攻擊，攻擊者的破壞范圍也會受到限制。

4.5 使用對象關系映射

對象關系映射（Object Relational Mapping，ORM）是一種在編程中用于將對象模型表示的數據與關系數據庫中的數據進行映射的技術。通過ORM，開發者可以使用面向對象的編程方式來操作數據庫，而不必手動編寫煩瑣的SQL語句。

4.6 定期更新和維護

安全管理人員應及時應用數據庫和應用程序廠商提供的安全更新和補丁，以確保所有已知的漏洞都已被修補。

4.7 使用防火墻和入侵檢測系統

安全管理人員應使用Web應用程序防火墻和入侵檢測系統來監測、過濾Web應用程序的請求，識別并攔截惡意流量，從而有效阻止或減輕SQL注入攻擊的發生。

4.8 安全測試和監控審計

安全管理人員應定期進行滲透測試和漏洞掃描，以便迅速識別并修復漏洞；同時，實施持續的監控和日志審計，以便及時發現和響應可疑的數據庫操作。

5 結語

SQL注入攻擊長期以來一直是Web安全領域的一個重要挑戰。文章分析了SQL注入的原理和常用的注入方法；通過實際的SQL注入案例，展示了如何非法獲取數據庫中存儲的用戶名、密碼等敏感信息。為了有效防范SQL注入攻擊，文章提供了多項針對性的防御策略。該研究旨在幫助開發人員和安全管理人員深化對SQL注入漏洞的認識，進而有效降低遭受此類攻擊的風險，全面提升Web系統的整體防御能力。

參考文獻

［1］OWASP. OWASPtop10［EB/OL］. （2021-09-13）［2022- 05-20］. https：//owasp.org/Top10/.

［2］王安琪，楊蓓，張建輝，等.SQL注入攻擊檢測與防御技術研究綜述［J］.信息安全研究，2023（5）：412-422.

［3］王婭.基于PHP的Web應用中的SQL注入及防御措施［J］.信息記錄材料，2019（6）：115-117.

［4］姜穎，高敬惠.SQL注入攻擊及其防御策略分析［J］.電腦知識與技術，2013（5）：1000-1001，1013.

［5］柯一川.Web網絡安全概述及幾種常見漏洞攻擊簡介［J］.網絡安全和信息化，2023（6）：126-128.

（編輯 王雪芬編輯）

Research on SQL injection attack and defense

MIAO" Chunling

（Nanjing Polytechnic Institute， Nanjing 210044， China）

Abstract： SQL injection attack is one of the most common and destructive attacks in the field of Web security. A deep understanding of the technical principles and corresponding defensive measures of SQL injection attack is particularly important for enhancing the security of Web applications. Based on this， the article explains the concept of SQL injection and common SQL injection methods. Combining with the practical case on the SQLi-Labs platform， the article presents the entire process of the attacker using SQL injection vulnerabilities to steal sensitive information in detail. A series of effective defense strategies against SQL injection attack are proposed. The article provides the theoretical and practical references for relevant personnel and has important significance for enhancing the protection capabilities in the field of Web security.

Key words： SQL injection; attack; defense; security