自动化扫描器依赖错误信息，是因为它们通过诱导数据库报错来确认注入点并提取敏感数据，如表名、字段名和版本号，进而自动生成后续payload；需同时关闭pdo的errmode和mysqli的report开关，并严格禁用框架debug模式以防错误泄露。
为什么自动化扫描器依赖错误信息
OWASP ZAP、sqlmap 这类工具不是靠猜，而是靠“诱导报错”来确认注入点。比如发一个 ' OR SLEEP(1)--，如果响应延迟，说明语句被执行；再发一个 ' AND (SELECT 1 FROM information_schema.tables WHERE table_name='users')--，如果返回 ERROR 1146 (42S02): Table 'test.users' doesn't exist，就直接拿到了表名。错误消息里带的 users、information_schema.tables、甚至 MySQL 版本号，都是它们自动构建后续 payload 的依据。
PDO 和 MySQLi 必须关掉的两个开关
只关 display_errors = Off 不顶用——驱动层还在往外吐 SQL。必须同步改两处：
-
PDO::ATTR_ERRMODE => PDO::ERRMODE_SILENT（不能是ERRMODE_EXCEPTION） -
mysqli_report(MYSQLI_REPORT_OFF)（别用MYSQLI_REPORT_STRICT，老项目常踩这个坑）
示例（PDO）：
$pdo = new PDO($dsn, $user, $pass, [
PDO::ATTR_ERRMODE => PDO::ERRMODE_SILENT,
PDO::ATTR_EMULATE_PREPARES => false,
]);
框架层 debug 模式是最大漏网之鱼
很多团队调好了 PHP 配置，上线后还是被扫出表名，问题出在框架没关 debug：
- Flask：确保
debug=False，且加全局异常捕获：@app.errorhandler(Exception)返回泛化提示 - Django：
DEBUG = False+ALLOWED_HOSTS = ['yourdomain.com']（空列表或未设会导致 500 堆栈照常泄露） - Laravel：
APP_DEBUG=false必须生效，检查.env和config/app.php是否被覆盖
哪怕只有一处没关严，sqlmap 发个 ?id=1' 就能拿到完整 traceback，含原始 SQL、表名、字段名、路径。
验证是否真关严了的实操方法
别只测首页 404，要主动触发数据库错误：
- 构造一个必然失败的查询，如
?id=1' AND 1=(SELECT COUNT(*) FROM nonexistent_table)-- - 观察响应体：应是纯前端 HTML 或 JSON 错误（如
{"error": "Internal server error"}），绝不能含Unknown column、Table 'xxx' doesn't exist等字样 - 用 curl 查响应头：
curl -I http://yoursite/api/user?id=1'，确认没有X-Powered-By: PHP/8.2.0这类泄露服务端细节的 header
真正难防的不是攻击者多聪明，而是你漏掉了一个 ini_set('display_errors', '1') 在某个中间件里，或者某条日志语句把 $e->getMessage() 直接写进了 response body。
