直接检查日志中GET/POST参数是否含SQL注入特征，需结合解码、行为分析与多层日志（如WAF、MySQL通用日志）交叉验证，避免仅依赖关键词匹配。
怎么看日志里藏着的 SQL 注入尝试
直接看 GET 或 POST 请求参数里有没有明显违反业务逻辑的 SQL 片段，比如 ' OR '1'='1、UNION SELECT、SLEEP(5) 这类。不是所有注入都带空格或分号，有些会 URL 编码、大小写混用、用注释符绕过 WAF，所以不能只靠肉眼扫关键词。
实操建议：
- 用
grep -i扫描日志：比如grep -i "union.*select\|sleep(\|benchmark(\|information_schema" access.log - 注意编码变形：
%27%20OR%20%271%27%3D%271就是' OR '1'='1的 URL 编码，得先解码再判断，或者用支持正则解码的工具（如awk配合urldecode函数） - 关注异常长度参数：比如一个本该是手机号的字段，值却是 200 字符长、含大量括号和关键字，大概率是探测行为
Apache / Nginx 日志里哪些字段最值得盯
关键不是看状态码（200 不代表安全，500 反而更可疑），而是看原始请求行和参数还原后的上下文。Nginx 默认 $request_uri 不包含 query string 解码后的内容，Apache 的 %q 也不自动解码，容易漏掉伪装请求。
实操建议：
- 确保日志格式记录了完整未解码的请求行：
log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent"'; - 对 POST 请求，原始 body 不在默认 access log 里，需用
mod_security（Apache）或nginx-module-vts+ 请求体捕获（Nginx）额外记录，否则会漏掉大量基于 POST 的注入 - 重点比对
$args（Nginx）或%{QUERY_STRING}e（Apache）字段，而不是只看$uri—— 因为注入几乎全在参数里
为什么简单 grep 容易误报也容易漏报
因为真实攻击者会刻意混淆特征：用双写绕过（如 SELSELECTECT）、用注释隔开（UNI/**/ON）、用内联注释（/*!50000SELECT*/）、甚至用十六进制编码（0x756e696f6e）。而正常业务也可能触发类似字符串，比如搜索词含单引号、用户昵称叫 “Union”。
实操建议：
- 别单独依赖字符串匹配，结合行为模式：比如同一 IP 在 1 秒内发 5 条带
ORDER BY且数字递增的请求（ORDER BY 1→ORDER BY 2），基本就是列数探测 - 注意时间盲注痕迹：连续请求中，URL 参数变化极小，但响应延迟明显拉长（如从 20ms 突增至 5s），且延迟与布尔条件强相关（
IF(1=1,SLEEP(5),0)） - 用
awk统计参数键名出现频次：高频非常规键（如id1、p、q）+ 高频特殊值，比单条匹配更可靠
应用层没打日志时，怎么从服务器层面补救
如果应用本身没记录原始请求参数（比如只记了处理后的 ID），就得退到系统层抓包或用审计模块兜底。这时候别指望日志分析，得换思路。
实操建议：
- 临时启用 MySQL 的
general_log（仅限排查期）：SET GLOBAL general_log = 'ON'; SET GLOBAL general_log_file = '/tmp/mysql-general.log';，然后 grep 里面执行的语句，但注意性能损耗大、磁盘爆满风险高 - 用
tcpdump抓应用到数据库的流量（假设走 TCP）：tcpdump -i lo -A -s 0 port 3306 | grep -i "select.*from\|union.*select"，适合短时定位，不持久 - 检查 Web 服务器是否启用了
mod_security或nginx_waf规则，它们的拦截日志（如SecAuditLog）往往比 access log 更早、更准地暴露注入意图
真正难的不是识别单个 payload，而是区分“试探性扫描”和“已成功利用”的边界——后者往往没有日志回显，只能靠数据库侧异常连接、非预期表锁、或后续数据篡改痕迹反推。这点很容易被忽略。
