应优先分析access.log中的异常get参数，关注sql片段特征、url编码痕迹、高频自动化扫描、盲注隐性特征、可疑user-agent及referer/cookie/post体中的注入线索，并通过关联分析确认攻击链。
直接看 access.log 里的异常 GET 参数
SQL注入流量绝大多数走 HTTP GET，所以第一眼就盯 access.log，别先翻 error.log 或数据库日志。重点不是“有没有报错”，而是“参数长得像不像 SQL 片段”。
- 搜
id=1' OR '1'='1、id=1 AND SLEEP(5)、id=1 AND (SELECT COUNT(*) FROM information_schema.tables)>0这类明显带逻辑运算或函数调用的参数值 - 注意 URL 编码痕迹：
%27（单引号）、%3B（分号）、%20（空格）连续出现多次，尤其夹在数字和字母之间时，大概率是绕过 WAF 的编码注入 - 同一 IP 在 1 分钟内发起 20+ 次含
UNION、EXTRACTVALUE、UPDATEXML的请求，基本可判定为自动化扫描器行为
识别布尔盲注和时间盲注的隐性特征
这类注入不触发报错也不回显数据，但会在日志里留下“响应时间异常 + 参数高度结构化”的组合痕迹。
- 响应状态码全是
200，但响应时间集中在4980ms、5020ms这类接近 5s 的值，且参数含SLEEP(5)或BENCHMARK(1000000,MD5(1))，就是时间盲注 - 同一 IP 轮询访问
?id=1 AND LENGTH(database())=1、?id=1 AND LENGTH(database())=2……直到某次响应内容明显不同（比如多了一行 HTML），这是布尔盲注在逐字猜解 -
User-Agent字段是python-requests、sqlmap或空白，比Mozilla/5.0更值得警惕
别忽略 Referer、Cookie 和 POST body 日志
现代注入越来越多藏在非 URL 参数里，尤其当 WAF 对 GET 做了强规则后。
- 检查日志是否记录了
Referer：攻击者常把 payload 放进 Referer 头绕过前端过滤，如Referer: http://evil.com/' AND 1=1-- - 确认
Cookie字段是否被完整记录：有些 CMS 登录态校验逻辑会从 Cookie 取值拼 SQL，日志里若出现auth_token=xxx' OR '1'='1就是典型线索 - 如果启用了
mod_security或 Nginx 的log_format包含$request_body，直接 grepINSERT INTO|SELECT.*FROM|DROP TABLE—— POST 提交的恶意 SQL 往往比 GET 更直白
关联分析比单条日志更有说服力
单看一条可疑请求容易误判，真正有效的溯源靠的是横向串联。
- 拿到可疑 IP 后，立刻查它在同一时间段是否还访问过
/phpmyadmin/、/webshell.php、/upload.php—— 这说明不是试探，而是已进入提权阶段 - 对比防火墙日志：如果该 IP 的 TCP 连接数突增，且目标端口是 3306（MySQL）或 1433（MSSQL），基本坐实数据库层攻击行为
- 检查 Web 服务器是否开启
LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\" \"%{Cookie}i\""—— 没记录 Cookie 和 Referer 的日志，对 UA 注入、Cookie 注入类攻击完全失明
日志字段是否全量采集，决定了你能看到攻击链的哪一环。很多团队卡在“发现不了注入”，其实不是没发生，是日志根本没记全。
