SQL注入日志如何研判

本文目录导读：

1. 关键特征识别（从日志中寻找“异常”）
2. 逻辑研判步骤（如何判断“是否是攻击”）
3. 误报排除（常见的非攻击情况）
4. 深度研判（实战分析示例）
5. 研判检查清单

研判SQL注入日志的核心是区分正常访问与恶意攻击行为，攻击者通常会利用Web应用未对用户输入进行充分过滤的漏洞,将恶意的SQL代码拼接到原有查询中。

以下是研判SQL注入日志的系统性方法，分为关键特征识别、工具辅助分析和误报排除三个维度。

关键特征识别（从日志中寻找“异常”）

当你查看访问日志或数据库审计日志时,重点寻找以下模式：

特殊的HTTP请求方法

• GET请求中的异常参数：?id=1'、?id=1 AND 1=1、?id=1 UNION SELECT...。
• POST请求体中的SQL关键字：如 username=admin'--、password=123' OR '1'='1。
• User-Agent或Referer头携带SQL：某些工具会将Payload藏在头部，例如User-Agent: Mozilla/5.0' OR '1'='1。

高频关键字与符号（核心特征）

日志中出现以下字符或关键词，几乎可以判定为SQL注入尝试（尤其是连续出现时）：

• SQL注释符：、、、。
• 恒真/假条件：1=1、1=2、'a'='a'、1=1--。
• UNION与联合查询：UNION SELECT、UNION ALL SELECT、NULL（用于判断字段数）。
• 特殊函数：@@version（数据库版本）、user()（当前用户）、database()、load_file()。
• 时间延迟函数：SLEEP(5)、WAITFOR DELAY '0:0:5'、BENCHMARK()。
• 报错注入语法：extractvalue()、updatexml()、EXP(~)、1' AND (SELECT 1 FROM (SELECT COUNT(*),...) ...)。
• 文件操作：INTO OUTFILE、INTO DUMPFILE、LOAD_FILE。
• 十六进制编码：0x...（如 0x61646D696E 代表 admin）。

异常的状态码与响应长度

• 状态码 200 + 大篇幅异常内容：攻击成功，可能返回了数据库表结构、账号密码等敏感信息。
• 状态码 500/404 + 特定Payload：盲注尝试（如时间注入、布尔注入）,服务器虽报错但攻击者在统计一页内容是否返回。
• 响应长度突变：对于同一个URL（如 ?id=1），正常返回200字节，当参数变为 ?id=1' 时返回500字或包含大量异常字符,高度可疑。

扫描器特征（自动化工具）

• 高频、连续、非人为的请求：同一IP在几秒内发送数十个不同参数值的请求（如 ?id=1, ?id=2, ?id=3，或者 ?id=1', ?id=1", ?id=1 AND 1=1）。
• 特定工具User-Agent：sqlmap、sqlmap/1.6、OWASP ZAP、Burp Suite、Nikto、Acunetix。
• 非标准HTTP版本：HTTP/1.0 或 HTTP/1.1 混杂。
• 参数名异常：某些扫描器会携带自定义参数如 ?q=1、?s=1（其实是在探测通用的注入点）。

逻辑研判步骤（如何判断“是否是攻击”）

不要只看单个请求，要结合上下文分析。

行为模式分析

• 常规访问链：正常用户：/index.html -> /product/1 -> /cart。
• SQL注入链：攻击者：/product?id=1 -> /product?id=1'（报错，确认注入） -> /product?id=1' UNION SELECT ...--（提取数据） -> /product?id=1' INTO OUTFILE ...（写shell）。
• 如果日志中出现连续的、递增的试探性请求（如上例）,基本可判定为恶意。

请求来源分析

• IP地址：是否来自已知的恶意IP库、Tor出口节点、国外IP（针对国内站）、数据中心IP（非家庭宽带）。
• 地理位置：与业务目标用户群体不符（如一个地方性政务网站被来自俄罗斯或美国的IP访问）。
• 请求时间：是否在非正常工作时间（如凌晨3点）发起大量请求。

白名单法

• 正常参数：?id=123（纯数字）。关键判断：对于参数 id，正常值应为数字，出现 、AND、OR 等字符，直接判定为恶意。
• 恶意参数：?id=123' OR '1'='1、?id=123 UNION SELECT...。

误报排除（常见的非攻击情况）

不是所有包含SQL关键字的请求都是攻击,需要排除以下情况：

1. 网站自身功能：
   • 搜索框：?q=O'Brien（包含单引号，但这是正常搜索姓氏）。
   • ?text=SELECT * FROM users（用户评论或文章中包含了SQL语句案例）。
2. 安全产品误判：CDN、WAF、IPS等设备可能对正常参数（如 ?name=tom 中的 tom 包含 1=1 的变体）产生误报。
3. 外部链接爬虫：某些SEO工具在抓取含SQL关键字的URL（如博客文章的示例代码）时,可能触发规则。
4. 开发测试流量：开发人员或测试人员的本地调试请求，如 ?debug=1、?id=test。

如何排除？

• 检查Referer：是否来自站内页面（如搜索框）。
• 检查URL路径：/blog/2023/SELECT 通常是文章URL,而非注入点。
• 检查：如果返回的是HTML、图片、JSON等正常业务数据，而非SQL语句错误或数据库信息,则可能是误报。

深度研判（实战分析示例）

一个真实的SQL注入日志条目：

2024-05-20 03:15:23 GET /product?id=1' AND (SELECT 1 FROM (SELECT COUNT(*), CONCAT((SELECT @@version),FLOOR(RAND()*2))x FROM information_schema.tables GROUP BY x)a) HTTP/1.1 
192.168.1.100 - - [20/May/2024:03:15:23 +0000] "GET /product?id=1' AND (SELECT 1 FROM (SELECT COUNT(*), CONCAT((SELECT @@version),FLOOR(RAND()*2))x FROM information_schema.tables GROUP BY x)a) HTTP/1.1" 200 5432
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36

研判过程：

1. 攻击特征：包含 AND (SELECT...、@@version（获取版本）、information_schema.tables（查询表）、FLOOR(RAND()*2)（双查询报错注入）。这是典型的报错注入Payload。
2. 行为模式：凌晨3点，针对单个参数 id,明显是自动化扫描或手动攻击。
3. IP与User-Agent：User-Agent伪装成了Chrome，但行为与正常用户不符（正常用户不会在凌晨3点发起这种长串恶意请求）。
4. 状态码与长度：返回200，长度为5432字节（可能包含报错信息或成功返回了版本号）。
5. 判定为恶意SQL注入攻击，且攻击者可能已经确认了注入点（因为返回了200）。

研判检查清单

最终行动建议：一旦确认日志条目为SQL注入攻击,应立即：

1. 封锁源IP：在WAF、防火墙或Web服务器上临时或永久封锁该IP。
2. 检查受影响范围：查看该IP是否访问过其他URL，以及该注入点是否成功返回了数据（响应长度异常）。
3. 审查代码：定位到对应的代码行（如 product?id=）,修复参数化查询或过滤。
4. 记录并追溯：保留日志作为证据,分析攻击者可能获取了哪些数据。

宁可误报，不可漏报，对于不确定的请求，可以先提升监控级别或手动验证,再决定是否封锁。