SQL注入实战：从靶场到真实漏洞的攻防演练

1. 从靶场到实战：为什么我们还在学SQL注入？

如果你在安全圈待过一阵子，或者刚入门网络安全，大概率听过“SQL注入”这个词。它太老了，老到很多新人会觉得：“这都202X年了，数据库都有预编译了，框架都内置防护了，还有必要学这个吗？” 我见过不少新手，一上来就想搞什么零日漏洞、高级持续性威胁，对SQL注入这种“古典”漏洞嗤之以鼻。但现实是，就在上个月，我帮一个朋友的公司做应急响应，他们一个刚上线的、用了最新Spring Boot和MyBatis-Plus的项目，依然被奇安信的安全扫描报出了SQL注入漏洞。原因？开发在动态排序的字段上，图省事直接用了${orderBy}。你看，漏洞不在技术的新旧，而在人的意识。

这就是为什么像iwebsec这样的SQL注入靶场至今仍有巨大价值。它不是一个简单的漏洞列表，而是一个完整的、从原理到手工利用再到工具辅助的思维训练场。通过它，你学到的不是几个' or 1=1--的Payload，而是一套面对一个黑盒系统时，如何像侦探一样，通过有限的输入点，一步步推理出后端数据库的结构、逻辑，并最终拿到你想要的数据（甚至是系统权限）的完整方法论。这套方法论，在CTF比赛、渗透测试、甚至代码审计中，都是相通的。今天，我就结合iwebsec靶场（以及其他像DVWA、Pikachu这类经典靶场）的闯关过程，为你拆解SQL注入的完整知识体系，从最基础的错误回显注入，到需要耐心和技巧的盲注，再到真实环境中那些“狡猾”的二次注入和宽字节注入。我的目标不是让你成为“脚本小子”，而是让你真正理解每一个Payload背后的原理，知道在什么时候、用什么方法，以及为什么要这么做。

2. 环境搭建与靶场初探：不只是运行一个Docker

在开始任何实战之前，一个稳定、隔离的测试环境是必须的。很多人觉得搭环境就是docker pull加docker run，但细节决定成败，尤其是当你需要调试或者复现一些复杂场景时。

2.1 靶场选择与部署考量

iwebsec是一个集成了多种漏洞的综合性Web靶场，它的SQL注入模块设计得比较系统。除了iwebsec，DVWA（Damn Vulnerable Web Application）因其极简的界面和可控的漏洞等级，是绝对的经典入门选择；Pikachu则更偏向于中文环境和漏洞场景化，比如有“搜索型注入”、“XX型注入”等分类，对理解漏洞成因很有帮助；而CTFHub的技能树则提供了更偏向CTF竞赛的闯关式练习。

我的建议是：以其中一个为主，其他为辅进行交叉验证。例如，你可以用iwebsec或DVWA作为主线任务，逐个关卡攻克。当你在某个关卡（比如盲注）遇到瓶颈时，去Pikachu的对应模块再做一遍，不同的实现方式可能会给你新的启发。部署上，强烈推荐使用Docker，这能避免污染你的主机环境。

# 以DVWA为例，一个更稳妥的部署命令： docker run -d --name dvwa -p 8080:80 -e MYSQL_ROOT_PASSWORD=p@ssw0rd vulnerables/web-dvwa

注意：别直接用latest标签，最好指定一个稳定版本号，比如vulnerables/web-dvwa:1.10。因为有些最新镜像的默认配置可能会有变动，导致你无法复现教程里的步骤。

部署完成后，访问http://localhost:8080，按照提示完成数据库初始化。这里第一个“坑”就来了：DVWA的默认登录账号是admin/password。但很多人输完发现登录失败。你需要先点击页面上的Create / Reset Database按钮，这个操作会初始化数据库并创建这个默认账户。这个步骤体现了安全测试中的一个重要原则：环境的状态是可预期且可重置的。

2.2 必要的工具准备：浏览器与代理

工欲善其事，必先利其器。除了靶场，你还需要两样核心工具：

  1. 浏览器：Chrome或Firefox。重点不是浏览器本身，而是其开发者工具（F12）。你需要熟练使用“网络”（Network）标签页查看HTTP请求/响应，使用“控制台”（Console）执行一些简单的JavaScript调试，以及“元素”（Elements）查看页面结构。
  2. 代理工具：Burp Suite Community版（以下简称Burp）是绝对的主力。它就像一个在你浏览器和靶场服务器之间的“中间人”，可以拦截、查看、修改所有过往的HTTP/HTTPS流量。这是手工测试SQL注入的灵魂工具。

