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
- 修复建议:
- 添加 API Token 认证(预共享密钥,所有调用需携带
_auth 字段)
- SELECT 强制添加 LIMIT 上限(默认 1000 条),防止拖库
- 添加操作权限:日志写入只允许 insert,禁止 delete/truncate
- 拒绝无条件 UPDATE/DELETE(必须带 where 条件)
- DDL 操作仅限本地运维工具,RPC 接口完全禁用
🟠 P1 — 高危问题
| # |
问题 |
说明 |
| P1-1 |
db_tools.py 运维工具存在 SQL 字符串拼接风险 |
运维脚本中可能使用字符串拼接构建 SQL |
| P1-2 |
无操作审计日志 |
谁在什么时候修改了什么数据无独立审计记录 |
| P1-3 |
Logs 表自动清理可被利用销毁证据 |
攻击者可通过触发大量日志加速清理,删除攻击痕迹 |
🟡 P2 — 中危问题
| # |
问题 |
| P2-1 |
日志表自动清理的保留策略可配置化(目前硬编码 30天/100万条) |
| P2-2 |
错误信息可能泄露表结构/字段名给调用方 |
✅ 已有安全机制
- ✅ SQLAlchemy Core 参数化查询:核心 CRUD 路径使用表反射 + 参数化,零 SQL 注入风险
- ✅ 仅监听 127.0.0.1:不对外暴露
- ✅ 集中式日志 fail-safe:db 不可用时静默丢弃,不阻塞业务
- ✅ 自动提交/回滚:异常时自动回滚事务
- ✅ 日期/时间适配:ISO 8601 处理,
"$now" 哨兵
- ✅ 日志自动清理:后台线程每小时清理,防止磁盘占满
- ✅ log_client 健壮性:异步队列、后台线程、fail-safe、队列上限(从各服务副本)
修复路线图
立即(24小时)
短期(72小时)
中期