2026.7.31（3）【日志分析】2026CCF-被入侵的数据库

📌 题目信息

🛠️ 使用工具

• 文本编辑器 / 日志查看
• Python 3

📝 解题思路

题目给了一份 Web 中间件日志access.log（3677 行，Nginx/Apache 格式）。日志里有大量扫描噪音（404 探测），真正的攻击者是执行SQL 注入的源 IP。核心思路：从注入流量中找出攻击者 → 定位其提取数据库数据的语句 → 数据库名就写在FROM 库名.表名里。

第 1 步：识别 SQL 注入流量，锁定攻击者

先使用python脚本判断哪一个IP是访问量最多的。

import re from collections import Counter data = open('access.log', encoding='utf-8').readlines() ip_counter = Counter() for line in data: line = line.strip() # 去掉首尾空白 if not line: # 跳过空行 continue ip = line.split()[0] ip_counter[ip] += 1 print("=== 各 IP 访问量 Top10 ===") for ip, c in ip_counter.most_common(10): print(f"{ip}: {c}")

发现123.13.22.45、192.168.1.100这两个IP访问量最多，因此怀疑这两个IP的其中一个为攻击者。

先查看123.13.22.45的相关日志，发现这个IP在探测敏感路径，但考虑到这个IP的访问量有3167次，不可能是手工探测，因此推测为使用扫描器探测。

然后看192.168.1.100的相关日志，发现 192.168.1.100 在/test/login.php上发起大量 SQL 注入，因此判断攻击者为192.168.1.100（因为访问量只有189次，人类能做到，且题目名称有提到数据库，因此判定为攻击者）。

总结：123.13.22.45（扫描器）和192.168.1.100（注入攻击者）是主要流量；其中192.168.1.100 的请求全部是对/test/login.php的注入，是真正的攻击者。

⚠️注意：123.13.22.45访问量虽大（3167 次），但它是在探测/druid/sql.html、/dump、/heapdump等敏感路径（返回 404），属于信息收集/扫描，并没有成功注入拿到数据；而 192.168.1.100 是对 login.php 的实际 SQL 注入。

第 2 步：定位注入成功、提取数据的请求

通过查看日志，发现注入手法多样（UNION 联合注入、布尔盲注、时间盲注、EXTRACTVALUE 报错注入），最终攻击者成功读到了数据。

使用python脚本，筛选攻击者192.168.1.100的请求,URL 解码后需要匹配FROM 库名.表名结构,输出成功查询数据表的注入语句,从而定位数据库名。

import re from urllib.parse import unquote data = open('access.log', encoding='utf-8').readlines() # 只筛攻击者 IP 192.168.1.100 # 匹配 "FROM 库名.表名"（不区分大小写），并对整行做 URL 解码 pat = re.compile(r'FROM\s+\w+\.\w+', re.IGNORECASE) seen = set() # 用于去重 print("\n"+"注入语句中带\"FROM 库.表\"这个特征日志行如下："+"\n") for line in data: line = line.strip() if not line: continue ip = line.split()[0] if ip != '192.168.1.100': continue decoded = unquote(line) # URL 解码整行，还原 SQL 语句 if pat.search(decoded): if decoded in seen: # 去掉重复的注入请求 continue seen.add(decoded) print(decoded)

第 3 步：提取数据库名

注入语句中，数据表以库名.表名形式被引用：

• FROM login_db.secret→ 表secret
• FROM login_db.users→ 表users
  两者都隶属于同一个库：login_db。

⚠️注意：题目要的是数据库名，不是表名！login_db是库名，secret和users是库里的表。

攻击过程还原

1. 攻击者192.168.1.100对/test/login.php的用户名字段发起 SQL 注入
2. 通过 UNION / 报错 / 盲注确认存在注入点
3. 枚举information_schema找到数据库结构
4. 从login_db库的secret、users表提取敏感数据，造成泄露

🏁 最终 Flag

flag{login_db}