配置Burp需要一点步骤：安装后，启动Burp，在Proxy -> Options中确保代理监听在127.0.0.1:8080（默认）。然后在浏览器中配置代理指向这个地址。最后，访问http://burp下载并安装Burp的CA证书到你的系统或浏览器受信任的根证书颁发机构。只有这样，Burp才能解密HTTPS流量（虽然靶场多是HTTP，但好习惯要养成）。

为什么强调Burp？因为图形化的界面让你能清晰地看到原始请求参数，方便你修改和重放（Repeater功能）。很多基于时间的盲注，你需要精确控制Payload的发送和计算响应时间，没有比Burp Repeater更顺手的工具了。

3. 核心原理深度拆解：SQL注入究竟是如何发生的？

在动手之前，我们必须把原理吃透。很多教程只讲“怎么注”，却不讲“为什么能注”，导致换一个场景就不会了。

3.1 漏洞的本质：数据与代码的混淆

SQL注入的根本原因，在于程序将用户输入的数据，未经充分处理就直接拼接到了SQL查询语句中，从而使用户输入被数据库引擎误解为代码的一部分并执行。

想象一个简单的登录场景，后端Java代码可能是这样的：

String sql = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'";

如果用户输入的username是admin，password是123456，那么拼接后的SQL是：

SELECT * FROM users WHERE username = 'admin' AND password = '123456'

这没问题。但如果攻击者输入的username是admin'--（注意最后的单引号和两个减号，在SQL中--是注释符），那么拼接后的SQL就变成了：

SELECT * FROM users WHERE username = 'admin'--' AND password = '...'

--之后的所有内容都被注释掉了！这意味着密码验证条件完全失效，只要数据库里存在用户名为admin的记录，这条查询就会成功返回该用户信息，攻击者就能以管理员身份登录。

这就是最经典的“永真条件”绕过。' or '1'='1也是同样的道理，它构造了一个永远为真的条件（'1'='1'），使整个WHERE子句恒成立。

3.2 参数化查询与预编译：为什么它是终极解决方案？

要防止SQL注入，核心原则就是：让“数据”永远是“数据”，绝不成为“代码”。实现这一点的最佳实践就是参数化查询（Prepared Statements）。

还是上面的登录例子，使用参数化查询的Java（JDBC）代码是这样的：

String sql = "SELECT * FROM users WHERE username = ? AND password = ?"; PreparedStatement stmt = connection.prepareStatement(sql); stmt.setString(1, username); stmt.setString(2, password); ResultSet rs = stmt.executeQuery();

这里，?是占位符。在prepareStatement阶段，数据库就已经知道了SQL的结构：“这是一个SELECT语句，在WHERE子句中有两个字符串类型的条件”。之后通过setString方法传入的username和password，无论里面包含什么奇怪的字符（'、--、or 1=1），都会被严格地当作一个完整的字符串值来处理。数据库引擎不会再去解析这些值中的SQL关键字。

所以，当你听说一个用了MyBatis的项目还有SQL注入时，问题往往出在动态SQL的${}用法上。MyBatis中，#{}是参数占位符（会预编译），而${}是字符串替换（直接拼接）。例如：

ORDER BY ${orderBy}

如果orderBy这个参数用户可控，攻击者传入id; DROP TABLE users--，那么拼接后的SQL就是ORDER BY id; DROP TABLE users--，后果不堪设想。正确的做法是，如果排序字段必须动态，应该在服务端用一个白名单来校验orderBy的值是否合法（如只允许id,name,create_time等），而不是直接信任前端传参。

4. 手工注入实战：像侦探一样推理数据库结构

理解了原理，我们进入实战。我将以iwebsec/DVWA的“SQL Injection”关卡（安全级别设为Low，即无任何防护）为例，演示一次完整的手工联合查询注入过程。这个过程是理解所有自动化工具的基础。

4.1 第一步：探测注入点与数据库类型

首先，在输入框随便输入一个数字，比如1，提交。页面返回了用户ID为1的信息（假设是admin）。然后，我们输入一个单引号'提交。

