SQL注入日志如何研判

wen 开源项目 2026-06-30 29

本文目录导读：

SQL注入日志如何研判

研判SQL注入日志,核心在于区分正常访问与恶意攻击，并评估攻击的有效性与影响，这需要结合日志中的请求参数、响应状态、时间窗口、IP行为等多个维度进行分析。

以下是系统化的研判思路和步骤：

基础筛选：识别SQL注入特征

在日志中过滤出可疑的请求,常见特征包括：

关键SQL关键字：
- 单引号（）：最基本的闭合测试。
- SQL注释符：、、。
- UNION：UNION SELECT、UNION ALL SELECT。
- 逻辑判断：OR 1=1、AND 1=2、OR '1'='1'。
- 系统函数：DATABASE()、USER()、VERSION()、@@version、@@datadir。
- 报错注入：updatexml、extractvalue、floor(rand(0)*2)、convert、count(*)。
- 时间盲注：SLEEP(5)、WAITFOR DELAY '0:0:5'。
- 布尔盲注：if(1=1,1,0)、ascii(substr(...))。
- 读写文件：INTO OUTFILE、INTO DUMPFILE、LOAD_FILE。
非常规的HTTP方法：虽然GET是最常见的，但POST请求体中的数据也需要检查。
异常的编码：URL编码后的一长串字符（如 %27%20OR%201%3D1%20--%20），或混合了Unicode编码、二次编码。

工具推荐：可以使用grep、awk等命令行工具，或Splunk、ELK等日志分析平台，编写规则匹配上述关键字。

不是所有包含SQL关键词的请求都是真正的攻击,需要根据上下文研判：

包含特殊字段：某些系统参数名或内容可能包含SQL关键词，username=admin'、password=1'2'3、like='%abc%'。
测试环境：来自内部测试IP的请求。
扫描器特征：常见扫描器（如AWVS、SQLMap、Nessus）在User-Agent头部有明显特征，但攻击者会修改，不可全信。

关键看：攻击者是否改变了请求参数，并观察返回结果。

单点测试（探针）：
- 请求 ?id=1'，返回了500错误或数据库报错信息（如 MySQL error: You have an error in your SQL syntax...）。
- 高危,几乎可以确认存在SQL注入点。
布尔盲注（探针）：
- 请求 ?id=1 AND 1=1 -> 返回正常。
- 请求 ?id=1 AND 1=2 -> 返回空白或报错。
- 高危,存在布尔注入点。
时间盲注（探针）：
- 请求 ?id=1 AND SLEEP(5) -> 服务器响应延迟明显超过5秒。
- 高危,存在时间盲注点。
报错注入（攻击）：
- 请求 ?id=1 AND updatexml(1,concat(0x7e,(SELECT user()),0x7e),1)--。
- 响应中直接暴露了数据库用户名（如 ~root@localhost~）。
- 攻击成功,数据已泄露。
UNION查询（攻击）：
- 请求 ?id=-1 UNION SELECT 1,2,3,table_name FROM information_schema.tables--。
- 响应中页面显示了 1,2,3,users 等数据。
- 攻击成功,表结构已经泄露。
文件读取/写入（高危）：
- 请求 ?id=1' UNION SELECT LOAD_FILE('/etc/passwd')--。
- 响应中返回了文件内容。
- 非常严重,可能导致服务器被控制。

单条日志不够,需要看“人”和“时间”：

源IP分析：
- 频率：同一个IP在短时间内（如1分钟内）发送了大量包含SQL关键字的请求（通常是扫描器行为，如100个/分钟）。
- 来源：是否来自境外、Tor出口节点、或已知的恶意IP库。
- 地理分布：正常用户很少在短时间内从多个不同国家/地区发起请求。
请求路径分析：
- 攻击的是否是明确存在的URL和参数（如 product.php?id=）？还是随机扫描不存在的文件（如 php?id=）？
- 是否对后台管理系统（/admin/、/login/）进行注入？
响应状态码分析：
- 200：攻击尝试且请求成功处理，但可能是盲注。
- 403/500：WAF拦截或服务器内部错误，说明攻击产生了效果或破坏了正常逻辑。
- 302：可能触发了重定向，但请求仍在执行。
- 重点关注响应包大小：如果发送AND 1=1和AND 1=2时，返回的页面大小完全一致（或完全不一致），是布尔盲注的重要特征。
User-Agent分析：
- 常见的Python Requests、Go-http-client、Wget等UA，表明可能是自动化工具，而非正常浏览器。
- 如果UA是真实浏览器（如Chrome 120），则需结合其他特征。

当你监控日志时,可以按以下优先级判断严重程度：

风险等级	典型特征	响应建议
严重	请求返回了数据库数据（表名、字段、用户密码、文件内容）。	立即阻断IP、下线漏洞页面、检查日志确认泄露范围、强制修改相关数据库密码。
高危	通过探针确认了注入点（如时间盲注明显延迟、返回了明显的数据库报错）。	立即封锁IP、对相关代码进行修复（使用参数化查询）。
中危	发现大量自动化扫描请求，但未产生有效注入（所有请求均返回正常/统一错误页，或WAF拦截）。	对IP进行临时或永久封禁、完善WAF规则。
低危	单次、非连续的探针请求（如 `?id=1'`），响应内容正常。	记录日志，持续观察该IP后续行为。

为了方便记忆,可以采用三分法：

分：将日志按时间、源IP、目标URL分组。
看：看每个组里，请求参数是否接近于单个SQL片段（如 1'、1 AND 1=1、sleep(5)），并且响应结果有明显变化（时间、长度、内容）。
定：根据上述变化，判定是探针还是数据窃取，并确认是否已经成功执行了查询（如返回了数据）。

编码问题：正常的用户输入中，也可能包含或（如搜索 O'Brien），需要结合上下文判断，不要单凭字符识别。
WAF误判：WAF日志中的blocked或forbidden事件是攻击尝试，但不一定是有效攻击，真正的研判要看绕过WAF后的日志。
自动化工具区别：SQLMap的Request通常与浏览器完全不同（头部顺序、Cookie、Accept-Language等），可以快速识别。
横向对比：如果多条不同源IP的日志针对同一个URL使用类似攻击手法，可能是分布式扫描，需重点排查该URL是否存在漏洞。

最终结论：不要只看关键字，要对比请求与响应的因果关系，一条真的SQL注入日志，能明显看出攻击者在“猜”和“验证”的过程。