SQL注入本身不直接导致CPU或内存飙升，但错误注入扫描会高频触发数据库报错、日志写入和连接堆积，间接引发负载异常；其通过'、"、1' OR '1'='1等payload诱导结构化错误，使SQL解析编译报错开销增3–5倍，频繁写入错误日志，并耗尽连接池造成雪崩。
SQL注入本身不会直接导致服务器CPU或内存飙升，但基于错误的注入扫描会高频触发数据库报错、日志写入和连接堆积，间接引发负载异常。
为什么错误注入扫描会让数据库CPU和连接数暴涨
攻击者用 '、"、1' OR '1'='1 这类 payload 发起大量请求，目的不是拿数据，而是诱导数据库返回结构化错误信息（比如 PostgreSQL 的 ERROR: syntax error at or near "xxx" 或 MySQL 的 You have an error in your SQL syntax）。这类行为会：
- 每次触发都走完整 SQL 解析 → 编译 → 报错路径，比正常查询开销高 3–5 倍
- 数据库频繁写入错误日志（尤其未关闭
log_error_verbosity或log_statement = 'all'时） - 应用层若未设连接超时或复用池限制，会快速耗尽连接数，新请求排队等待，形成雪崩
- WAF 或中间件若仅做关键词匹配（如拦截
UNION SELECT），对单引号类基础 payload 无感，放行后全压到 DB
如何从 Nginx/Apache 日志里快速识别错误注入扫描
别等告警——直接查 access log 中高频、低价值、带典型错误特征的请求。重点关注：
- URL 中含
'、"、/*、--、%27（URL 编码单引号）且状态码为500或503 - 同一 IP 在 1 分钟内发起 ≥10 次含
error、syntax、unexpected等关键词的GET请求 - Referer 或 User-Agent 为空、极简（如
-或sqlmap）或含测试工具指纹（sqlmap/、havij）
示例命令（Linux）：
awk '$9 ~ /^50[03]$/ && $7 ~ /%27|\'/ {print $1}' access.log | sort | uniq -c | sort -nr | head -20在 Web 层拦截错误注入的实操配置
靠应用代码补漏太慢，优先在反向代理或 WAF 层做前置过滤。以下配置可立即生效：
- Nginx：用
map+if拦截 URL 中的危险字符（注意：不推荐在location外用if，此处仅针对 query string） - Apache：启用
mod_security并加载 OWASP CRS 规则集，重点开启REQUEST-942-APPLICATION-ATTACK-SQLI - 云 WAF（如 Cloudflare、阿里云 WAF）：开启「SQL 注入防护」+「错误信息泄露防护」，并把规则动作设为「阻断」而非「观察」
关键点：必须同时拦截 %27（编码单引号）和原始 '，否则绕过率超 60%；只拦 SELECT 或 UNION 对错误注入完全无效。
数据库侧必须关闭的危险配置
即使前端拦住了 99% 的扫描，数据库自身若暴露过多信息，一次漏网请求就能让攻击者拿到表名、字段名。立刻检查并禁用：
- PostgreSQL：
log_error_verbosity = default（不要设为verbose），show_subclass = off - MySQL：
sql_mode中移除STRICT_TRANS_TABLES不是问题，但必须关掉log_warnings = 2和general_log = ON - 所有数据库：禁止应用账号执行
SHOW TABLES、SELECT * FROM pg_tables等元数据查询（最小权限原则）
真正容易被忽略的是：错误注入扫描往往不触发传统 WAF 的 SQLi 规则，因为它根本没拼出完整恶意语句，只是用语法错误“试探”。防御成败，取决于你是否把 ' 和 %27 当作一级威胁来处理，而不是等它变成 UNION SELECT version() 才响应。
