1. 项目概述：为什么选择 sqli-labs 作为你的 SQL 注入第一课
如果你刚开始接触 Web 安全，或者想系统性地把 SQL 注入这个“老牌”但依然致命的漏洞彻底搞懂，那么 sqli-labs 这个靶场几乎是你绕不开的必修课。我第一次接触它时，感觉就像拿到了一本 SQL 注入的“武功秘籍”，从最基础的报错回显，到复杂的盲注、堆叠注入，它把各种场景都给你搭好了舞台，就等你上去“实战演练”。和 DVWA、Pikachu 这些综合性靶场不同，sqli-labs 非常纯粹，它只专注于 SQL 注入这一件事，并且通过由浅入深的关卡设计，让你能清晰地感受到自己技术的成长轨迹。很多人在网上找“sqli-labs通关”笔记，本质上就是在寻找一条被验证过的、高效的学习路径。今天，我就结合自己当年“磕”靶场的经验，以及后来在渗透测试项目中遇到的真实案例，来拆解一下如何利用 sqli-labs 真正吃透 SQL 注入，而不仅仅是“通关”。
这个靶场的价值在于，它模拟了开发者在编写代码时可能犯的各种错误。比如，有的关卡直接回显数据库错误信息（报错注入），有的只告诉你登录成功与否（布尔盲注），还有的甚至没有任何回显（时间盲注）。攻击者面对的就是这样多变的现实环境。通过手动完成从信息探测、注入点确认、到最终获取数据库数据的全过程，你不仅能记住那些union select 1,2,3的 payload，更能理解其背后的原理：为什么这里要用单引号闭合？为什么 order by 可以猜字段数？information_schema这个数据库在渗透中到底扮演什么角色？把这些原理吃透了，以后遇到 WAF（Web应用防火墙）或者一些奇怪的过滤规则时，你才有能力去思考如何绕过，而不是只会照搬 payload。
2. 环境准备与靶场部署：避开第一个坑
工欲善其事，必先利其器。部署 sqli-labs 本身不难，但对于新手来说，这里往往是第一个“劝退点”。很多人卡在环境配置上，还没开始注入就先放弃了。我推荐最稳定、兼容性最好的组合：PHP 5.x/7.x + MySQL 5.x + Apache。用集成环境（如 XAMPP、PHPStudy）可以省去大量配置麻烦。
2.1 部署步骤与关键配置
首先，从 GitHub 上搜索 “sqli-labs” 找到官方或高星仓库下载源码。解压后，将整个文件夹放到你的 Web 服务器根目录（例如 XAMPP 的htdocs目录下）。接下来是关键的一步：配置数据库连接。找到sql-connections目录下的db-creds.inc文件，用文本编辑器打开。你会看到类似下面的内容：
<?php //give your mysql connection username and password $dbuser ='root'; $dbpass =''; $dbname ="security"; $host = 'localhost'; $dbname1 = "challenges"; ?>这里需要根据你的 MySQL 实际情况进行修改。$dbuser和$dbpass是你的数据库用户名和密码（PHPStudy 默认 root/root，XAMPP 默认 root/空）。$dbname是 sqli-labs 主要关卡使用的数据库，保持“security”即可。修改保存后，通过浏览器访问http://localhost/sqli-labs/（具体路径根据你的文件夹名调整），点击页面上的 “Setup/reset Database for labs” 链接。如果一切正常，页面会提示你数据库和表创建成功。
注意：这里最常见的坑是 MySQL 版本过高（如 MySQL 8.0）导致的认证插件问题。MySQL 8.0 默认使用
caching_sha2_password认证，而老版本的 PHP 驱动可能不支持，会导致连接失败。如果遇到“数据库连接错误”，可以尝试在 MySQL 中为 root 用户重新设置一个使用旧版mysql_native_password认证的密码，或者直接使用 MySQL 5.7 版本，能避免很多兼容性问题。
2.2 部署成功验证与目录结构解析
点击链接后，看到成功的提示信息，只是第一步。我更建议你亲自登录到 MySQL 命令行，查看是否真的生成了security数据库和里面的users等表。这能加深你对靶场数据结构的理解。执行use security; show tables;，你应该能看到 emails、referers、uagents、users 这几张表。后续我们注入获取的数据，主要就来自users表。
了解靶场的目录结构也很有帮助。Less-1、Less-2等文件夹对应每一关的源码，你可以直接阅读index.php来了解这一关的代码逻辑和过滤规则，这对于理解漏洞成因和构思绕过方法至关重要。比如，看到代码里用了mysql_real_escape_string()，你就知道这一关可能考的是宽字节注入。这种“看源码打靶场”的方式，能让你从攻击者思维反向推导到开发者思维，收获更大。
3. 核心攻击流程深度拆解：以 Less-1 为例
网上很多“sqli-labs通关”笔记，会把 payload 罗列出来。但知其然更要知其所以然。我们以最经典的 Less-1（基于错误的字符型注入）为例，完整走一遍手动 Union 注入的思考过程。我强烈建议你跟着操作，并用 Burp Suite 截取每一个步骤的请求和响应，这能帮你建立完整的流量视角。
3.1 第一步：注入点探测与类型判断
访问http://localhost/sqli-labs/Less-1/?id=1，页面正常显示用户 ID、登录名和密码。我们的目标是：通过这个id参数，获取数据库里的其他信息（比如所有用户名和密码）。
首先，判断id参数是否存在注入漏洞。最经典的方法是添加一个永真条件和永假条件，观察页面回显差异：
?id=1‘ and ‘1’=‘1（页面应正常）?id=1‘ and ‘1’=‘2（页面应异常或数据消失）
在 Less-1 中，你会发现输入?id=1‘（一个单引号）时，页面直接爆出了数据库错误信息：You have an error in your SQL syntax...。这立刻告诉我们两件事：1）存在 SQL 注入漏洞；2）漏洞类型是“字符型”，因为单引号破坏了原 SQL 语句的字符串闭合，导致语法错误。
实操心得：在实际测试中，可能不会直接报错。这时就需要更精细的探测。比如，可以尝试
?id=2-1，如果回显和?id=1一样，说明可能是数字型注入（程序执行了2-1这个运算）。在 Less-1 中，我们确认是字符型，并且需要单引号来闭合。
3.2 第二步：构造闭合与确定字段数
既然知道是字符型，并且原语句大概像是SELECT ... FROM ... WHERE id='$id' LIMIT 0,1，那么我们需要用‘来闭合前面的引号，然后插入我们的攻击代码，最后用--+（或#）注释掉后面的引号和语句。
首先，构造一个合法的闭合，确认注入点可用：?id=1‘ and ‘1’=‘1。页面正常，说明我们构造的闭合是正确的。
接下来，确定当前查询语句最终返回的字段数，这是使用UNION SELECT联合查询的前提。因为UNION前后两个SELECT语句的字段数必须相同。这里使用ORDER BY子句来猜测：
?id=1‘ order by 3 --+（页面正常）?id=1‘ order by 4 --+（页面报错）
这说明当前查询返回的字段数是 3。ORDER BY 3表示按照结果集的第 3 列排序，如果该列存在，则正常；ORDER BY 4超出了列数范围，所以报错。这个过程就像在试探一个黑盒的出口宽度。
3.3 第三步：联合查询探测回显点
知道字段数是 3 后，我们就可以构造UNION SELECT语句了。但在这之前，需要让原查询不返回数据，这样页面原本显示数据的位置就会空出来，方便我们查看UNION后面查询的回显。通常用?id=-1‘或者?id=1‘ and 1=2让原查询结果为空。
然后，构造：?id=-1‘ union select 1,2,3 --+
如果页面某处原本显示“用户ID”的地方变成了数字1，显示“登录名”的地方变成了2，显示“密码”的地方变成了3，那么就说明这些位置是我们可以控制的“回显点”。在 Less-1 中，你会发现只有2和3的位置在页面上显示了出来。这意味着，我们后续可以把想要查询的数据，放在UNION SELECT语句的第 2 和第 3 个字段位置。
3.4 第四步：信息收集与数据提取
现在，我们就可以利用这两个回显点，来提取数据库的核心信息了。SQL 注入的终极目标通常是获取数据，而information_schema数据库是 MySQL 的“信息中心”，存储了所有数据库、表、列的结构信息。
获取当前数据库名和用户：
?id=-1‘ union select 1, database(), user() --+在回显点 2 和 3 的位置，你会看到当前使用的数据库名（应该是security）和连接数据库的用户名（如root@localhost）。这步确认了我们攻击的上下文。获取 security 数据库中的所有表名：
?id=-1‘ union select 1,2,group_concat(table_name) from information_schema.tables where table_schema=‘security’ --+这里用了group_concat()函数，把所有的表名拼接成一个字符串返回。你会看到emails,referers,uagents,users。显然，users表是我们最感兴趣的。获取 users 表的所有列名：
?id=-1‘ union select 1,2,group_concat(column_name) from information_schema.columns where table_schema=‘security’ and table_name=‘users’ --+回显会是id,username,password。这样我们就知道了表结构。最终，提取用户名和密码：
?id=-1‘ union select 1,group_concat(username),group_concat(password) from users --+至此，users表中所有的用户名和密码（虽然是哈希值）都会显示在页面上。一次完整的手动 Union 注入攻击就完成了。
注意事项：
group_concat()有长度限制（默认 1024 字节）。如果数据太多，可能显示不全。这时可以改用limit子句分批次查询，例如... limit 0,1获取第一条，... limit 1,1获取第二条。在实际渗透中，这种“化整为零”的思路非常常用。
4. 各类注入手法原理与靶场实战
sqli-labs 的关卡设计精妙之处，就在于它系统地覆盖了 SQL 注入的主要类型。仅仅会 Union 注入是远远不够的。
4.1 报错注入：当错误信息成为你的向导
从 Less-1 到 Less-4，都属于报错注入（Error-Based）。其原理是，通过故意构造错误的 SQL 语句，让数据库将错误信息（其中可能包含我们查询的数据）直接返回到前端页面上。除了前面利用语法错误，更常用的是利用 MySQL 的一些特殊函数，如updatexml()、extractvalue()。
例如，在 Less-5（基于错误的单引号字符型注入）中，页面不会直接显示查询数据，但会显示错误信息。我们可以这样利用：?id=1‘ and updatexml(1, concat(0x7e, (select database()), 0x7e), 1) --+updatexml()函数本意是更新 XML 文档，但第二个参数需要是合法的 XPath 格式。我们通过concat()将波浪符~、我们想查询的数据（如database()）、另一个波浪符合并，形成一个非法 XPath（~security~），从而触发错误，并将这个拼接的字符串在错误信息中输出。0x7e是波浪符~的十六进制，常用来作为数据的边界标识，方便在错误信息中快速定位。
实操心得：报错注入非常高效，一次请求就能带回数据。但它依赖于错误信息的回显。如果网站配置了不向用户显示详细的数据库错误，这种方法就会失效。这也是为什么渗透测试时，要先用单引号等字符试探是否有详细报错的原因。
4.2 布尔盲注与时间盲注：在没有回显的黑暗中摸索
从 Less-5 开始，很多关卡进入了“盲注”的世界。页面不会显示数据，也不会显示具体错误，只根据查询结果返回“存在”或“不存在”两种状态（布尔盲注），甚至始终返回相同页面，只能通过服务器响应时间来判断（时间盲注）。
布尔盲注的核心思想是“猜”。通过构造 SQL 语句，向数据库询问一个个“是或否”的问题，并根据页面特征（如图片是否加载、单词“存在”与否）来判断答案。 例如，猜解数据库名长度：?id=1‘ and length(database())=8 --+如果页面返回“存在”的特征，说明数据库名长度是 8；否则，换其他数字试。猜解数据库名第一个字符：?id=1‘ and substr(database(),1,1)=‘s’ --+substr()函数用于截取字符串。这个过程极其繁琐，必须借助工具（如 Burp Suite 的 Intruder，或 sqlmap）来自动化完成。手动操作的意义在于理解其原理：攻击脚本本质上就是在自动化地遍历所有可能性（a-z, 0-9）。
时间盲注则更进一步，页面连“是/否”的特征都没有。这时我们通过让数据库执行一个耗时的操作（如sleep(5)），然后观察页面响应是否延迟，来判断我们的问题是否为真。?id=1‘ and if(length(database())=8, sleep(5), 1) --+如果页面响应延迟了大约 5 秒，说明数据库名长度是 8。时间盲注是最慢、最耗资源的一种注入方式，但也是防御最严的环境下可能唯一有效的方式。
4.3 堆叠查询与二次注入：更高级的攻击面
堆叠查询（Stacked Queries）允许我们在一次数据库连接中执行多条 SQL 语句，语句之间用分号;分隔。这赋予了攻击者更大的破坏力，可以执行插入、更新、删除甚至创建表、删除数据库等操作。sqli-labs 的 Less-38 就是一个例子。但并非所有数据库驱动和配置都支持堆叠查询，PHP 的mysql_query()函数通常就不支持，而mysqli_multi_query()可能支持。
二次注入是一种更隐蔽的攻击。攻击者先将恶意数据（如包含 SQL 代码的字符串）存入数据库，这些数据在存入时被安全地转义了。但之后，当应用程序从数据库中取出这些“受信任”的数据，并拼接到新的 SQL 语句中执行时，注入就发生了。这考验的是开发者对“数据在不同上下文中的安全性”的理解。防御二次注入，需要对从任何来源（包括数据库）取出的数据，在拼接 SQL 前都进行校验。
5. 绕过防御与工具实战：从手动到自动化
真实的网站不会像靶场这样“赤裸裸”，它们会有各种防御措施。sqli-labs 后面的关卡也引入了简单的过滤，比如对SELECT、UNION、空格等进行过滤或转义。
5.1 常见过滤绕过技巧
- 大小写绕过：如果过滤了
select，可以尝试SeLeCt。 - 双写绕过：如果过滤并删除了一次
select，可以尝试selselectect，中间的select被删除后，剩下的字符正好又组成了select。 - 编码绕过：使用 URL 编码、十六进制编码、Unicode 编码等。例如，空格可以用
%20、+或/**/（注释符）代替。 - 等价函数/语句替换：
substring()可以用mid()、substr()代替；=可以用like、rlike代替；and可以用&&代替。 - 注释符使用：
--（后面有个空格）、#、/*...*/都可以用来注释掉后续语句。/*!...*/是 MySQL 的特有注释，其中的代码会被执行，可用于绕过某些 WAF 的简单正则匹配。
理解这些绕过的本质，是理解防御规则的匹配模式。WAF 或过滤函数通常是基于黑名单或正则表达式，我们的目标就是构造出能执行恶意功能，但又不匹配其规则的特殊 payload。
5.2 Sqlmap 自动化注入实战
手动注入是理解原理的基础，但在真实渗透测试或 CTF 比赛中，效率至关重要。Sqlmap 是开源的 SQL 注入自动化检测与利用工具，功能极其强大。在吃透手动注入原理后，用 Sqlmap 来验证和快速利用是必备技能。
以 Less-1 为例，基本使用流程如下：
- 检测：
sqlmap -u “http://localhost/sqli-labs/Less-1/?id=1” - 列出所有数据库：
sqlmap -u “http://localhost/sqli-labs/Less-1/?id=1” --dbs - 列出指定数据库的所有表：
sqlmap -u “http://localhost/sqli-labs/Less-1/?id=1” -D security --tables - 列出指定表的所有列：
sqlmap -u “http://localhost/sqli-labs/Less-1/?id=1” -D security -T users --columns - dump 表数据：
sqlmap -u “http://localhost/sqli-labs/Less-1/?id=1” -D security -T users -C username,password --dump
重要提示：Sqlmap 功能强大，但务必仅用于授权的测试（如自己搭建的靶场、获得明确授权的渗透测试项目）。未经授权对他人网站使用 Sqlmap 是违法行为。在测试时，可以使用
--batch参数让工具自动选择默认选项，使用--threads设置线程数提高速度，但要注意对目标服务器的压力。
6. 从靶场到实战：防御视角与经验总结
通关了 sqli-labs，不代表就能应对所有 SQL 注入场景。靶场是理想化的、静态的，而真实环境是复杂的、动态的。
6.1 实战中可能遇到的复杂情况
- 非常规的注入点：注入点可能不在
id，而在User-Agent、X-Forwarded-For等 HTTP 头中，或者在 JSON、XML 格式的 POST 数据里。你需要用 Burp Suite 这类工具拦截所有请求，对每一个参数进行测试。 - 多重编码与混淆：数据在传递过程中可能被多次编码（如 URL 编码后 Base64 编码），WAF 可能在你解码前检查，而应用服务器在解码后执行。这就需要你尝试在 payload 中嵌入多层编码来绕过。
- 云 WAF 与动态防护：现在的云 WAF 具备学习能力，简单的 payload 很快会被封禁 IP。需要低慢速的攻击，或者寻找网站真正的源站 IP（旁站攻击）。
- ORM 框架的误用：很多人以为用了 MyBatis、Hibernate 等框架就高枕无忧。以“如何绕过 mybatis #号进行 sql 注入”这个热词为例，MyBatis 中
#{}是预编译占位符，能有效防止注入，但${}是字符串拼接，如果用户输入直接用在${}中，依然存在注入风险。这属于开发者对工具的错误使用。
6.2 开发者如何有效防御 SQL 注入
作为攻击者学习注入，最终目的是为了更好的防御。从开发角度，根治 SQL 注入的核心原则就一条：永远不要信任用户输入，将代码与数据严格分离。
- 使用预编译语句（Prepared Statements）：这是最有效、最根本的防御手段。无论是 PHP 的 PDO，Java 的 PreparedStatement，还是 Python 的
cursor.execute(“SELECT * FROM users WHERE id=%s”, (user_id,))，其原理都是将 SQL 语句的骨架（代码）和参数（数据）分开发送给数据库。数据库会先编译语句骨架，再将参数作为纯数据处理，从根本上杜绝了参数被解释为代码的可能性。 - 对输入进行严格的校验和过滤：在业务层面，对输入的类型、长度、格式（如邮箱、手机号）进行白名单校验。但注意，过滤不能替代预编译，它只是增加攻击难度的辅助手段。
- 最小权限原则：为数据库连接账户分配最小必要的权限。例如，一个只用于查询的页面，其数据库账户就不应该有
DROP TABLE、UPDATE的权限。这样即使发生注入，也能将损失降到最低。 - 避免动态拼接 SQL：这是万恶之源。尽量不要用字符串拼接的方式构造 SQL 语句。如果实在有复杂动态查询的需求，应该使用安全的 ORM 框架提供的查询构建器，或者对输入进行严格的白名单映射。
- 自定义错误信息：关闭或重写数据库的详细错误回显，向用户返回统一的、模糊的错误页面，避免向攻击者泄露数据库结构信息。
通关 sqli-labs 只是一个开始。它给了你一套系统的“攻击图谱”。真正的功力提升，在于将这套图谱与现实中的各种防御措施进行对抗演练，并最终理解如何从架构和代码层面构建更坚固的防线。我自己的习惯是，每学一种新的攻击技巧，都会立刻去想“如果我是开发者，该怎么防住它？”这种双向思考，能让你的安全技术功底变得非常扎实。
