1. 项目概述：从“黑盒”到“白盒”的渗透测试思维

在网络安全领域，SQL注入（SQL Injection）是一个经久不衰的话题。它不像某些复杂的0day漏洞那样需要深厚的逆向功底，但其危害性却常常被低估。很多刚入门安全测试的朋友，一提到SQL注入，第一反应就是打开自动化扫描工具，比如sqlmap，输入一个URL，然后等待结果。工具确实高效，但它也像一层“黑盒”，屏蔽了漏洞产生的根本原理和手动挖掘过程中的关键细节。这就像你学会了开车，却不知道发动机是如何工作的，一旦遇到复杂路况或车辆故障，就会束手无策。

这篇内容，我想和你深入聊聊“手动SQL注入”。这不是为了否定工具的价值，恰恰相反，是为了让你在工具失效、遇到WAF（Web应用防火墙）拦截、或者面对一些非常规的注入点时，能够凭借对原理的深刻理解，像外科医生一样精准地“下刀”。我们将从最基础的原理讲起，一步步拆解手工注入的完整流程，包括如何判断注入点、如何获取数据库信息、如何提取数据，以及如何绕过一些基础的防御措施。整个过程，我会结合我过去在渗透测试项目中遇到的实际案例，分享那些在自动化报告里看不到的“手感”和“思路”。

无论你是正在学习网络安全的学生，还是希望提升手动测试能力的运维、开发人员，甚至是负责应用安全评估的工程师，掌握手动SQL注入都是一项不可或缺的核心技能。它能帮你真正理解“数据是如何被窃取的”，从而在设计、开发和审计代码时，建立起更牢固的安全防线。

2. SQL注入核心原理与手动注入的价值

2.1 漏洞根源：程序与数据的混淆

要理解手动注入，必须先吃透它的原理。SQL注入的本质，是Web应用程序没有严格区分“程序代码”和“用户输入的数据”，导致攻击者提交的恶意数据被应用程序误认为是代码的一部分并加以执行。

想象一个简单的用户登录场景。后端代码可能是这样的（以PHP为例）：

$username = $_POST['username']; $password = $_POST['password']; $sql = "SELECT * FROM users WHERE username = '$username' AND password = '$password'"; $result = mysqli_query($conn, $sql);

如果用户老老实实输入admin和123456，那么拼接后的SQL语句是：

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

这没问题。但如果用户在用户名输入框里输入的是admin' --（注意最后有个空格），那么拼接后的语句就变成了：

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

在SQL中，--是单行注释符，它会让后面的AND password = 'xxx'全部失效。这意味着，攻击者只需要知道一个有效的用户名（比如admin），就能在不知道密码的情况下登录系统。这就是最经典的“万能密码”注入。

手动注入的价值，就在于深入这个过程。自动化工具是通过提交大量预定义的“测试载荷”（Payload），并根据服务器返回的差异（如页面内容、响应时间、错误信息）来判断是否存在漏洞以及漏洞类型。而手动注入，要求测试者自己构造这些Payload，并像侦探一样，仔细分析服务器的每一次响应，从而精准地定位问题、理解上下文，甚至发现一些工具无法识别的“盲注”或“非常规注入点”。

注意：所有测试必须在合法授权范围内进行，例如在自己的实验环境（如DVWA、Pikachu靶场）、CTF比赛或企业授权的渗透测试项目中。未经授权的测试是违法行为。

2.2 手动注入 vs. 自动化工具：互补而非对立

我从不认为手动注入和自动化工具是对立的。它们的关系更像是“显微镜”和“探雷器”。

• 自动化工具（如sqlmap）：像高效的“探雷器”，能快速扫描一大片区域，标记出可能的风险点。在时间紧迫、目标范围大的初步信息收集阶段，它的优势无可替代。
• 手动注入：像精密的“显微镜”和“手术刀”。当“探雷器”报警后，你需要手动验证这个报警是否准确（可能是误报）；当遇到复杂地形（如含WAF）导致“探雷器”失效时，你需要手动分析地形，寻找缝隙；当需要精确获取某个特定数据（如管理员哈希值）而不想触发大量日志时，手动注入的精准和低调至关重要。

掌握手动注入，能让你：

