SQL注入日志如何研判

本文目录导读：

1. 基础筛选：识别SQL注入特征
2. 深度分析：区分“探测”与“攻击”
3. 关联分析：扩大研判范围
4. 用户端（客户端）研判要点（面向甲方安全人员）
5. 高效研判三步骤
6. 常见误判与注意事项

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

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

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

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

1. 关键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。

2. 非常规的HTTP方法：虽然GET是最常见的，但POST请求体中的数据也需要检查。

3. 异常的编码：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')--。
  • 响应中返回了文件内容。
  • 非常严重,可能导致服务器被控制。

关联分析：扩大研判范围

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

1. 源IP分析：

   • 频率：同一个IP在短时间内（如1分钟内）发送了大量包含SQL关键字的请求（通常是扫描器行为，如100个/分钟）。
   • 来源：是否来自境外、Tor出口节点、或已知的恶意IP库。
   • 地理分布：正常用户很少在短时间内从多个不同国家/地区发起请求。

2. 请求路径分析：

   • 攻击的是否是明确存在的URL和参数（如 product.php?id=）？还是随机扫描不存在的文件（如 php?id=）？
   • 是否对后台管理系统（/admin/、/login/）进行注入？

3. 响应状态码分析：

   • 200：攻击尝试且请求成功处理，但可能是盲注。
   • 403/500：WAF拦截或服务器内部错误，说明攻击产生了效果或破坏了正常逻辑。
   • 302：可能触发了重定向，但请求仍在执行。
   • 重点关注响应包大小：如果发送AND 1=1和AND 1=2时，返回的页面大小完全一致（或完全不一致），是布尔盲注的重要特征。

4. User-Agent分析：

   • 常见的Python Requests、Go-http-client、Wget等UA，表明可能是自动化工具，而非正常浏览器。
   • 如果UA是真实浏览器（如Chrome 120），则需结合其他特征。

用户端（客户端）研判要点（面向甲方安全人员）

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

高效研判三步骤

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

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

常见误判与注意事项

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

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