SQL注入实战入门：从sqli-labs靶场Less-1掌握核心测试流程

1. 项目概述：从靶场到实战的SQL注入通关指南

如果你刚开始接触Web安全，或者想系统地检验一下自己的SQL注入水平，那么sqli-labs这个开源靶场绝对是你的必经之路。它就像一本精心编排的“武功秘籍”，从最基础的错误回显注入，一路升级到各种刁钻的过滤绕过和盲注。今天要聊的“Less-1”，就是这本秘籍的第一页，也是整个旅程的起点。很多人觉得第一关太简单，看一眼就过了，但恰恰是这种“简单”，最容易让人忽略掉那些真正重要的细节和思维习惯。通关Less-1，绝不仅仅是输入一个单引号看到报错，然后丢个union select就完事了。它背后涉及的是对Web应用交互逻辑的完整理解、对数据库报错信息的精准解读，以及构建有效Payload的标准化流程。这篇文章，我会以一个渗透测试老兵的视角，带你重新走一遍Less-1，目标不是“过关”，而是让你掌握一套可以应对真实复杂环境的、扎实的SQL注入方法论。

2. 环境准备与靶场初探

2.1 靶场部署与访问

Sqli-labs通常以PHP+MySQL的环境运行。最省事的方法是用Docker一键部署，但对于想深入理解环境配置的同学，我建议手动搭建。你需要一个集成了Apache、PHP和MySQL的环境，比如XAMPP或PHPStudy。将下载的sqli-labs源码解压到Web服务器的根目录（如htdocs或www目录下）。启动Apache和MySQL服务后，通过浏览器访问http://localhost/sqli-labs/，点击“Setup/reset Database for labs”链接来初始化数据库。这个过程会自动创建名为security的数据库，并插入必要的测试数据。

注意：很多新手在这一步就卡住了，常见问题是PHP版本过高导致语法不兼容，或者MySQL连接失败。如果遇到问题，请检查sql-connections目录下的db-creds.inc文件，确保里面的数据库主机、用户名、密码（默认为root,root）与你的MySQL配置一致。对于高版本PHP，可能需要将代码中的mysql_*函数手动替换为mysqli_*函数，这是一个很好的练习，能让你更熟悉代码。

2.2 Less-1页面功能分析

访问http://localhost/sqli-labs/Less-1/，你会看到一个简单的页面，通常有一个输入框，提示你输入用户ID。它的功能非常典型：根据前端传入的id参数，到后端数据库查询对应用户信息，并返回显示在页面上。用我们的话说，这就是一个“用户详情查看”功能点。前端的请求看起来大概是这样的：/Less-1/?id=1。后端PHP代码会接收这个id值，拼接到SQL查询语句中。我们通关的核心，就是要去猜测和验证这个拼接的过程，并找到干预它的方法。

3. SQL注入核心原理与手动测试流程

3.1 理解数字型与字符型注入

在动手之前，必须搞清楚一个关键概念：注入点的数据类型。这直接决定了你Payload的构造方式。

  • 数字型注入：参数被直接用于SQL语句的数字比较或运算中，如SELECT * FROM users WHERE id = $id。这种情况下，参数本身不需要被引号包裹。
  • 字符型注入：参数被用于SQL语句的字符串比较中，如SELECT * FROM users WHERE username = '$name'。这种情况下，参数会被单引号（或双引号）包裹。

Less-1从关卡名“Error Based- Single quotes- String”就明确告诉我们：这是一个基于错误回显、且参数被单引号包裹的字符型注入。知道这一点，你的测试起点就应该是单引号，目的是为了破坏原SQL语句的引号闭合。

3.2 标准化手动测试四步法

我强烈建议新手养成一套固定的测试流程，这能让你在复杂情况下也不至于慌乱。

第一步：探测与确认注入点在输入框输入一个单引号‘，然后提交。这是最重要的第一步。如果页面返回了数据库的详细错误信息（例如，你看到了“You have an error in your SQL syntax...”这样的MySQL报错），那么恭喜，注入点存在，并且是显错型注入，难度直接降低一个等级。这个报错信息是宝藏，它通常会告诉你SQL语句在哪个位置附近出了错，这能帮你反推后端查询的原始结构。

第二步：判断列数（Order By）确认注入后，下一步是弄清当前查询语句最终返回了多少列数据。这是使用UNION SELECT进行数据提取的前提，因为UNION前后查询的列数必须相同。我们使用ORDER BY子句来探测。

  1. 输入：1‘ order by 1 --+
  2. 输入：1‘ order by 2 --+
  3. 输入：1‘ order by 3 --+
  4. 输入：1‘ order by 4 --+

--+是注释符（--后面有个空格，+在URL中常被解释为空格），用于注释掉原查询后面的单引号和其他语句，避免语法错误。当order by 3页面正常，而order by 4页面报错或显示异常时，就说明当前查询的列数为3列。

第三步：确定回显点（Union Select）知道列数后，我们用UNION SELECT来找出哪几列的内容会被显示在页面上。这被称为“回显点”。 输入：-1‘ union select 1,2,3 --+这里有几个技巧：

  1. 将原查询的id设为-1或一个不存在的值，目的是让原查询结果为空，这样页面就会完整显示我们union select的结果。
  2. select 1,2,3就是用数字占位，如果页面某处显示了数字“2”和“3”（通常“1”可能不显示），那就说明第2列和第3列是回显点。我们的Payload就可以放在这两个位置。

第四步：提取信息（Database(), Version(), User()）确定了回显点（假设是2和3），我们就可以开始提取信息了。

  1. 获取当前数据库名：-1‘ union select 1, database(), 3 --+。页面在第二个回显点会显示当前数据库名，通常是security。
  2. 获取数据库版本和用户：-1‘ union select 1, version(), user() --+。这能帮你了解目标环境。