1. 理解漏洞本质：不再依赖工具的“黑盒”输出，能从代码层面理解漏洞成因。
2. 提升排查能力：当工具扫描无果时，能通过手动测试发现隐藏的、逻辑复杂的注入点。
3. 绕过基础防御：学习如何构造Payload以绕过简单的过滤和WAF规则。
4. 进行精准利用：在需要最小化攻击痕迹、精确获取特定数据的场景下，手动注入是唯一选择。

3. 手动注入实战全流程拆解

接下来，我们以一个虚拟的、存在漏洞的搜索功能为例，假设其URL为http://test.com/search.php?keyword=apple，完整走一遍手动注入的流程。这个过程我们通常称为“手工注入四步曲”：判断注入点、判断字段数、判断回显位、获取数据。

3.1 第一步：判断注入点类型与闭合方式

这是最关键的一步，目的是确认参数是否真的存在SQL注入漏洞，并确定后端SQL语句是如何“拼接”我们输入的参数的。

1. 初步探测：我们首先在keyword参数后尝试添加一个单引号'。

• 访问：http://test.com/search.php?keyword=apple'
• 观察结果：
  • 如果页面返回数据库错误（如“You have an error in your SQL syntax...”），这强烈暗示我们的输入被带入了SQL查询，且破坏了原语句的语法。这是一个非常乐观的信号。
  • 如果页面显示异常（如空白、部分内容缺失），但无具体错误，也可能存在注入。
  • 如果页面正常，不代表一定安全，可能需要尝试其他闭合方式或进行盲注测试。

2. 确定闭合方式：假设我们收到了错误。接下来要判断原SQL语句是如何“包裹”这个参数的。常见的闭合方式有：单引号'、双引号"、单引号加括号')、双引号加括号")等。

• 尝试apple' --：如果页面恢复正常，说明原语句是用单引号闭合的。因为--注释掉了后面的内容，修复了语法。
• 尝试apple" --：如果恢复正常，说明是双引号闭合。
• 尝试apple') --：如果恢复正常，说明是单引号加括号闭合。

3. 判断注入类型：确定闭合方式后，通过逻辑测试判断注入类型。

• 数字型注入：如果参数本是数字，如id=1，可能无需闭合。测试id=1 and 1=1和id=1 and 1=2。如果前者正常后者异常，则存在数字型注入。
• 字符型注入：我们的keyword参数明显是字符型。测试apple' and '1'='1和apple' and '1'='2。原理同上。

实操心得：很多WAF或过滤规则会检测and、or、--等关键字。在初步探测时，可以尝试使用&&（URL编码为%26%26）代替and，使用#（URL编码为%23）代替--（注意--后必须跟空格）。例如：apple' %26%26 '1'='1。

3.2 第二步：判断查询结果的字段数（列数）

为了后续能够将我们想查询的数据“嫁接”到原查询结果中并显示出来（联合查询注入），我们需要知道原查询SELECT语句到底返回了多少个字段。

这里主要使用ORDER BY子句。ORDER BY n表示根据第n列进行排序。如果n超过了实际列数，数据库就会报错。

1. 构造Payload：apple' order by 1 --
2. 访问：http://test.com/search.php?keyword=apple' order by 1 --
3. 如果页面正常，说明查询结果至少有一列。
4. 然后尝试order by 2,order by 3... 依次递增。
5. 假设当尝试order by 5时页面报错或异常，而order by 4正常，那么我们就可以断定，原查询返回的字段数是4。

3.3 第三步：寻找数据回显位置

知道了字段数（假设为4），我们就可以使用UNION SELECT联合查询，来让数据库执行我们自定义的查询，并将结果“拼”在原始查询结果的后面显示出来。但前提是，我们需要知道页面的哪个位置会显示我们注入查询的结果。

1. 首先，要让原查询不返回任何结果，这样页面预留的“数据展示位”就会空出来，显示我们联合查询的结果。通常使用一个永假条件，例如and 1=2，或者让原查询的WHERE条件不成立。Payload：apple' and 1=2 union select 1,2,3,4 --
2. 访问这个URL。如果联合查询被执行，页面原本显示数据的地方，可能会变成数字1,2,3,4中的某一个或某几个。这些数字出现的位置，就是我们可以控制的数据回显点。
3. 例如，如果页面上“商品名称”的位置显示了数字“2”，在“价格”的位置显示了数字“3”，那么就意味着，我们在联合查询中，替换到SELECT语句第2和第3个位置的数据，会被显示在页面对应位置。

3.4 第四步：获取数据库信息与数据提取