这是最关键的一步。如果页面返回了数据库错误信息（比如“You have an error in your SQL syntax...”），那么恭喜，这里存在SQL注入漏洞，并且是错误回显注入。错误信息能告诉我们很多：它可能直接暴露数据库类型（MySQL, SQL Server, PostgreSQL等）。例如，MySQL的错误信息通常包含“MySQL server version”，而SQL Server可能包含“Microsoft SQL Server”。

如果输入'后页面空白、报500错误或者跳转到错误页，但没有具体信息，则可能是盲注。我们暂时按有回显的情况继续。

假设我们看到了MySQL的错误。接下来，我们构造一个“永真”和“永假”条件来确认注入点确实会影响查询逻辑：

  • 输入1' and '1'='1-> 页面应正常返回ID为1的用户信息（因为条件永真）。
  • 输入1' and '1'='2-> 页面应返回空或错误（因为条件永假）。

如果行为符合预期，说明我们注入的SQL片段确实被数据库执行了。

4.2 第二步：判断字段数与确定回显位

现在我们知道可以注入，下一步是搞清楚这个SELECT语句到底查询了多少个字段（列）。这要用到ORDER BY子句。ORDER BY后面可以接字段名，也可以接数字，表示按第几列排序。

我们在注入点输入：1' order by 1--。注意，--后面有一个空格，在MySQL中这是单行注释的标准写法。提交后，页面正常排序（可能没变化）。

然后尝试1' order by 2--，1' order by 3--... 以此类推，直到页面报错。比如，当输入1' order by 4--时页面出错，而order by 3正常，那么就说明原始查询语句一共查询了3个字段。

知道字段数后，我们需要确定这些字段中，哪几个的位置内容会显示在网页上。这要用到UNION SELECT联合查询。联合查询要求前后两个SELECT的字段数必须一致。所以我们构造：1' union select 1,2,3--

提交后，页面可能原本显示ID为1的用户信息的地方，变成了显示数字2和3（或者只有其中几个）。这说明，在这个页面的显示位置，对应着原始查询结果集的第2和第3个字段。这两个位置，就是我们后续注入查询结果、并让其显示在页面上的“回显位”。

4.3 第三步：获取数据库信息

现在，我们可以把回显位（比如2和3）替换成我们想查询的数据库函数。

  • 查询当前数据库名：1' union select 1, database(), 3--。database()函数在MySQL中返回当前使用的数据库名称。提交后，在回显位2的位置，你应该能看到数据库名，比如dvwa。
  • 查询数据库版本和用户：1' union select 1, version(), user()--。version()返回MySQL版本，user()返回当前数据库用户。这能帮你判断数据库权限。

4.4 第四步：爆破表名、列名与最终数据

MySQL在5.0版本以上，有一个名为information_schema的系统数据库，它就像数据库的“户口本”，记录了所有其他数据库、表、列的信息。这是我们进行下一步的钥匙。

  • 查询所有表名：1' union select 1,group_concat(table_name),3 from information_schema.tables where table_schema=database()--

    • information_schema.tables存储所有表的信息。
    • table_schema=database()条件限制只查询当前数据库的表。
    • group_concat(table_name)将查询到的所有表名合并成一个字符串，用逗号分隔，方便一次性显示。你可能会看到users, guestbook等表名。我们显然对users表更感兴趣。

  • 查询users表的所有列名：1' union select 1,group_concat(column_name),3 from information_schema.columns where table_schema=database() and table_name='users'--

    • information_schema.columns存储所有列的信息。
    • 条件限定了当前数据库下的users表。
    • 执行后，你可能会得到user_id, first_name, last_name, user, password, avatar等列名。其中user和password很可能就是我们要找的账号密码列。

  • 最终拖库：1' union select 1,group_concat(user, ':', password),3 from users--

    • 直接从users表中，将用户名和密码用冒号连接后查询出来。
    • 提交后，你就能在页面上看到类似admin:5f4dcc3b5aa765d61d8327deb882cf99这样的结果。这里的密码是MD5哈希值，需要去在线网站或用工具（如John the Ripper）进行破解。

至此，一次完整的手工联合查询注入就完成了。这个过程看似繁琐，但它训练的是你面对一个未知系统时的结构化思维：探测 -> 判断 -> 获取信息 -> 逐步深入。自动化工具（如sqlmap）无非是把这些步骤用程序实现了而已。

5. 盲注：在没有回显的黑暗中摸索

