报错注入本身不危险，危险的是它暴露了本不该出现在生产环境的错误详情——一旦开启，数据库结构、用户权限、甚至明文密码都可能直接回显在 HTTP 响应里。
为什么报错注入能直接泄露数据库结构
MySQL 的 updatexml()、extractvalue() 等函数在解析非法 XPath 表达式时，会把整个参数原样塞进错误消息。攻击者只要让子查询结果拼进第一个参数，错误信息就变成“数据传输通道”。
- 错误不是偶然发生的：比如
updatexml(1, (SELECT user()), 1)中，SELECT user()先执行，结果作为第二个参数传入；而该参数必须是合法 XPath，否则报错——但报错前值已计算完毕 - 显错长度有硬限制：
updatexml()和extractvalue()最多只显示 32 字符，gtid_subset()可到 200 字符，超出部分被截断，容易漏关键字段 - 不同 MySQL 版本支持函数不同：5.1+ 才支持
updatexml()，5.6.5+ 才支持gtid_subset()，盲目用 payload 可能无响应
SQL 层最有效的三道拦截关卡
不能靠“不让报错”来防御，而要从 SQL 执行源头切断数据外泄路径。
- 禁用高危函数：在 MySQL 配置中通过
sql_mode或权限控制移除普通账号对updatexml、extractvalue、floor(rand())等函数的执行权限（注意：仅 revoke 函数权限不够，需配合SECURITY_CONTEXT限制） - 关闭系统表访问：执行
REVOKE SELECT ON information_schema.* FROM 'app_user'@'%'，防止通过information_schema.tables枚举表名 - 强制最小权限原则：应用连接数据库的账号不应有
FILE、PROCESS、SUPER权限，且禁止跨库查询（如app_db.users不能查mysql.user）
开发侧最容易被忽略的配置点
很多团队以为加了 WAF 就安全了，但 WAF 对报错注入的识别率普遍低于 40%——因为 payload 太分散、变形太多，且发生在 SQL 执行后而非请求阶段。
- PHP 中
display_errors = On+error_reporting = E_ALL是最大雷区，哪怕只在 dev 环境启用，也常被误推到预发或灰度环境 - Node.js 的
mysql2库默认抛出完整错误栈，若未 catch 后重写 message，err.sqlMessage会直接透出字段名和表名 - Java 的 MyBatis 若使用
${}拼接而非#{}预编译，错误堆栈里会出现原始 SQL 片段，含未脱敏的用户输入
真正卡住报错注入的，从来不是某个函数禁用或某条正则规则，而是错误信息从不出现在 HTTP 响应体里——无论开发环境还是线上，所有数据库异常都应转为统一状态码（如 500）+ 无字段名、无表名、无函数名的泛化提示。
