报错注入能直接获取数据库结构，因未捕获异常时数据库错误消息泄露表名、字段名等敏感信息，如“column 'user_name' does not exist”暴露users表及字段，为后续union或盲注提供关键情报。
数据库报错注入危害巨大，根本原因在于错误信息里直接泄露了表名、字段名、数据库版本甚至完整 SQL 语句结构——这些正是攻击者构造后续 UNION 或盲注攻击的弹药。
报错注入为什么能直接拿到数据库结构
当应用未捕获 SQL 异常，或错误页面直接输出 mysqli_error()、pg_last_error()、SQLException.getMessage() 等原始错误时，数据库会返回类似这样的内容：
ERROR: column "user_name" does not exist LINE 1: SELECT id, user_name, password FROM users WHERE ...
攻击者靠这个就能确认：表叫 users，字段有 id、user_name、password。再配合 UNION SELECT 就能直接拖库。
Miller CSV TSV JSON 数据处理器
下载
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
- MySQL 常见报错点：
extractvalue()、updatexml()、geometrycollection()，触发后错误消息里常带当前数据库名或字段名 - PostgreSQL 的
cast()或array_to_string()报错也容易回显结构 - SQL Server 的
convert()或name类型转换错误同样暴露元数据
全局异常处理器怎么真正隐藏细节
不是简单 catch 住异常就完事——关键在于不把原始数据库错误透出到 HTTP 响应体或前端页面中。
- Spring Boot 中，用
@ControllerAdvice+@ExceptionHandler(SQLException.class)捕获后，只返回统一 JSON：{"code":500,"msg":"系统繁忙，请稍后再试"}，绝不含getMessage()或getSQLState() - PHP Laravel 里，在
app/Exceptions/Handler.php的render()方法中判断$exception instanceof PDOException，然后返回 500 页面但不输出$exception->getMessage() - Node.js Express 下，中间件里用
if (err.code === '23505') {...}这类具体错误码做分支处理，避免把err.stack或err.detail写进res.send()
容易被忽略的“伪隐藏”陷阱
很多团队以为关掉 display_errors = Off 或设置 debug = False 就安全了，其实远远不够。
- 日志文件里还在狂写完整错误堆栈？攻击者若能读取日志（比如通过路径遍历或 SSRF），等于白设
- HTTP 响应头里还带着
X-Powered-By: PHP/8.2.12或Server: Apache/2.4.52？这会帮攻击者精准匹配已知 CVE - 前端控制台 Network 面板里，接口返回的 500 响应体是空的，但响应头
X-Debug-Info却悄悄塞了 SQL 片段？这类自定义 header 常被遗忘清理
真正的隐藏，是让攻击者连“这里用了什么数据库、哪个字段不存在”都猜不出来——所有错误走同一通道，且响应体、响应头、日志三处全部脱敏。