找到了回显点（假设是第2和第3位），我们就可以开始提取信息了。这个过程是阶梯式的，从数据库本身的信息，到具体表名，再到字段名，最后到数据。

1. 获取数据库基础信息：替换回显点位置的数字为数据库函数。

• Payload：apple' and 1=2 union select 1, database(), version(), user() --
• 这里，database()返回当前数据库名，version()返回数据库版本，user()返回当前数据库用户。通过查看页面回显，我们就能知道这些关键信息。

2. 获取所有数据库名/表名：在MySQL中，有一个名为information_schema的系统数据库，它存储了所有其他数据库的元数据（如表名、列名）。

• 获取所有数据库名：

  apple' and 1=2 union select 1, schema_name, 3,4 from information_schema.schemata --

  这会将所有数据库名显示在第二个回显位。
• 获取指定数据库（假设为testdb）中的所有表名：

  apple' and 1=2 union select 1, table_name, 3,4 from information_schema.tables where table_schema='testdb' --

  通常我们需要寻找像admin,users,customer这类可能存储敏感信息的表。

3. 获取指定表（假设为users）中的所有字段名：

apple' and 1=2 union select 1, column_name, 3,4 from information_schema.columns where table_schema='testdb' and table_name='users' --

这样就能列出users表的所有列，如id,username,password,email等。

4. 最终数据提取：知道了库、表、列，提取数据就水到渠成了。

apple' and 1=2 union select 1, username, password, 4 from testdb.users --

这个Payload会将users表中的用户名和密码分别显示在页面的第二和第三回显位上。

注意事项：在实际测试中，password字段很可能存储的是哈希值（如MD5、SHA1）。获取到哈希值后，需要借助彩虹表或在线解密网站进行破解。此外，数据可能非常多，可以使用limit子句分批次获取，例如limit 0,1获取第一条，limit 1,1获取第二条。

4. 进阶技巧：盲注与时间盲注实战

并不是所有SQL注入漏洞都会将数据或错误信息直接回显在页面上。当服务器屏蔽了错误信息，并且我们的联合查询结果也无法显示时，我们就遇到了“盲注”（Blind SQL Injection）。盲注需要我们像“猜谜”一样，通过询问数据库“是或否”的问题，并根据页面反应的细微差异来推断答案。

4.1 基于布尔（Boolean）的盲注

布尔盲注的依据是页面返回内容的“真”“假”两种状态。例如，一个正常的搜索页面和搜索无结果的页面，可能在HTML结构、某个提示语上存在差异。

核心思路：利用and连接一个条件判断，如果条件为真，页面呈现“真”状态；如果为假，页面呈现“假”状态。

实战：逐字符猜解数据库名假设我们已确定存在布尔盲注，当前数据库名的第一个字符的ASCII码是多少？

1. 猜解长度：apple' and length(database())=4 --观察页面，如果返回“真”状态，则数据库名长度为4。
2. 猜解第一个字符：apple' and ascii(substr(database(),1,1))>100 --
   • substr(database(),1,1)截取数据库名的第1个字符。
   • ascii()将其转为ASCII码。
   • 如果页面为“真”，说明ASCII码大于100；否则小于等于100。
3. 通过不断调整比较的数值（使用二分法效率最高），最终确定第一个字符的ASCII码是110，对应字母n。
4. 重复这个过程，修改substr(database(),2,1)、substr(database(),3,1)... 直到猜出完整数据库名test。

这个过程非常繁琐，但原理清晰。在实际操作中，我们通常会编写Python脚本来自动化这个“猜解”过程。

4.2 基于时间（Time-Based）的盲注

这是最隐蔽的一种注入方式。无论页面返回什么内容，看起来都完全一样。此时，我们通过构造让数据库执行延时操作的语句，根据页面响应时间的长短来判断条件真假。

核心函数：SLEEP(n)让数据库休眠n秒。IF(condition, true_part, false_part)条件判断。

实战：判断数据库名第一个字符Payload：apple' and if(ascii(substr(database(),1,1))>100, sleep(3), 0) --

• 解释：如果数据库名第一个字符的ASCII码大于100，则执行sleep(3)，数据库会停顿3秒，导致页面响应时间显著变长（超过3秒）。
• 如果第一个字符的ASCII码小于等于100，则执行0，页面立即返回。
• 我们通过计时器观察页面响应时间，就能完成布尔判断。

时间盲注的猜解过程比布尔盲注更慢，因为每次请求都要等待潜在的休眠时间。但它对防御措施的绕过能力更强。