至此，你已经完成了最基本的注入流程，证明了漏洞的存在并获取了初步信息。但Less-1的价值远不止于此。

4. 信息收集与数据库结构探查

4.1 利用系统数据库获取表名和列名

在MySQL中，有一个名为information_schema的元数据库，它就像数据库的“户口本”，记录了所有其他数据库、表、列的信息。这是我们进行深度注入的核心。

  1. 获取security数据库的所有表名：-1‘ union select 1,group_concat(table_name),3 from information_schema.tables where table_schema=‘security’ --+group_concat()函数会将所有结果拼接成一个字符串，避免多次查询。执行后，你可能会看到类似emails,referers,uagents,users的结果。我们的目标通常是users表，因为它很可能存放着用户名和密码。

  2. 获取users表的所有列名：-1‘ union select 1,group_concat(column_name),3 from information_schema.columns where table_schema=‘security’ and table_name=‘users’ --+执行后，你会得到类似id,username,password的列名。

4.2 最终数据提取

现在，表名（users）和列名（username, password）都知道了，就可以直接提取数据了。-1‘ union select 1,group_concat(username),group_concat(password) from users --+这条语句会将users表中所有的用户名和密码分别拼接起来，显示在页面的两个回显点上。你就能看到类似Dumb,Angelina,Dummy,...和Dumb,I-kill-you,p@ssword,...这样的结果。group_concat有长度限制，如果数据太多，可以用substring或limit分片读取。

实操心得：在真实测试中，information_schema库的访问权限可能被限制。因此，掌握基于错误回显的报错注入（如updatexml、extractvalue）和基于布尔/时间的盲注就变得至关重要。Less-1虽然简单，但这个“查询表名->查询列名->提取数据”的思路，是所有SQL注入的通用路径。

5. 漏洞原理深度剖析与Payload构造

5.1 还原后端SQL语句

我们来回溯一下整个漏洞发生的逻辑。假设后端PHP代码是这样的：

$id = $_GET[‘id’]; $sql = “SELECT * FROM users WHERE id=‘$id’ LIMIT 0,1”; $result = mysql_query($sql);

当我们输入1‘ and ‘1’=‘1时，代码拼接后变成：SELECT * FROM users WHERE id=‘1‘ and ‘1’=‘1’ LIMIT 0,1由于我们输入的单引号与原SQL中的左单引号闭合，and ‘1’=‘1‘这个永真条件就被插入到了查询中，导致语句执行，页面正常显示。这就是经典的字符型注入闭合。

5.2 Payload编码与绕过浅谈

在Less-1中，我们直接输入单引号就能生效，说明没有过滤。但在后续关卡或真实场景中，可能会遇到过滤。这时就需要对Payload进行编码或变形。

  • URL编码：单引号‘的URL编码是%27。所以1‘可以写成1%27。
  • 双重URL编码：如果应用做了一次解码过滤，可以尝试双重编码，如%27编码为%2527。
  • 大小写/内联注释绕过：对于简单的关键字过滤（如and,or,union），可以尝试AnD、UnIoN，或者使用MySQL的内联注释/*!*/，如/*!union*/ select。

虽然Less-1用不上这些，但建立这种“绕过”思维非常重要。你可以尝试在Less-1的输入里使用%27代替单引号，结果应该是一样的，这能帮你理解数据在传输过程中的变化。

6. 从靶场到实战的思维跃迁

6.1 自动化工具与手动测试的平衡

很多新手会问：为什么不直接用sqlmap？确实，对于Less-1，一句sqlmap -u “http://localhost/sqli-labs/Less-1/?id=1“ --dbs可能就搞定了。但工具是“黑盒”，它告诉你结果，却不告诉你过程。手动测试的每一步，都在训练你对HTTP请求、SQL语法、应用逻辑的感知力。在实战中，尤其是面对WAF（Web应用防火墙）或奇怪的过滤规则时，手工构造一个精巧的Payload往往是突破的关键，而sqlmap可能因为过于“粗暴”而被拦截。我的建议是：靶场练习阶段，强制自己手工完成前10关以上，把流程刻在脑子里；实战中，用手工测试确认漏洞点和基本类型，再用工具进行高效的数据提取。

6.2 防御视角下的思考

真正理解漏洞，才能更好地防御。从开发者的角度看，如何修复Less-1的漏洞？

  1. 预处理语句（Prepared Statements）：这是根治SQL注入的“银弹”。使用PDO或MySQLi的预处理功能，将SQL语句与数据分离，用户输入永远被视为数据而非代码。这是首选的、最安全的方案。
  2. 严格的输入验证：对于id这种参数，明确其应为整数，那么在接收后使用intval()函数强制转换为整数。这样，即使用户输入1‘ union select...，也会被转换成1。
  3. 最小权限原则：连接数据库的账号，不应该拥有information_schema的查询权限，或者不应该拥有FILE、OUTFILE等高危权限。这能在漏洞被利用时，极大限制攻击者的破坏范围。

通关Less-1，如果你只记住了一个Payload，那收获是有限的。但如果你理解了从探测、确认、判断列数、找回显点到系统信息查询、最终数据提取这一整套链条，并且能站在攻击和防御两个角度去思考，那么你这第一步就迈得无比扎实。后续的关卡，无非是在此基础上增加过滤、改变回显方式、关闭错误提示，核心的测试思维和流程是不变的。带着这套思维进入Less-2、Less-3...你会发现，它们不再是孤立的谜题，而是同一个故事的不同章节。