安全审计补充记录（2026-03-12）

审计范围：后端权限边界、文件与归档处理链路、部署敏感资产暴露情况。
审计方式：静态只读审计，本文档仅记录结论与建议，不包含代码修复。
审计前提：当前环境为开发机，目标部署环境为私有内网；授权签发材料与初始化密码当前因封装方式不足，仍位于开发目录中。

1. 本次审计的判断口径

本次记录将问题分为两类：

这一区分的目的，是避免把“开发机上的临时暴露”与“真正需要修代码的问题”混为一谈。

以下内容在当前“开发机 + 私有内网 + 尚未完成封装”的前提下，可以暂时理解为运维接受项；但它们不应进入最终部署包、客户现场机器、共享目录或备份集。

证据：
- license-issuer/issue_license.py
- license-issuer/private_key.b64
- backend/app/license_service.py
- license-issuer/README.md
说明：
- 当前目录同时包含授权验证逻辑和签发私钥材料。
- 在开发阶段这可以理解为便于调试和现场签发。
- 但从交付角度看，签发端与验证端必须物理隔离。
当前结论：
- 在开发机上记录为“运维接受项”。
- 在上线交付前必须从部署物中彻底移除。

证据：
- .env
- scripts/init_db.py
- README.md
说明：
- 初始化脚本会读取 INIT_ADMIN_PASSWORD 用于创建或重置管理员。
- 这在开发期、首次部署准备期可以理解为简化初始化流程。
- 但如果 .env 被打进部署包、同步到共享目录或留在客户机，管理员账户控制面会暴露。
当前结论：
- 在开发机上记录为“运维接受项”。
- 在上线交付前必须改为受控注入，不应随项目目录长期保留。

以下问题即使部署在私有内网，仍然成立，建议在正式部署前完成修复。

风险等级：高
证据：
- 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。
- 在提取前对最终落盘路径做真实路径校验。

风险等级：中
证据：
- 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 也可能被误判为合法。
影响：
- 导出、复制、结果提取类接口的目标目录边界不够严格。
建议：
- 改为基于规范化后的真实路径做“目录包含关系”判断，而不是字符串前缀判断。

风险等级：中
证据：
- 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 账号明显。
建议：
- 改为“用户名 + 来源”或多维限流。
- 对不存在账号和存在账号保持相近的响应节奏。
- 视部署场景决定是否叠加网关层限流。

本轮复核中，暂未发现以下明显高危问题：

这不代表系统不存在其他缺陷，只表示在本次覆盖范围内未发现更高优先级的新问题。