避坑技巧：在测试时间盲注时，务必先测试sleep(1)是否有效，确定基准响应时间。同时，网络延迟可能导致误判，因此需要多次请求取平均值，并设置一个合理的延时阈值（比如，判断响应时间>2秒才认为是触发了sleep）。

5. 手动注入中的常见问题与排查实录

即使理解了原理和步骤，在实际手动注入时还是会踩很多坑。下面是我总结的一些典型问题及排查思路。

5.1 问题一：单引号被转义或过滤，无法触发错误

现象：输入'后，页面显示\'或直接将其删除，页面依然正常。原因：后端使用了addslashes()、mysql_real_escape_string()等函数对单引号进行了转义，或者直接过滤了单引号。排查与绕过：

1. 尝试数字型注入：如果参数是ID类，尝试and 1=1和and 1=2逻辑测试，可能无需闭合符号。
2. 尝试宽字节注入：如果数据库编码为GBK等宽字符集，可能存在经典宽字节注入。例如输入%df%27，%df与转义添加的反斜杠\（%5c）组合成%df%5c，在GBK中这是一个合法汉字“運”，从而“吃掉”了反斜杠，使后面的%27（单引号）逃逸。
3. 尝试其他闭合符号：如"、)、'))等。
4. 尝试编码绕过：对Payload进行URL编码、双重URL编码、十六进制编码。例如，将UNION SELECT编码为%55%4e%49%4f%4e%20%53%45%4c%45%43%54。

5.2 问题二：关键字（如union, select, and, or）被WAF拦截

现象：输入包含这些关键字的Payload后，页面返回403、WAF拦截提示，或直接跳转到错误页。绕过思路：

1. 大小写混合：UnIoN SeLeCt
2. 双写关键字：有些简单的过滤会删除一次关键字，双写可以绕过。UNIUNIONON SELESELECTCT
3. 使用等价符号或函数：
   • 用&&代替and，用||代替or。
   • 用like代替=。
   • 用mid()、substring()代替substr()。
4. 内联注释（MySQL特性）：/*!UNION*/ /*!SELECT*/。/*!...*/在MySQL中会被执行，在其他数据库中被当作注释，常用来绕过WAF的关键字检测。
5. 注释符分割：U/**/NION SEL/**/ECT。
6. 换行符：%0a（换行）、%0d（回车）可能被WAF忽略。

5.3 问题三：联合查询（union）有结果但不显示

现象：union select 1,2,3...执行不报错，但页面上看不到数字1,2,3。排查：

1. 字段数不对：重新用order by精确判断字段数，确保union前后字段数一致。
2. 数据类型不匹配：原查询的某个字段可能是字符串类型，而你用数字（如2）去占位，可能导致类型错误而不显示。尝试将回显点的数字换成字符串，如'2'。
3. 回显点不在当前视图：可能数据被查询出来了，但输出到了页面的隐藏标签、注释或者JSON数据源里。一定要查看网页源代码（Ctrl+U），搜索你注入的数字。
4. 需要原查询结果为空：确保union前面的语句查询结果为空（如and 1=2），否则页面可能只显示原查询的第一条结果。

5.4 问题四：在盲注中，真/假页面状态难以区分

现象：无论输入什么，页面看起来都差不多，无法确定布尔判断的依据。排查：

1. 深入对比：使用Burp Suite的“对比”（Comparer）功能，或浏览器插件，对“真”“假”两种状态下的HTTP响应进行逐字节比对。差异可能在于一个隐藏的输入框值、一个微小的HTML注释、一个HTTP头的细微差别，甚至是响应时间的毫秒级差异。
2. 寻找二次触发点：有时，注入的结果不会立刻显示，但会影响后续的某个操作。例如，一个“用户是否存在”的查询，其结果可能决定了后续是否显示“找回密码”的链接。
3. 考虑时间盲注：如果实在找不到布尔状态差异，直接尝试时间盲注sleep()函数。

手动SQL注入是一个需要耐心、细心和大量实践的过程。它没有一键通吃的“神器”，每一个新目标都可能带来新的挑战。但正是通过一次次的手动分析、构造、测试和排查，你才能建立起对SQL注入漏洞最深刻的理解，这种理解是任何自动化工具都无法赋予的。当你能够在不依赖工具的情况下，独立完成从发现到利用的全过程时，你才真正掌握了这门技艺。