SQL注入攻击日志分析与防御实战

发布时间：2026/10/29 23:11:01

1. 日志分析场景还原与攻击特征识别

看到这组日志记录时，我的第一反应是遇到了典型的SQL注入探测行为。172.16.12.1这个内网IP在2018年1月22日15:05:05这个时间点（注意时区是东八区），对/index.php接口发起了密集的GET请求，所有请求都带有相同的恶意参数构造：

productid=1%20and%20(SELECT%201%20from%20cfreer)

URL解码后实际是productid=1 and (SELECT 1 from cfreer)，这是经典的SQL注入探测手法。攻击者通过and连接一个子查询，测试目标是否存在SQL注入漏洞。cfreer这个表名看起来像是随机生成的，可能是攻击工具自动填充的占位符。

关键发现：所有请求的HTTP状态码都是200，响应大小固定为1085字节。这说明服务器正常响应了这些恶意请求，没有触发任何防护机制，存在严重安全隐患。

2. 攻击流量深度解析

2.1 HTTP请求结构拆解

日志中的请求格式符合Apache的Combined Log Format：

客户端IP：172.16.12.1
时间戳：[22/Jan/2018:15:05:05 +0800]
请求行：GET /index.php?m=product&s=admin/product_list&productid=1%20and%20(SELECT%201%20from%20cfreer) HTTP/1.1
状态码：200
响应大小：1085字节
Referer：-（空）
User-Agent：Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0

2.2 注入语句技术分析

攻击payload可以分解为三个技术点：

参数拼接：productid=1是正常参数，后面的and是SQL关键字
子查询探测：(SELECT 1 from cfreer)测试是否允许执行子查询
表名探测：cfreer很可能是随机生成的表名，用于测试系统反应

这种手法的危险之处在于：

如果应用没有过滤就直接拼接SQL，会形成完整查询：SELECT * FROM products WHERE productid=1 and (SELECT 1 from cfreer)
当cfreer表不存在时，不同数据库的反应：
- MySQL：报错"Table 'xxx.cfreer' doesn't exist"
- PostgreSQL：报错"relation "cfreer" does not exist"
- SQL Server：报错"Invalid object name 'cfreer'"

3. 防御方案设计与实施

3.1 即时应对措施

发现此类日志后应立即：

封禁攻击源IP：iptables -A INPUT -s 172.16.12.1 -j DROP
检查数据库日志确认是否执行了恶意SQL
审计product_list接口的代码

3.2 长期防护策略

防护层级	具体措施	实施示例
应用层	参数化查询	使用PDO::prepare()绑定参数
网络层	WAF规则	配置ModSecurity过滤SQL关键词
系统层	日志监控	部署ELK+Suricata实时告警
架构层	API网关	在Kong上配置参数格式校验

3.3 代码修复示例

原始危险代码：

$productId = $_GET['productid']; $sql = "SELECT * FROM products WHERE id = " . $productId;

修复后的安全代码：

$stmt = $pdo->prepare("SELECT * FROM products WHERE id = :id"); $stmt->execute([':id' => $_GET['productid']]);

4. 日志分析进阶技巧

4.1 自动化检测脚本

用Python实现简单的注入检测：

import re from urllib.parse import unquote def detect_sqli(log_line): decoded = unquote(log_line) patterns = [ r'\bSELECT\b.*\bFROM\b', r'\bUNION\b.*\bSELECT\b', r'\bAND\b.*\(.*\)' ] return any(re.search(p, decoded, re.I) for p in patterns)