报错型SQL注入的典型响应特征是页面直接返回含敏感信息的数据库错误，如版本号、字段名或表名；需验证参数可控性、报错触发性及内容可变性，结合数据库特有报错函数（如MySQL的UPDATEXML）精准利用。
报错型SQL注入的典型响应特征
生产环境里能直接看到数据库报错，基本等于把数据库结构白送给攻击者。关键不是“有没有报错”，而是“报错里有没有敏感字段名、表名、函数名或版本号”。比如页面返回 You have an error in your SQL syntax; MySQL version 5.7.33 或 Unknown column 'password_hash' in 'field list'，这类信息绝不是开发该暴露的。
怎么验证报错是否真实可控
不能只看一次报错就下结论。要确认三点：参数是否可控、报错是否由该参数触发、报错内容是否随输入变化。常用验证步骤：
- 先试
'（单引号），看是否触发语法错误；再试"（双引号），观察报错是否变化——不同引号闭合方式暴露不同上下文 - 用
' AND SLEEP(1)--测试是否能控制执行逻辑，如果响应延迟但无报错，说明可能被WAF拦截或已转为盲注 - 构造
' OR 1=1 UNION SELECT 1,2,3--，若报错中出现column count doesn't match，说明后端执行了UNION，且列数可推断 - 避免用
ORDER BY盲猜列数——生产环境常禁用该语法，或返回空响应，容易误判
MySQL/PostgreSQL/SQL Server 报错差异点
不同数据库触发报错的方式和返回内容差别极大，识别时必须对症下药：
- MySQL 常见报错函数：
EXTRACTVALUE()、UPDATEXML()，报错信息里会带 XPath 表达式解析失败提示，且直接回显查询结果 - PostgreSQL 更倾向用
CAST()或array_to_string()触发类型转换错误，错误里常含invalid input syntax for type和实际值 - SQL Server 报错最“直白”，
;后接任意非法语句（如;WAITFOR DELAY '0:0:5'）常导致Incorrect syntax near ';'，但真正泄露结构的是ERROR_NUMBER()+ERROR_MESSAGE()组合
为什么生产环境不该出现这些报错
根本原因不是“没关调试模式”，而是错误处理逻辑本身就有缺陷。比如 PHP 中开启 display_errors=On 只是表象，深层问题是没用 try/catch 捕获 PDO 异常，也没做 error_log() 记录+用户侧友好降级。更危险的是，有些团队用 mysqli_error() 把原始错误拼进 HTML 返回，等于主动喂数据给爬虫。真正的修复点在于：所有数据库异常必须被拦截、脱敏、记录，前端只返回统一错误码（如 500-DB-ERR），绝不透出任何 SQL 片段或字段名。
