micro_servers/docs/security/db_SECURITY_AUDIT_20260801.md

db 模块安全审计报告

审计日期: 2026-08-01
审计范围: dbv2.py、db_tools.py、log_client 相关
代码版本: dev_qing 分支

---

修复进度

优先级	总数	已修复	待修复
P0	1	0	1
P1	3	0	3
P2	2	0	2

---

🔴 P0 — 严重问题

P0-1: 零认证对外开放完整 CRUD（依赖 127.0.0.1 网络隔离）

• 位置: dbv2.py RpcServer
• 问题:
  • 完全没有认证机制
  • 任何能访问 8005 端口的本地进程/用户都可执行任意 select/insert/update/delete
  • 可读取 Users 表密码哈希、Logs 表所有日志
  • SELECT 无 limit 上限，可被拖库
  • 无表级/操作级权限控制
• 当前缓解: 默认监听 127.0.0.1，Docker 也绑定到 127.0.0.1
• 修复建议:
  1. 添加 API Token 认证（预共享密钥，所有调用需携带 _auth 字段）
  2. SELECT 强制添加 LIMIT 上限（默认 1000 条），防止拖库
  3. 添加操作权限：日志写入只允许 insert，禁止 delete/truncate
  4. 拒绝无条件 UPDATE/DELETE（必须带 where 条件）
  5. DDL 操作仅限本地运维工具，RPC 接口完全禁用

---

🟠 P1 — 高危问题

#	问题	说明
P1-1	db_tools.py 运维工具存在 SQL 字符串拼接风险	运维脚本中可能使用字符串拼接构建 SQL
P1-2	无操作审计日志	谁在什么时候修改了什么数据无独立审计记录
P1-3	Logs 表自动清理可被利用销毁证据	攻击者可通过触发大量日志加速清理，删除攻击痕迹

---

🟡 P2 — 中危问题

#	问题
P2-1	日志表自动清理的保留策略可配置化（目前硬编码 30天/100万条）
P2-2	错误信息可能泄露表结构/字段名给调用方

---

✅ 已有安全机制

1. ✅ SQLAlchemy Core 参数化查询：核心 CRUD 路径使用表反射 + 参数化，零 SQL 注入风险
2. ✅ 仅监听 127.0.0.1：不对外暴露
3. ✅ 集中式日志 fail-safe：db 不可用时静默丢弃，不阻塞业务
4. ✅ 自动提交/回滚：异常时自动回滚事务
5. ✅ 日期/时间适配：ISO 8601 处理，"$now" 哨兵
6. ✅ 日志自动清理：后台线程每小时清理，防止磁盘占满
7. ✅ log_client 健壮性：异步队列、后台线程、fail-safe、队列上限（从各服务副本）

---

修复路线图

立即（24小时）

• SELECT 添加强制 LIMIT 上限（防止拖库）

短期（72小时）

• 添加 API Token 认证
• 无条件 UPDATE/DELETE 拒绝执行
• 错误信息脱敏

中期

• 表级权限控制（日志表只写不删/改）
• 管理操作审计日志