关键看报错是否回显数据库结构或执行上下文，如MySQL的“Unknown column 'xxx'”、PostgreSQL的“syntax error at or near 'xxx'”，结合Burp抓包查SQLSTATE等关键词，并关注版本、库名、原始SQL片段。
怎么看报错信息里有没有SQL注入线索
关键不是看有没有报错，而是看报错里是否回显了数据库结构或执行上下文。比如 MySQL 报错中出现 Unknown column 'xxx' in 'where clause'，说明你输入的 'xxx' 被原样拼进了 SQL；PostgreSQL 报错里出现 syntax error at or near "xxx"，且 xxx 是你可控的输入，基本可以确认语句被截断重写了。
常见陷阱：有些系统会把报错 500 包装成“系统繁忙”，但后端其实吐了真实错误到日志——这时候要结合 Burp 抓包看响应体是否含 SQLSTATE、pg_query、mysql_fetch_array 等关键词，而不是只信前端提示。
- 开启开发者工具 Network 面板，过滤
text/html或application/json响应，重点扫error、message、trace字段 - 对疑似参数（如
id=1）尝试加单引号，观察是否返回You have an error in your SQL syntax类报错 - 不要只试
'，也试试"、')、" OR "1"="1，不同数据库/框架对引号处理差异很大
MySQL 和 PostgreSQL 报错差异怎么影响判断
MySQL 默认报错较直白，尤其是开启 sql_mode=STRICT_TRANS_TABLES 以外时，SELECT * FROM users WHERE id = '1' AND (SELECT 1 FROM information_schema.tables)='1' 这种会直接爆表名；PostgreSQL 更严格，多数语法错误会卡在解析阶段，报错像 ERROR: syntax error at or near "("，但一旦绕过解析（比如用 UNION SELECT 拼接合法子句），后续报错就可能泄露列数或类型。
一个典型区别：ORDER BY 注入在 MySQL 中可直接用 id=1 ORDER BY 2-- 看是否报错来猜列数；PostgreSQL 同样写法大概率报错，得换 id=1 ORDER BY (SELECT 2)-- 才能绕过解析检查。
- MySQL 常见报错关键词：
mysql_fetch_array、mysql_num_rows、Unknown column - PostgreSQL 常见报错关键词：
SQLSTATE、relation "xxx" does not exist、column "xxx" does not exist - SQL Server 报错更隐蔽，常含
Msg 102, Level 15, State 1, Line 1，需配合;分号尝试堆叠注入
为什么有时报错不显示，但其实能注入
因为应用层做了错误屏蔽，或者用了预编译但拼接了动态表名/字段名——这种场景下，id=1' AND SLEEP(3)-- 不会报错，但响应时间明显变长，说明 SQL 已执行。还有一种是布尔盲注：id=1' AND 1=1-- 返回正常页面，id=1' AND 1=2-- 返回空或跳转，说明后端逻辑依赖查询结果做分支判断。
别迷信报错，先确认输入是否进 SQL。方法很简单：改参数值为 id=1.1，如果返回空或 404，说明后端把它当数字强转了（可能防住了）；如果返回和 id=1 一样，说明没做类型校验，大概率拼接了字符串。
- 时间盲注优先用
SLEEP(1)（MySQL）、pg_sleep(1)（PostgreSQL）、WAITFOR DELAY '0:0:1'（SQL Server） - 布尔盲注建议用
AND (SELECT COUNT(*) FROM users)>0这类稳定判据，别用AND 1=1，有些 ORM 会优化掉恒真条件 - 注意 WAF 可能拦截
SLEEP、benchmark等函数名，可编码或大小写混用，比如slEEp(1)
报错信息里哪些字段最值得抓
不是所有报错都可信，优先盯住三类内容：数据库版本（如 MySQL 5.7.31）、当前数据库名（database(): xxx）、正在执行的 SQL 片段（Query: SELECT * FROM users WHERE id = '1''）。这些一旦回显，基本等于给了注入入口的地图。
特别注意那些看似无关的字段：比如 PHP 报错里的 mysqli_query() 调用栈、Java 的 org.hibernate.exception.SQLGrammarException，它们暴露的是底层驱动和 ORM 层级，能帮你判断能不能用 Hibernate HQL 注入或 MyBatis 动态 SQL 注入。
- 看到
mysqli_real_escape_string出现在报错里，说明用了旧式转义，\可能被绕过 - 看到
PreparedStatement但仍有报错，大概率是表名/字段名拼接导致的，预编译只防值，不防结构 - 报错里含
/var/www/html/xxx.php on line 42且该行调用了mysql_query($sql)，基本锁定漏洞位置
真正难的不是识别报错，而是区分这是开发环境遗留的调试开关，还是生产环境真没关严——很多系统只在 debug=false 时隐藏报错，但 SQL 仍按老逻辑拼接。所以别光看页面，得看请求实际走的是哪套配置。
