从事这行久了你会发现，很多在外面吹得天花乱坠的所谓“高危漏洞”，真正上了授权测试的项目清单，翻来覆去就那么几个。SQL注入常年稳居前三，几乎每一次外网渗透测试、每一次内网横向评估，都得跟它打照面。原因很简单：它门槛低、变种多、一旦打穿直接拿数据库权限，严重情况下还能通过文件读写直接拿下服务器。这篇文章把我在实际渗透测试项目中遇到过的、以及平时整理笔记时反复回看的SQL注入常见方式做一次系统汇总，重点讲清楚每种注入的成因、识别方法、利用姿势和对应的防护思路。无论你是刚入行准备走渗透测试方向的初学者，还是已经在做等保、红队评估的从业者，这份汇总都能当一份速查手册用。
1. SQL注入的本质与渗透测试中的定位
1.1 一句话说清注入原理
SQL注入的本质，是程序把用户输入的内容当成了SQL语句的一部分来解析执行。正常情况下，用户输入应该只是数据，比如你登录时输入的username是admin，数据库执行的是SELECT * FROM users WHERE username = 'admin'，那用户名就是纯粹的数据。但如果开发者图省事，直接用了字符串拼接：
$sql = "SELECT * FROM users WHERE username = '" . $_POST['username'] . "'";这时候用户输入的内容就不再只是数据了。你输入admin' OR '1'='1，拼出来的SQL就变成：
SELECT * FROM users WHERE username = 'admin' OR '1'='1'后面的OR '1'='1'恒为真，整条查询就不再看用户名具体是什么，直接把整表数据都返回了。这就是最原始的注入雏形。因为输入被拼进了代码的上下文，它就有了“参与解析”的能力，这跟XSS把输入拼进HTML一个道理，只是SQL注入玩的是数据库解析器，攻击面更直接、危害更大。
我在做渗透测试时判断一个参数能不能注入，核心就看三点：第一，这个参数值会不会被拼进SQL；第二，拼接时有没有做转义、过滤或参数化；第三，SQL执行结果会不会以某种形式回显到前端或者产生可观察的差异。这三点全部满足，基本就跑不掉了。
1.2 为什么现在依然是“常青树”
很多人觉得SQL注入是十几年前的老古董了，现在框架都预编译了，哪还轮得到它。这个想法确实天真了。我自己测过不少系统，老代码改造成新框架时，历史接口没清干净的情况太多了；还有一批报表系统、数据迁移工具、Excel导入导出功能，为了图方便仍然在手拼SQL。更有意思的是，很多开发者知道要用参数化查询，却不知道ORDER BY、IN、表名这类“不能参数化的SQL片段”也同样能被注入。还有从外部数据源取参数再拼接的场景，比如把请求头、Cookie、上传文件名带进SQL，这都属于典型的二次注入入口。
所以SQL注入在渗透测试里永远是必测项，不光是测外网Web系统，内网OA、ERP、工业控制系统的上位机软件，只要能传参到数据库，都有它的身影。这篇文章我按注入方式做分类，逐个拆解，方便你在测试时对照排查。
2. 六类常见注入方式逐一拆解
2.1 联合查询注入：有回显时效率最高
联合查询是效率最高的一种注入，因为它能直接把数据“合并”到正常查询结果里输出到页面，相当于数据库在替你打印数据。前提是页面必须存在SQL查询结果的回显位置，也就是页面上能动态展示数据库返回的字段内容。
利用步骤一般是三步。第一步，判断列数，用ORDER BY n不断调整数字：?id=1' ORDER BY 3--+正常，ORDER BY 4报错，说明原查询只有3列。第二步，用UNION SELECT 1,2,3填充占位，此时页面上哪些位置回了数字，就代表“显示位”对应哪一列。第三步，在显示位替换成你要查的数据。
以MySQL为例，爆出当前库所有表名：
?id=-1' UNION SELECT 1,group_concat(table_name),3 FROM information_schema.tables WHERE table_schema=database()--+这里把id改成-1，是为了让原查询结果集为空，后面的UNION结果才能顶上来显示。一个小经验：先别忘了测试注释符是--+、#还是--，不同数据库风格不一样。SQL Server、Oracle下注释符有差异，先摸清数据库类型再构造payload，否则容易做无用功。
有个比较隐蔽的点：不是所有回显位都能显示所有数据类型，有的位置适合显示字符串，有的适合显示数字。碰到UNION没反应，优先排查是不是列类型不匹配。
2.2 报错注入：无回显时的务实选择
联合查询最大的软肋是页面没回显位置，很多后台管理接口只返回“成功”或“失败”。这时候报错注入就派上用场了，它的思路是故意构造会让数据库报错的表达式，而数据库的错误信息里会包含我们想要查询的数据。MySQL中最常用的两个函数是updatexml()和extractvalue()，它们的XPath参数如果格式不合法，数据库会把错误内容原样打印出来。
经典的报错payload：
?id=1' AND updatexml(1,concat(0x7e,(SELECT user()),0x7e),1)--+0x7e是波浪号~的十六进制，作用是确保拼接出来的XPath内容不合法，强制触发错误输出。报错注入有个非常蛋疼的限制：错误信息长度最多显示32个字符左右，所以拖数据时必须配合substr()一段一段截取：
?id=1' AND updatexml(1,concat(0x7e,substr((SELECT group_concat(table_name) FROM information_schema.tables WHERE table_schema=database()),1,20)),1)--+分20个字符一段手工提取很折磨人，我一般直接写脚本或者让sqlmap跑报错注入模式。不过原理必须懂，因为很多WAF对updatexml和extractvalue做关键字拦截，需要你用mid()、substring()等函数做变体，原理不熟根本绕不过去。
PostgreSQL下报错注入常见用cast()强制类型转换，SQL Server下用convert()配合整数溢出，Oracle下用ctxsys.drithsx.sn()这类函数。能报错的位置永远是开发者留下的一扇后门，渗透测试时优先关注。
2.3 布尔盲注：页面只告诉你“是/否”
有些系统既没回显，也不报错，但页面内容会因为SQL条件真假出现细微差异。这就属于布尔盲注。最基础的判断方法是：
?id=1' AND 1=1--+ ?id=1' AND 1=2--+第一条正常返回页面A，第二条返回页面B或空白，说明存在布尔盲注。它的原理是注入的条件直接影响整个WHERE子句的真假，进而影响页面有没有数据。利用时用ascii()函数配合substr()逐字符提取数据：
?id=1' AND ascii(substr((SELECT database()),1,1))>100--+这个payload的意思是：当前库名的第一个字符的ASCII码是否大于100。返回正常说明大于100，继续二分，一般8次左右就能确定一个字符。手工测非常耗时，所以布尔盲注在有工具可用时根本不手跑。但工具失效的场景很多，比如参数被URL编码过一道、请求需要自定义签名，这时候就必须手写Python脚本跑二分。
我在测试中遇到布尔盲注时，会先用Burp Suite对比两次请求的响应长度，确认差异点是正文内容还是响应头，排除CDN缓存导致的假阳性。有次碰到页面差异只有1个字节，差在时间戳字段上，那就不适合布尔盲注，得换时间盲注。
2.4 时间盲注：最后一个可靠的信道
当页面在SQL真假情况下输出完全一样，没有任何布尔差异可观察，时间盲注就是最后的方案。它的原理是让数据库根据条件去执行一个耗时的操作，比如MySQL的sleep()、benchmark()，SQL Server的WAITFOR DELAY，PostgreSQL的pg_sleep()，然后通过响应时间差异来判断条件真假：
?id=1' AND IF(ascii(substr((SELECT database()),1,1))>100, sleep(3), 0)--+这条payload的意思是：如果库名第一个字符ASCII码大于100，就睡3秒，否则立即返回。你在前端看到响应3秒以上，说明条件成立。时间盲注最大的坑在误判。网络本身有延迟，数据库并发高的时候，本来该立即返回的请求也可能卡个两三秒。我个人的经验是：先用sleep(5)测试三次，记录基准时间，再把sleep时间拉长到8~10秒做条件判断，宁可慢一点也要避免误报。benchmark()类payload我基本不用，它极容易把数据库CPU打满，在授权测试里属于容易出事故的姿势。
时间盲注是所有盲注里最稳定的信道，但也最慢。实战中如果目标允许，我通常先跑一遍sqlmap的--time-sec=8参数，再手工验证关键数据。
2.5 堆叠注入与二次注入：被低估的杀伤链
堆叠注入指的是通过分号将多条SQL语句拼接在一起执行：
?id=1'; UPDATE users SET password='hacked' WHERE id=1--+它的前提是数据库连接驱动允许一次执行多条语句。很多场景下PHP的mysqli默认禁止多语句执行，但SQL Server和PostgreSQL的部分驱动是支持的。堆叠注入的优势在于它能执行任意的增删改：改密码、删表、写文件、调用存储过程，比单纯的查询注入高一个量级。但也是因为多数驱动会拦截，堆叠注入在实战中的命中率反而没有联合查询高。我一般会在测试早期就尝试一次分号，如果后端报错特征明显被拦，就果断放弃走别的路线。
二次注入比堆叠注入隐蔽得多，它不要求前端立即产生效果，而是把“脏数据”存进数据库，等另一个功能点把这条数据取出来拼接SQL时再触发。经典场景是注册功能：注册用户名时写入admin'-- -，注册接口因为用了参数化没出事，数据正常入库。但修改密码接口如果用username拼SQL，就可能出现：
UPDATE users SET password='newpass' WHERE username='admin'-- -'这里的-- -把后面的单引号注释掉，实际作用就成了修改admin的密码。二次注入最难防的地方在于，第一处“注入点”表面上完全安全，代码审计很难发现，WAF也不会拦，最终触发点在另一个角落。渗透测试时我会特别关注“写入数据库后再被取出拼接”的业务逻辑，比如用户名、昵称、收货地址、留言板内容——这些字段进库时干干净净，出库时可能变成致命武器。
2.6 编码类注入：宽字节与HTTP头位置扩展
宽字节注入是历史遗留问题，但在老系统中仍然存在。它主要出现在PHP+MySQL且连接字符集为GBK的环境中。开发者为了防注入，会把单引号转义成\'（即%5c%27）。但如果我们输入%df%27，在GBK编码下，%df%5c会被解析成一个完整的汉字，后面的单引号就脱离了转义束缚，成功闭合SQL语句：
?id=1%df%27 AND 1=1--+这个过程具体点说，就是\（%5c）被%df“吃掉”了，两者组合成一个宽字符，单引号裸奔出来。这套原理放到现在的UTF-8环境里大多失效了，但MySQL连接层编码设置不规范的老项目仍然有。遇到这类情况，先判定字符集再决定用不用宽字节思路，不要一上来就试%df。
HTTP头注入是我在测试中经常顺手验的。很多开发者只对GET/POST参数做过滤，却忽略了User-Agent、X-Forwarded-For、Referer、Cookie这些请求头也可能进入SQL。比如有的系统把客户端IP存到数据库，后台管理页面再查询展示，这里X-Forwarded-For就是注入点：
X-Forwarded-For: 127.0.0.1' AND updatexml(1,concat(0x7e,database(),0x7e),1)--+所以测试时不要只盯参数，把HTTP请求里每个可控点都过一遍。热词里提到的SQL Server场景，本身安装建库这些我就不展开了，但测试SQL Server时要注意，它的报错函数体系、注释符（--）、字符串拼接方式（+而不是空格）跟MySQL差异很大，识别错数据库类型，后面所有payload都是白干。
3. 注入类型的识别流程与绕过手法
3.1 五步判断当前是什么注入类型
拿到一个疑似注入点，我推荐按固定顺序判断，效率最高，不遗漏：
第一步，摸清数据库类型。看报错信息里的关键字，MySQL的You have an error in your SQL syntax、SQL Server的Microsoft OLE DB Provider for SQL Server、Oracle的ORA-01756，都是极好的“指纹”。没报错就试函数差异，比如version()在MySQL能跑，其它库就是语法错误。
第二步，测闭合方式。参数值是单引号包着还是双引号包着，还是数值型不带引号，直接在参数后面加一个引号看报错特征。这一步决定payload后面要不要闭合引号、要不要加注释符。
第三步，测回显。联合查询能出数据，走UNION；出不了但报错，走报错函数；什么都不出，进入盲注判断。盲注里先看布尔差异，页面正常/异常两张脸，再考虑时间盲注。
第四步，测注释符。--+在URL里其实+被解码成空格，本质是--加空格；#在某些请求里会被当成锚点，要URL编码成%23。注释符写错，后面的闭合引号就会破坏SQL语法，前功尽弃。
第五步，测堆叠和二次注入的可能性。这一般留到主流程之后再试，先拿到数据优先级最高，再考虑写文件、提权这些进一步利用。
这套流程我称为“五步定级法”，几乎每次授权测试都能用上，也顺手能排查掉大量“伪注入”。所谓伪注入，就是参数加引号报错，但加逻辑判断却无差异，多半是程序内部的异常处理把SQL错误直接抛出来了，并没有真正执行注入条件。
3.2 常见WAF绕过与进阶变体
现在裸奔的系统不多了，多少都套着WAF，注入payload容易被拦截。常见的绕过思路我整理成了一套优先级清单：
第一，大小写混合与关键字替换。UNION SELECT改uNiOn SeLeCt，能干掉一批基于纯字符串匹配的老WAF。第二，内联注释。MySQL的/*!union*/写法能绕过不少关键字过滤，因为数据里合法的MySQL扩展语法，过滤器容易忽略。第三，用注释符号拆分关键字，比如UN/**/ION SE/**/LECT，很多正则表达式没处理注释就被骗过去了。第四，字符串函数重写，substr()换mid()或left()，ascii()换hex()，sleep()换benchmark()。第五，编码绕过，URL双重编码、十六进制编码、Unicode编码，关键看后端解码顺序，WAF解一次，应用层又解一次，就能制造差异。
还有一个容易被忽略的思路是等价替代，OR可以用||替代（注意MySQL默认不开启PIPES_AS_CONCAT，||在布尔上下文是或的意思），空格可以用%0a、%09、%0b等替代。绕过没有银弹，本质是猜WAF的过滤规则，所以先手工试几个最普遍的姿势，摸清WAF指纹再决定上什么tamper脚本。
3.3 万能密码与登录绕过的实战边界
热词里提到了“sql注入万能密码绕过”，这块确实在登录口渗透测试里很常测。最经典的万能密码是这样：
用户名: admin' OR '1'='1'-- 密码: 任意拼出来就是：
SELECT * FROM users WHERE username='admin' OR '1'='1'-- ' AND password='xxx'--注释掉了后面的密码判断，OR '1'='1'恒真，整条SQL直接返回第一个用户的数据，登录验证就被绕过去了。类似的变体还有' OR 1=1#、admin'--、'='等等。
但说实话，万能密码现在在正规系统上的成功率已经很低了，原因有三个：一是大部分登录逻辑用了参数化查询，输入永远只是数据；二是即使拼接查询，很多程序会额外校验返回结果的行数和密码字段；三是密码校验从SQL层挪到了应用层，查出用户记录后再用哈希比对，SQL再怎么注入也绕不过第二步。所以我在测试登录口时，万能密码只花五分钟快速验证，更多精力放在看接口的响应差异、验证码逻辑和找回密码流程上。
4. 渗透测试实战：从注入点到数据落地的完整流程
4.1 授权、靶场与测试边界
先强调一个原则：渗透测试这份工作，所有技术动作都必须建立在授权范围内。自己搭的靶场，或者合同明确授权的测试目标，才是练习和验证技术的合法环境。DVWA、sqli-labs、bWAPP这些都是免费的本地靶场，想练SQL注入完全够用。我在带新人时说的第一句话永远是：技术本身没有对错，但边界不清的测试行为是会出事的。下面的实操步骤全部默认你在授权靶场里执行，请自觉守住这个底线。
4.2 手工注入实操记录
以sqli-labs的Less-1为例，完整走一遍手工注入流程。
判断注入点和闭合方式。URL是http://127.0.0.1/sqli-labs/Less-1/?id=1，在参数后加单引号，页面报错，且错误信息显示是单引号闭合。测列数：
GET /sqli-labs/Less-1/?id=1' ORDER BY 3--+ HTTP/1.1页面正常，把3改成4，报错，确认原查询只有3列。接下来构造联合查询：
GET /sqli-labs/Less-1/?id=-1' UNION SELECT 1,2,3--+ HTTP/1.1页面上回显了2和3两个位置，说明显示位在第2列和第3列。现在把第2列换成数据库名：
GET /sqli-labs/Less-1/?id=-1' UNION SELECT 1,database(),3--+ HTTP/1.1得到当前数据库名security。然后一次性爆出所有表名和字段名：
GET /sqli-labs/Less-1/?id=-1' UNION SELECT 1,group_concat(table_name),3 FROM information_schema.tables WHERE table_schema=database()--+ HTTP/1.1接下来对着users表，爆出所有用户名和密码：
GET /sqli-labs/Less-1/?id=-1' UNION SELECT 1,group_concat(username,0x3a,password),3 FROM users--+ HTTP/1.1这套流程跑下来，刚开始可能要十分钟，熟练之后两分钟搞定。手工注入的核心价值不在于“跑得比工具快”，而在于让你理解每一步在干什么。sqlmap一句命令能出结果，但遇到复杂WAF、自定义协议、特殊过滤时，没有手工基础你连payload该往哪个方向改都不知道。
4.3 sqlmap效率化操作与常用参数
工具选型上，SQL注入这块sqlmap依然是第一选择。它不是最强，但生态最全、案例最多、遇到问题最好搜。常规操作我整理了一张速查表：
| 目的 | 命令 |
|---|---|
| 基础检测 | sqlmap -u "http://target/list.php?id=1" --batch |
| POST参数 | sqlmap -u "http://target/login.php" --data="name=admin&pwd=123" |
| 带Cookie | sqlmap -u "http://target/list.php?id=1" --cookie="PHPSESSID=abc123" |
| 指定数据库类型 | sqlmap -u "http://target/list.php?id=1" --dbms=mysql |
| 枚举数据库 | sqlmap -u "http://target/list.php?id=1" --dbs |
| 枚举指定库的表 | sqlmap -u "http://target/list.php?id=1" -D security --tables |
| 拖指定表数据 | sqlmap -u "http://target/list.php?id=1" -D security -T users --dump |
| 提升检测深度 | sqlmap -u "..." --level=3 --risk=2 |
| 绕过脚本 | sqlmap -u "..." --tamper=space2comment |
--level和--risk是新手最容易忽略的。默认level 1只测GET参数，升到3会测请求头里的注入点；risk 2会增加时间盲注等更激进的payload，但耗时也会成倍增长。我一般策略是先用默认参数快速扫一遍，发现可疑点后再针对性地加level/risk，不要一上来就全套伺候。--tamper是把payload做变形处理的插件，遇到WAF时再上，比如space2comment把空格换成注释，between把比较运算改成BETWEEN。
一个比较关键的操作，如果sqlmap检测出多个注入点，不用每个都跑完，选一个数据完整度最高的注入点拖数据就行，省时间。还要注意：sqlmap会把数据库跑挂的极端情况不是没有，时间盲注模式下并发太高、benchmark类payload，都可能把目标数据库负载拉满。授权测试也需要克制，我给自己定的规矩是单请求串行跑，绝不并发多个sqlmap。
4.4 常见问题与排查技巧实录
问得最多的问题是：页面加引号会报错，但sqlmap跑不出注入点。这种情况十有八九是请求链路里有防护层，比如WAF把有特征的恶意请求直接拦截了，而手工加引号这种“低危操作”没触发。排查思路是：先用Burp对比正常请求和sqlmap的请求差异，把手动设置的User-Agent、Cookie、Referer补全；再把--level升到3，加上--tamper试编码绕过脚本；最后确认数据库类型是不是被识别错了，加--dbms手动指定。
第二个高频问题：注入点确认存在，但UNION不出数。可能原因有几个：列数判断错误、显示位被应用层过滤、目标数据库版本不支持information_schema、字符串类型不匹配。我的排查顺序是：先用ORDER BY重新确认列数；再用UNION SELECT NULL,NULL,NULL测试（NULL能兼容所有数据类型）；最后换个数据源，比如MySQL 5.0以下没有information_schema，但可以直接爆库名。
第三个高频问题：时间盲注老是超时或者误报。先测基准时间，连续请求十次正常的页面，记下平均值。然后把sleep时间设成基准时间的三倍以上，避免网络波动的干扰。另外注意不要用sleep(0)做假条件判断，有人图省事用sleep配合条件真假，但有些数据库会把0当成假、1当成真，结果正好相反，容易搞反判断逻辑。
第四个问题比较隐蔽：报错注入有回显，但显示内容不全。前面说过updatexml有32字节长度限制，解决办法就是分段截取，或者干脆换联合查询。有时候数据里带特殊字符，比如单引号、反斜杠，直接拼接进payload就会破坏语法，这时候可以用hex()把目标内容转成十六进制再拼进去。
4.5 修复建议与防护落地
渗透测试报告写到最后，总归要落到修复建议上。如果只会测不会修，这测试报告就是瘸腿的。SQL注入的修复，第一位永远是参数化查询，也就是预编译语句：
String sql = "SELECT * FROM users WHERE username = ?"; PreparedStatement ps = conn.prepareStatement(sql); ps.setString(1, username);原理不复杂：SQL语句的结构在预编译阶段就已经固定下来，用户输入只是作为参数值传入，数据库引擎不会再把它当作SQL代码解析。这相当于把“数据”和“代码”从物理上隔离开了，注入自然无从谈起。这不是什么高级技巧，但覆盖面最广、成本最低、最不容易出错。
除了参数化，还要做纵深防御。一是输入校验，对整型参数做强类型限制，对字符串参数做白名单校验，拒绝一切不在预期格式内的输入。二是最小权限原则，数据库账号能用SELECT绝不给INSERT，能用INSERT绝不给UPDATE/DELETE，绝对不能拿root或者sa账号给Web应用连库。三是关闭错误回显，把详细的数据库报错信息记录到日志里，只给用户返回通用错误页，这一步能直接把报错注入和盲注的信息通道切断。四是WAF兜底，但WAF只是缓解手段，不能依赖它根治。
我自己在做代码审计时会额外关注三个容易漏的地方：动态表名、动态列名、ORDER BY子句。它们几个没法用参数化，必须走白名单或者枚举映射方案。如果你在开发自己的系统，把这些场景提前设计好，相关代码都会省心很多。
5. 工具选型解析与手工能力的平衡
工具在SQL注入测试里能大幅提效，但工具不是万能的。我的习惯是先手工把注入点确认清楚，再让工具去干活。sqlmap再聪明，它也只是把常见的注入模式跑一遍，碰到业务逻辑复杂的参数、自定义的序列化协议、需要多重签名的请求，它一样会卡住。这时候手工构造payload的能力就是底牌。
Burp Suite是整个渗透测试流程里的“基础设施”，拦截、改包、重放、对比响应，每一环都离不开。我的日常工作流是：Burp拦截请求、删掉无关参数、逐个测试注入点；sqlmap导出Burp捕获的完整请求文件跑批量测试；最后再用Python脚本处理盲注的二分提取逻辑。三者配合，效率和准确率都高。
对于初学者，我的建议是：先练手工，别急着上工具。你把sqli-labs前20关每一关的payload都手写一遍，理解每句SQL在干什么，然后再碰sqlmap，你会发现自己看工具输出时是完全不同的一层理解。工具是加速器，不是替代品。
6. 写在最后的一点体会
SQL注入从提出到现在快二十年了，中间被各种框架、防护技术“判过死刑”，但直到今天它依然活跃在渗透测试的第一线。我自己最大的体会是：这个漏洞最迷人的地方不在于它能拖出多少数据，而在于它迫使你去理解程序的数据流——从HTTP请求到后端语言、再到SQL引擎，整条链路上任何一个节点的疏忽，都可能被精准捕捉。学会SQL注入，你对Web应用的认知会有一个质的飞跃，这也是为什么它一直是安全入门必修课。
最后再分享一个我自己常用的细节技巧：手工测试时，所有payload尽量先在Burp的Repeater里调试通了再放到sqlmap里跑，避免直接在命令行里写长串payload，转义和引号问题会让你怀疑人生。另外，每次测试结束养成清理临时文件和关闭代理的习惯，职业习惯这种东西，关键时刻能帮你避免很多不必要的尴尬。
希望这篇文章能成为你渗透测试路上的工具书之一。遇到SQL注入相关问题，翻一翻这里面的排查思路，大概率能给你省点时间。