现实中的漏洞往往没有友好的错误回显。页面对于正确的输入和错误的输入，可能都只返回“查询成功”或“查询失败”的通用提示，甚至HTTP状态码都是200。这就是盲注。盲注又分为基于布尔（Boolean）的和基于时间（Time）的两种。

5.1 布尔盲注：像玩“猜数字”游戏

布尔盲注的核心思想是：通过构造SQL语句，让页面的某种可观察特征（如是否存在某个关键词、页面长度是否变化）随着我们注入的SQL条件真假而变化。

例如，一个搜索功能，无论输入什么，页面都只显示“找到结果”或“未找到结果”。我们可以这样探测：

  • 输入1' and 1=1---> 页面显示“找到结果”（条件真）。
  • 输入1' and 1=2---> 页面显示“未找到结果”（条件假）。

这就建立了一个“真/假”信号通道。接下来，我们就可以用这个通道来“问”数据库问题。比如，猜解当前数据库名的第一个字母：

  • 1' and ascii(substr(database(),1,1))>100---> 如果返回“找到结果”，说明ASCII码大于100。
  • 1' and ascii(substr(database(),1,1))>150---> 如果返回“未找到结果”，说明ASCII码小于等于150。

通过这种二分法（折半查找），我们可以一步步确定第一个字母的ASCII码，进而推出字母。substr(database(),2,1)用于猜第二个字母，以此类推。猜完数据库名，再用同样的方法去猜表名、列名。整个过程极其耗时，必须借助工具（如Burp的Intruder模块，或sqlmap）自动化进行。

5.2 时间盲注：利用“睡眠”函数作为信号灯

有时候，页面对于真和假的返回看起来完全一样。这时就要祭出时间盲注。其原理是：让数据库根据我们注入的条件真假，执行不同的耗时操作（通常是sleep()函数），通过观察页面响应时间的差异来判断条件真假。

在MySQL中，可以这样构造：

  • 1' and if(1=1, sleep(5), 0)---> 如果页面响应大约延迟了5秒，说明if条件为真（1=1），执行了sleep(5)。
  • 1' and if(1=2, sleep(5), 0)---> 如果页面立即返回，说明if条件为假（1=2），执行了0。

同样，我们可以把1=1替换成我们想猜解的条件，例如if(ascii(substr(database(),1,1))>100, sleep(5), 0)。通过对比响应时间，就能实现和布尔盲注一样的猜解效果。时间盲注对网络稳定性要求高，且速度更慢。

6. 工具辅助与自动化：让sqlmap成为你的利器

手工注入是理解基础，但在真实渗透测试中，面对盲注，我们必须借助自动化工具。sqlmap是这方面的王者。但很多人用sqlmap就是一句sqlmap -u “http://target.com” --dbs，知其然不知其所以然。

6.1 sqlmap核心参数与工作逻辑

以我们刚才手工测试过的DVWA漏洞点为例（假设URL是http://localhost:8080/vulnerabilities/sqli/?id=1&Submit=Submit）。

  1. 基础探测：sqlmap -u “http://localhost:8080/vulnerabilities/sqli/?id=1&Submit=Submit” --cookie=“PHPSESSID=你的会话ID; security=low”

    • -u：指定目标URL。
    • --cookie：这是关键！因为DVWA需要登录后才能访问漏洞页面，你必须提供有效的会话Cookie。可以通过浏览器开发者工具复制。
    • 运行这个命令，sqlmap会先尝试各种注入技术（布尔、时间、联合查询等）来确认是否存在注入点以及是什么类型的数据库。

  2. 获取数据库：确认存在注入后，使用--dbs参数列出所有数据库：sqlmap -u “...” --cookie=“...” --dbs

  3. 获取当前数据库的表：sqlmap -u “...” --cookie=“...” -D dvwa --tables

    • -D：指定数据库名。

  4. 获取表的列：sqlmap -u “...” --cookie=“...” -D dvwa -T users --columns

    • -T：指定表名。

  5. 最终拖取数据：sqlmap -u “...” --cookie=“...” -D dvwa -T users -C user,password --dump

    • -C：指定要导出的列。
    • --dump：导出数据。如果密码是哈希，sqlmap会询问你是否尝试用内置字典破解。

6.2 使用Burp Suite辅助sqlmap

有时候，目标站点的请求比较复杂，有Token、复杂的JSON或重定向。这时，先用Burp抓包，将完整的HTTP请求（包括所有Header、Cookie、POST数据）保存到一个文本文件（比如request.txt），然后让sqlmap直接加载这个文件进行分析：sqlmap -r request.txt。这能绕过很多前端校验和复杂交互。

