139 lines
5.5 KiB
Markdown
139 lines
5.5 KiB
Markdown
# 安全审计补充记录（2026-03-12）
|
||
|
||
审计范围：后端权限边界、文件与归档处理链路、部署敏感资产暴露情况。
|
||
审计方式：静态只读审计，本文档仅记录结论与建议，不包含代码修复。
|
||
审计前提：当前环境为开发机，目标部署环境为私有内网；授权签发材料与初始化密码当前因封装方式不足，仍位于开发目录中。
|
||
|
||
## 1. 本次审计的判断口径
|
||
|
||
本次记录将问题分为两类：
|
||
|
||
1. 开发阶段可解释、但上线打包时必须隔离的运维/交付风险。
|
||
2. 与部署环境无关、进入内网后仍然成立的代码级安全缺陷。
|
||
|
||
这一区分的目的，是避免把“开发机上的临时暴露”与“真正需要修代码的问题”混为一谈。
|
||
|
||
## 2. 开发机阶段的可解释暴露
|
||
|
||
以下内容在当前“开发机 + 私有内网 + 尚未完成封装”的前提下，可以暂时理解为运维接受项；但它们不应进入最终部署包、客户现场机器、共享目录或备份集。
|
||
|
||
### 2.1 授权签发私钥与签发工具位于项目目录
|
||
|
||
- 证据：
|
||
- `license-issuer/issue_license.py`
|
||
- `license-issuer/private_key.b64`
|
||
- `backend/app/license_service.py`
|
||
- `license-issuer/README.md`
|
||
- 说明：
|
||
- 当前目录同时包含授权验证逻辑和签发私钥材料。
|
||
- 在开发阶段这可以理解为便于调试和现场签发。
|
||
- 但从交付角度看，签发端与验证端必须物理隔离。
|
||
- 当前结论：
|
||
- 在开发机上记录为“运维接受项”。
|
||
- 在上线交付前必须从部署物中彻底移除。
|
||
|
||
### 2.2 `.env` 中包含初始化管理员密码
|
||
|
||
- 证据：
|
||
- `.env`
|
||
- `scripts/init_db.py`
|
||
- `README.md`
|
||
- 说明：
|
||
- 初始化脚本会读取 `INIT_ADMIN_PASSWORD` 用于创建或重置管理员。
|
||
- 这在开发期、首次部署准备期可以理解为简化初始化流程。
|
||
- 但如果 `.env` 被打进部署包、同步到共享目录或留在客户机，管理员账户控制面会暴露。
|
||
- 当前结论：
|
||
- 在开发机上记录为“运维接受项”。
|
||
- 在上线交付前必须改为受控注入，不应随项目目录长期保留。
|
||
|
||
## 3. 上线前应修复的代码问题
|
||
|
||
以下问题即使部署在私有内网，仍然成立，建议在正式部署前完成修复。
|
||
|
||
### 3.1 归档解压边界仍不安全
|
||
|
||
- 风险等级：高
|
||
- 证据：
|
||
- `scripts/unpack_archives.py:123`
|
||
- `scripts/unpack_archives.py:206`
|
||
- `backend/app/services/gf3_service.py:27`
|
||
- `backend/app/services/gf3_service.py:36`
|
||
- `backend/app/services/gf3_service.py:42`
|
||
- 问题描述：
|
||
- 现有检查主要基于归档条目名中的 `..` 或绝对路径。
|
||
- 但后续仍直接使用 `extractall`。
|
||
- 这种模式对 tar 的符号链接、硬链接等条目并不稳妥。
|
||
- 影响：
|
||
- 如果输入归档来自外部来源、共享目录或低信任操作员，可能出现目录逃逸或覆盖非目标文件的风险。
|
||
- 建议：
|
||
- 禁用不安全条目类型。
|
||
- 使用逐条提取代替 `extractall`。
|
||
- 在提取前对最终落盘路径做真实路径校验。
|
||
|
||
### 3.2 导出目录白名单使用前缀匹配，存在绕过空间
|
||
|
||
- 风险等级：中
|
||
- 证据：
|
||
- `backend/app/routers/dependencies.py:179`
|
||
- `backend/app/routers/dependencies.py:219`
|
||
- `backend/app/routers/tools.py:88`
|
||
- `backend/app/routers/dinsar.py:299`
|
||
- `backend/app/routers/idl.py:246`
|
||
- 问题描述：
|
||
- `ALLOWED_EXPORT_DIRS` 白名单校验使用 `startswith`。
|
||
- 当允许目录为 `C:\exports` 时，类似 `C:\exports_tmp` 也可能被误判为合法。
|
||
- 影响：
|
||
- 导出、复制、结果提取类接口的目标目录边界不够严格。
|
||
- 建议：
|
||
- 改为基于规范化后的真实路径做“目录包含关系”判断，而不是字符串前缀判断。
|
||
|
||
### 3.3 登录限流按用户名生效，容易被用于锁死指定账号
|
||
|
||
- 风险等级：中
|
||
- 证据：
|
||
- `backend/app/routers/dependencies.py:459`
|
||
- `backend/app/routers/auth.py:72`
|
||
- `backend/app/routers/dependencies.py:92`
|
||
- `backend/app/routers/dependencies.py:94`
|
||
- 问题描述：
|
||
- 当前限流键仅基于用户名，不区分来源。
|
||
- 任意请求方只需反复提交错误密码，即可让目标账号进入锁定窗口。
|
||
- 影响：
|
||
- 会形成低成本拒绝服务，尤其对 `admin` 账号明显。
|
||
- 建议：
|
||
- 改为“用户名 + 来源”或多维限流。
|
||
- 对不存在账号和存在账号保持相近的响应节奏。
|
||
- 视部署场景决定是否叠加网关层限流。
|
||
|
||
## 4. 本轮未发现的高风险点
|
||
|
||
本轮复核中，暂未发现以下明显高危问题：
|
||
|
||
- 前端未见将会话令牌持久化到 `localStorage` 或 `sessionStorage`。
|
||
- 后端主路由默认挂载了统一的授权与登录依赖。
|
||
- 管理类写操作多数仍要求管理员身份。
|
||
|
||
这不代表系统不存在其他缺陷，只表示在本次覆盖范围内未发现更高优先级的新问题。
|
||
|
||
## 5. 建议的上线前处置顺序
|
||
|
||
### P0：正式部署前必须完成
|
||
|
||
1. 修复所有归档解压的安全边界。
|
||
2. 修复导出路径白名单判断逻辑。
|
||
3. 调整登录限流策略，避免用户名级别锁死。
|
||
4. 确保 `license-issuer/`、`.env`、任何实际授权文件不进入部署包。
|
||
|
||
### P1：交付封装优化
|
||
|
||
1. 将签发工具与后端运行目录彻底拆分。
|
||
2. 将初始化口令改为部署时注入，而不是长期存放在项目根目录。
|
||
3. 为部署物建立显式排除清单。
|
||
|
||
## 6. 说明
|
||
|
||
- 本文档用于记录 2026-03-12 的补充审计结论。
|
||
- 本次审计未进行动态利用验证。
|
||
- 本次审计未修改业务代码。
|
||
|