从访问日志里揪出可疑请求
做网站运维的朋友应该都清楚，每天服务器日志都会记录成千上万条访问请求。大多数是正常浏览，但也可能藏着恶意试探。比如有人在URL里塞一堆奇怪字符，像单引号、or 1=1、union select这类关键字，很可能就是冲着数据库来的。
举个例子，你在Nginx的access.log里看到这样一条记录：
192.168.3.10 - - [15/Apr/2025:14:22:33 +0800] "GET /product.php?id=1' OR '1'='1' HTTP/1.1" 200 1245 "-" "Mozilla/5.0"这个id参数明显不正常，用单引号闭合前面的SQL语句，再拼接永真条件，目的就是绕过查询限制。这种写法在手工注入中非常常见。
关注响应码和返回长度异常
攻击者测试时往往不会一次成功，他们会不断调整payload。这时候你会发现同一IP短时间内频繁请求相似路径，且返回状态码忽变。比如正常页面返回200但数据为空，或者突然报500错误，这可能是构造的SQL语句导致后端数据库报错。
更隐蔽的是盲注行为。攻击者看不到直接回显，会通过if语句或sleep函数判断逻辑真假。比如出现这样的请求：
GET /user.php?uid=1 AND SLEEP(5) HTTP/1.1如果这条请求响应明显比正常的慢几秒，基本可以判定对方正在探测时间盲注漏洞。
利用SQL关键字组合过滤日志
手动翻日志效率低，可以用grep配合常见关键字快速筛查。比如在Linux下执行：
grep -i \"\' OR \|UNION\|SELECT\|DROP\|INSERT\|LOAD_FILE\|SLEEP\|BENCHMARK\" access.log这条命令能筛出包含典型SQL语法的日志行。当然要注意误报，比如有些正常搜索功能也会带“select”字样，得结合上下文判断。
注意编码变形和绕过手法
现在的攻击者越来越狡猾，会用URL编码、双写、注释符等方式躲检测。比如把单引号写成%27，或者把union写成uni%6fn。还有的会在关键字中间插/**/之类的注释块，像：
GET /news.php?id=1 UNION/**/SELECT/**/1,username,password FROM/**/users这种请求看起来被拆开了，但数据库解析时仍会执行原意。查日志时得留意这类“伪装”模式。
建议定期跑脚本分析日志，把高频异常参数、特定语法组合、响应延迟等指标做成可视化报表，便于及时发现问题请求。