如何识别SQL注入迹象_分析应用服务器的访问日志

2次阅读

直接检查日志中 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 字符长、含大量括号和关键字，大概率是探测行为

关键不是看状态码（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 —— 因为注入几乎全在参数里

因为真实攻击者会刻意混淆特征：用双写绕过（如 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，而是区分“试探性扫描”和“已成功利用”的边界——后者往往没有日志回显，只能靠数据库侧异常连接、非预期表锁、或后续数据篡改痕迹反推。这点很容易被忽略。

发表于：数据库

近一天内