📋 1. 自查总览
| # | 漏洞类型 | TOENK状态 | 整改方案 | 优先级 |
|---|---|---|---|---|
| API1 | 对象级授权失效 (BOLA) | 部分 | 强化对象级授权检查，实施资源拥有权验证 | 🔴 P0 |
| API2 | 认证失效 | 部分 | 实施JWT+ Refresh Token，完善会话管理 | 🔴 P0 |
| API3 | 过度数据暴露 | 待实施 | 限制API响应字段，实施数据最小化 | 🔴 P0 |
| API4 | 资源消耗与限速 | 已完成 | 已配置API速率限制和并发控制 | 🟢 P2 |
| API5 | 功能级授权失效 | 已完成 | 管理员/用户角色分离，路由权限已控制 | 🟢 P2 |
| API6 | 批量分配 | 待实施 | 实施输入白名单，防止属性批量覆盖 | 🔴 P0 |
| API7 | 安全配置错误 | 部分 | 持续加固Nginx/TLS/HTTP头配置 | 🟡 P1 |
| API8 | 注入 | 部分 | WAF+输入校验+参数化查询 | 🟡 P1 |
| API9 | 资产管理不当 | 待实施 | 建立完整API清单，停用过时端点 | 🟡 P1 |
| API10 | 日志与监控不足 | 部分 | 加强异常检测和告警覆盖 | 🟡 P1 |
🔍 2. 逐项整改方案
API1: 对象级授权失效（BOLA）部分完成
现状：New-API内置基本的用户资源隔离，但缺少细粒度的对象级授权检查。不同用户的API Key可以访问各自资源，但需要确保用户只能操作属于自己的数据对象。
整改步骤：
- 在API网关层增加资源属主验证中间件，每次请求校验用户ID与资源Owner ID是否匹配
- 实施UUID代替自增ID，降低可猜测风险
- 所有API端点添加@PreAuthorize("owner")类型注解或等价中间件逻辑
预计工时：2-3天
API2: 认证失效部分完成
现状：当前使用Bearer Token（API Key）方式认证，Token不会过期，存在长期泄露风险。缺少Refresh Token机制和完善的会话生命周期管理。
整改步骤：
- 实施JWT双Token机制：短期Access Token（15分钟）+ 长期Refresh Token（7天）
- API Key保留为可选的长期认证方式，但增加IP白名单绑定
- 实施登录失败锁定策略（连续5次失败锁定30分钟）
- 增加多因素认证（MFA）选项（TOTP）
预计工时：3-5天
API3: 过度数据暴露待实施
现状：API响应中可能返回了比前端所需更多的字段（例如用户管理接口返回了敏感字段）。
整改步骤：
- 对所有API端点实施响应字段白名单，只返回文档中声明的字段
- 区分内部接口和外部接口的响应数据形
- 使用DTO模式，每个API端点绑定专用Response DTO
- 移除敏感字段（密码Hash、内部ID、Token Secret等）
预计工时：2-3天
API4: 资源消耗与限速已完成 ✅
现状：New-API内置速率限制功能，已按用户等级配置调用频率上限（标准用户60 RPM，高级用户120 RPM）。
已验证：速率限制中间件正常工作，超出限制返回429 Too Many Requests。并发连接数已限制为每用户10个并发。
API5: 功能级授权失效已完成 ✅
现状：New-API天然支持管理员/用户角色分离。管理员后台路由（/api/* 管理端）和用户路由（/v1/* API端）已通过Nginx和New-API双重控制。
已验证：管理员Token（管理Token f44c565c...）和用户API Key分离。普通用户无法访问管理接口。
API6: 批量分配（Mass Assignment）待实施
现状：用户注册/更新接口可能存在批量分配漏洞，攻击者可以通过请求体覆盖未公开的字段。
整改步骤：
- 对所有POST/PUT请求体实施字段白名单验证
- 使用DTO/数据传输对象模式，只接受预定义字段
- 禁用auto-binding，强制显式字段映射
- 审计所有update/create接口，确保不存在role/权限等敏感字段可被用户覆盖
预计工时：1-2天
API7: 安全配置错误部分完成
现状：已配置TLS 1.3、HSTS、安全HTTP头等基础防护，但缺少自动化配置检查机制。
整改步骤：
- 实施Nginx配置自动化安全扫描（每周）
- 关闭不必要的HTTP方法（TRACE/DELETE/PUT等除必要外全部禁用）
- 配置Content-Security-Policy (CSP) 响应头
- 禁用目录列表，配置404处理
- 移除不必要的HTTP响应头（Server: nginx版本信息等）
预计工时：1天
API8: 注入部分完成
现状：系统使用SQLite数据库。New-API已内置基本的输入转义，但未实施参数化查询的统一框架。Nginx层配置了基本WAF规则。
整改步骤：
- 在Nginx层实施ModSecurity WAF（OWASP CRS规则集）
- 审核所有数据库查询，改为参数化查询（prepared statement）
- 限制API输入参数长度和类型
- 对用户输入实施严格的编码验证
预计工时：2-3天
API9: 资产管理不当待实施
现状：缺少系统化的API端点和版本清单文档。部分内部管理端点可能暴露在外。
整改步骤：
- 建立并维护完整的API资产清单（所有公开端点、内部端点、管理端点）
- 实施API版本标准化（/v1/, /v2/, 弃用策略）
- 停用或隐藏所有非必要的内部端点
- 建立API变更管理流程，新增端点必须经过安全评审
- 定期（每月）扫描暴露的API端点
预计工时：2天
API10: 日志与监控不足部分完成
现状：系统已有基础日志（Nginx access log + New-API 调用日志），但缺少集中式日志分析和异常行为检测。
整改步骤：
- 实施集中式日志聚合（ELK或Loki方案）
- 配置异常行为检测规则：同IP大量失败认证、异常时间调用、罕见端点访问
- 设置多级告警（即时/5分钟/15分钟）
- 保留日志至少6个月，支持安全溯源
- 定期（每月）审查安全日志
预计工时：3-5天
📡 3. API资产清单
以下为TOENK API所有公开/内部端点清单，用于安全审计和资产盘点：
3.1 公开API端点
| 方法 | 路径 | 认证 | 说明 |
|---|---|---|---|
| GET | /api/status | 不需要 | 系统状态查询 |
| GET | /api/setup | 不需要 | 安装状态检查 |
| POST | /api/user/login | 不需要 | 用户登录 |
| POST | /api/user/register | 不需要 | 用户注册 |
| POST | /v1/chat/completions | 需要Token | 模型调用（核心API） |
| GET | /v1/models | 需要Token | 模型列表查询 |
3.2 管理端API（内部）
| 方法 | 路径 | 认证 | 说明 |
|---|---|---|---|
| GET | /api/ | Admin Token | 管理面板数据 |
| GET | /api/user/ | Admin Token | 用户列表/管理 |
| GET | /api/token/ | Admin Token | API令牌管理 |
| GET | /api/log/ | Admin Token | 日志查询 |
3.3 静态资源端点
GET /home ·
GET /docs/ ·
GET /status.html ·
GET /favicon.svg ·
GET /robots.txt ·
GET /sitemap.xml
3.4 SPA前端路由（Nginx → 后端）
GET / ·
/sign-in ·
/sign-up ·
/dashboard ·
/profile ·
/keys ·
/about
🗺️ 4. 整改路线图
| 阶段 | 时间 | 任务 | 优先级 |
|---|---|---|---|
| Phase 1 紧急修复 |
第1周 |
API6 批量分配 — 输入白名单 API9 API资产清单建立 API7 安全配置加固（HTTP头/CSP） |
P0 |
| Phase 2 核心加固 |
第2-3周 |
API1 BOLA — 对象级授权中间件 API2 JWT+Refresh Token API3 响应字段控制 |
P0 |
| Phase 3 纵深防御 |
第4周 |
API8 ModSecurity WAF API10 日志集中化+异常检测 定期扫描+渗透测试 |
P1 |
| Phase 4 持续优化 |
第5-6周 |
API4 限速算法升级（令牌桶） 安全日志月审机制 自动化安全扫描流水线 |
P1 |