重要心得：不要过度依赖工具的“全自动”模式。对于关键系统或复杂的注入点，我习惯先用--level和--risk参数调低扫描强度进行试探，同时使用--proxy=”http://127.0.0.1:8080”让sqlmap的流量经过Burp，这样我就能在Burp中清晰地看到sqlmap到底发送了哪些Payload，便于学习和调试。理解工具的行为，比单纯拿到一个结果重要得多。

7. 绕过技巧与高级注入场景

WAF（Web应用防火墙）和简单的过滤机制无处不在。了解常见的绕过技巧，能让你在实战中更从容。

7.1 常见过滤与绕过

  • 过滤空格：可以用注释/**/、Tab键（%09）、换行符（%0a）代替。例如union/**/select。
  • 过滤关键词（如select, union）：
    • 大小写混淆：SeLeCt。
    • 双写：selselectect（如果过滤逻辑是删除关键词，双写后删除中间部分，剩下的正好是原词）。
    • 用等价函数或编码：有些场景下可以用like代替=，用hex()编码字符串。
  • 过滤引号：如果参数是数字型（如id=1），根本不需要引号。如果是字符型且引号被过滤，可以尝试用十六进制表示字符串。例如，admin的十六进制是0x61646d696e，那么Payload可以写成：... where username=0x61646d696e。

7.2 二次注入与宽字节注入

  • 二次注入：这是一种“存储型”SQL注入。攻击者将恶意的SQL片段（比如admin'--）输入到系统的某个存储功能（如注册用户名、留言内容），这些数据被存入数据库时，因为经过了转义或处理，是安全的。但后来，当程序在另一个逻辑中，从数据库取出这个“安全”的数据，并未经再次处理就拼接到新的SQL语句中时，注入就发生了。防御二次注入，要求在所有从不可信源（包括数据库！）取数据并拼接SQL的地方，都进行参数化处理。
  • 宽字节注入：主要针对使用GBK、GB2312等宽字符集的PHP程序。如果程序用addslashes()或mysql_real_escape_string()函数对单引号进行转义（'变成\'），但数据库连接字符集是GBK。那么，当输入%df'时，%df和转义符\（%5c）会结合被解码为GBK编码的一个汉字“運”（%df%5c），从而使得后面的单引号'逃逸出来，形成注入。防御方法是统一使用UTF-8字符集，并在进行转义前调用mysql_set_charset('utf8')或使用PDO的setCharset。

8. 从攻击到防御：开发者的必修课

作为安全研究者或开发者，了解攻击的最终目的是为了更好的防御。

  1. 使用参数化查询（预编译语句）：这是唯一被证明能从根本上防止SQL注入的方法。在任何语言、任何框架中，都优先使用它。
  2. 使用安全的ORM框架：像MyBatis，严格使用#{}，避免使用${}进行字符串拼接。如果动态SQL无法避免（如动态排序、动态表名），必须结合白名单校验。
  3. 严格的输入校验与输出编码：在服务端对输入进行类型、长度、格式的严格校验。对所有从数据库取出并输出到前端的数据进行HTML编码，防止XSS等二次攻击。
  4. 最小权限原则：给数据库应用账户分配最小必要的权限。通常，Web应用只需要SELECT,INSERT,UPDATE,DELETE，绝对不要赋予DROP,CREATE,FILE等高级权限。
  5. 错误信息处理：自定义统一的错误页面，避免将数据库的原始错误信息（包含路径、SQL片段等）直接展示给用户。这些信息是攻击者的路标。
  6. 使用WAF：虽然不能依赖WAF作为唯一防线，但它可以作为一道有效的缓冲层，拦截大量自动化攻击和已知攻击模式。

最后，我想分享一个真实案例。在一次内部代码审计中，我发现一个查询接口使用了字符串拼接来构造ORDER BY子句，就像前面提到的${}问题。我向开发团队指出风险，他们的第一反应是：“这个排序字段是下拉框选的，前端已经固定了选项，用户改不了。” 我当场打开浏览器开发者工具，编辑了前端HTML，手动添加了一个<option>标签，提交后成功实施了注入。这个案例告诉我们，永远不要信任前端传来的任何数据。安全防御必须建立在“假设所有输入都是恶意的”这一零信任基础之上。