# 安全审计补充记录（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 的补充审计结论。
- 本次审计未进行动态利用验证。
- 本次审计未修改业务代码。