rickyma18/api-pentest-otp-business-logic

# 🔴 API 安全评估 — 幻想投注平台中的业务逻辑滥用 本评估展示了识别、利用并串联多个 API 漏洞，形成真实可牟利的攻击场景的能力。    -lightgrey) --- ## ⚠️ 免责声明 本文档是**经过脱敏与匿名化处理的真实评估报告**。所有客户名称、域名、端点、标识符、令牌及用户数据均已替换为虚构占位符（`api.example.com`、`user_1`、虚拟 UUID 等）。本文档中的信息**不得用于攻击原始系统**。仅限个人作品集展示用途，经授权发布。 --- ## 📑 目录 1. [执行摘要](#1-executive-summary) 2. [参与概述](#2-engagement-overview) 3. [方法论](#3-methodology) 4. [发现汇总](#4-findings-summary) 5. [旗舰发现 — 推荐农场 + 完整折扣绕过](#5-flagship-finding--referral-farming--full-discount-bypass) 6. [攻击路径](#6-attack-paths) 7. [精选技术发现](#7-selected-technical-findings) 8. [端到端攻击叙事](#8-end-to-end-attack-narrative) 9. [影响分析](#9-impact-analysis) 10. [OWASP API Top 10 (2023) 映射](#10-owasp-api-top-10-2023-mapping) 11. [修复路线图](#11-remediation-roadmap) 12. [检测缺口分析](#12-detection-gap-analysis) 13. [经验总结](#13-lessons-learned) 14. [工具与技术栈](#14-tools--stack) --- ## 1. 执行摘要 目标为**移动端“幻想投注”应用的 REST API 后端**——用户加入私密社群，对体育赛事结果进行付费预测并共享奖金池。应用与外部金融科技提供商对接处理存取款，并运行带有真实货币奖励的推荐计划。 评估采用**黑盒方式**，针对**QA 环境**，覆盖认证、账户恢复、参与流程、支付集成、推荐跟踪、操作观察性端点与会话管理。 ### 核心结果 | 指标 | 值 | |---|---| | **全局风险等级** | 🔴 **严重** | | 确认发现 | **25**（10 个关键 · 8 个高 · 4 个中 · 3 个低） | | 已验证假设（排除） | 7（有明确记录） | | 识别出的积极控制项 | 9 | | 单个最高 CVSS | 9.1 | | 旗舰发现 | 可货币化的业务逻辑滥用链 | ### 关键结论 - **完全可自动化的业务逻辑滥用链**（旗舰发现）使外部攻击者无需真实付款即可从推荐计划中提取真实奖励，链式利用了 OTP 设计缺陷、缺少速率限制以及公开端点暴露的内部支付方式。 - **BOLA（Broken Object Level Authorization）具有系统性**：7 个端点均存在，非孤立漏洞。根本原因为架构层面未实施跨对象所有权策略。 - **密码更改不是有效的响应控制**：变更密码前后颁发的访问令牌与刷新令牌仍有效。一旦令牌泄露，攻击者可长期保持访问。 - **未认证的 Prometheus `/metrics` 端点**泄露真实 `transactionId` 与 `userId`，直接助长了针对交易记录的 BOLA 攻击。 --- ## 2. 能力展示 本评估展示了识别、验证并串联多个 API 漏洞，形成真实可牟利攻击场景的能力。 ### 🔐 API 安全评估 - OWASP API Top 10 (2023) 评估 - 端点枚举与攻击面测绘 - 认证与会话管理测试（JWT、OTP 流程） ### 🚨 授权与访问控制分析 - BOLA / IDOR 跨端点利用 - 水平与垂直权限提升 - 多端点授权链组合 ### 💣 业务逻辑滥用与金融操纵 - 可货币化攻击路径识别与利用 - 金融流程操纵（支付绕过、推荐滥用） - 面向内部使用的功能被公开暴露 ### 🔄 攻击链构建 - 端到端利用路径设计与执行 - 多个低/中严重问题汇聚为关键影响 - 模拟真实攻击者思维 ### 🧪 验证与利用 - 手工 HTTP 请求重现 - PowerShell 脚本自动化 - QA 环境受控验证 ### 🏗️ 安全架构与风险分析 - 系统性设计缺陷识别（认证、授权、可观察性） - 孤立漏洞与架构弱点的区分 - 超越 CVSS 的业务影响评估 ### 🧭 专业方法 - 以实际可利用性为导向 - 关注业务影响与攻击可行性 - 与 OWASP 及真实攻击行为对齐的方法论 --- ## 3. 测试方式 评估采用**以攻击者驱动的手动方法**，聚焦可利用的认证、授权与业务逻辑弱点。 ### 🧭 攻击面测绘 - 使用 OpenAPI（Swagger）枚举所有暴露端点 - 识别高风险区域：认证流、参与流程、交易、推荐系统、可观察性端点 - 绘制实体关系图（用户 → 参与 → 交易 → 推荐） ### 🔐 认证与会话分析 - 测试登录、密码重置、OTP 验证流程 - 分析令牌生命周期（JWT 访问令牌 + 刷新令牌） - 验证密码更改后的会话失效行为 - 发现 OTP 泄露与令牌重用机会 ### 🚨 授权测试（BOLA / IDOR） - 在用户范围端点执行水平访问控制测试 - 操纵对象标识符（userId、participationId、transactionId） - 关联来自多个端点（指标、统计、排位）的泄露标识符 - 验证多个资源上缺少所有权检查 ### 💣 业务逻辑滥用测试 - 分析支付与参与流程 - 测试多种支付方式，包括内部专用选项 - 模拟推荐与奖励系统的滥用场景 - 识别具有真实财务影响的攻击路径 ### 🔄 多步骤攻击链 - 组合多个低/中严重问题形成完整利用链 - 从数据泄露 → IDOR → 金融滥用重构攻击者路径 - 验证端到端场景的可行性 ### 🧪 验证与利用 - 使用原始 HTTP 请求重现攻击 - 使用 PowerShell 脚本自动化关键流程 - 在受控 QA 环境验证 - 验证正向与负向控制（防护按预期生效） ### 📊 可观察性与数据暴露 - 分析公开可访问的监控端点 - 识别指标中的敏感数据泄露 - 将泄露标识符与脆弱端点关联 ### 🧭 测试理念 - 优先真实可利用性而非理论漏洞 - 关注业务影响与货币化潜力 - 将业务逻辑视为主要攻击面 ### 🧰 工具（辅助角色） - Burp Suite（手动拦截与请求操作） - PowerShell（流程自动化） - 浏览器开发者工具（客户端分析） --- ## 4. 成果证明 本案例研究基于在受控 QA 环境中执行的动手测试与可重现攻击场景。 评估包含： - 跨多个 API 端点的真实攻击链重建 - 每个漏洞的可重现 HTTP 请求 - 用于自动化关键利用流程的 PowerShell 脚本 - 多端点关联攻击（IDOR + 数据暴露 + 业务逻辑） - 通过模拟场景验证的财务影响 所有示例均已脱敏，移除任何敏感或可识别信息。 --- ## 5. 影响概览 | 领域 | 影响 | |---|---| | 认证 | 因 OTP 滥用导致的账户接管 | | 授权 | 系统性 BOLA / IDOR 暴露 | | 业务逻辑 | 推荐系统中的金融操纵 | | 监控 | 指标端点泄露敏感数据 | --- ## 2. 参与概述 ### 目标 评估移动端客户端所依赖的后端 API 的安全状况，重点关注**业务逻辑完整性**，而非仅技术漏洞。评估范围明确面向可能产生直接经济、监管或声誉影响的滥用场景。 ### 范围 - 后端 API（QA 环境）：`https://api.example.com/api` - 移动端客户端（Android APK —— 静态分析 + 动态调试） - 关键功能流：注册、认证、密码恢复、池参与、团体排名、获奖者、财务交易、外部钱包集成、推荐计划 - 操作端点：`/metrics`、`/api-docs` ### 范围外 - 底层基础设施（云、容器、边界网络） - 后端源代码审查（纯黑盒测试） - 第三方支付提供方内部机制 - 生产环境 ### 授权与周期 测试在客户书面授权下，针对独立的 QA 环境，在多周迭代周期内执行。 --- ## 3. 方法论 评估结合多种行业框架： - **OWASP API 安全 Top 10 (2023)** - **OWASP MASVS**（移动应用安全验证标准） - **OWASP WSTG v4.2** - **PTES**（渗透测试执行标准） ### 阶段 ``` ┌─────────────────────────────────────────────────────────────┐ │ 1. Passive recon → APK static analysis, OpenAPI │ │ enumeration, /metrics scraping │ │ 2. Active enumeration → endpoint mapping, auth patterns │ │ 3. AuthN / session → OTP flow, token lifecycle │ │ 4. AuthZ → BOLA, BFLA, horizontal/vertical │ │ 5. Business-logic → referral program, payment │ │ abuse methods, financial flows │ │ 6. Chain construction → multi-endpoint exploitation │ │ 7. Controlled PoC → end-to-end validation │ └─────────────────────────────────────────────────────────────┘ ``` ### 工具 `JADX` · `Burp Suite Pro` · `Frida` · `Postman` / `curl` · 自定义 Python 自动化脚本 --- ## 4. 发现汇总 ### 按严重性分布 | 严重性 | 数量 | CVSS 平均值 | CVSS 范围 | |---|---|---|---| | 🔴 关键 | 10 | 8.4 | 7.5 – 9.1 | | 🟠 高 | 8 | 7.3 | 6.5 – 8.1 | | 🟡 中 | 4 | 5.1 | 4.3 – 5.5 | | 🟢 低 | 3 | 2.8 | 2.0 – 3.7 | | **总计** | **25** | — | — | ### 按 OWASP API Top 10 (2023) 分布 | 类别 | 发现 | 占比 | |---|---|---| | API1 — 破坏对象级别授权 | 7 | 28% | | API2 — 破坏认证 | 5 | 20% | | API3 — 破坏对象属性级别授权 | 1 | 4% | | API4 — 无限制资源消耗 | 1 | 4% | | API5 — 破坏函数级别授权 | 1 | 4% | | API6 — 无限制访问敏感业务流 | 2 | 8% | | API8 — 安全配置错误 | 8 | 32% | **战略解读**：80% 的发现集中在 API1 + API2 + API8。这表明平台在设计时未将授权作为跨层策略，且可观察性表面未与功能表面同步加固。 --- ## 5. 旗舰发现 — 推荐农场 + 完整折扣绕过 **发现 ID**：`F-036` **严重性**：🔴 关键 · **CVSS 3.1**：8.7 — `AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N` **OWASP**：API6:2023 — *无限制访问敏感业务流*（主要） + API5:2023 — *破坏函数级别授权* ### 是什么 一个**可自动化的业务逻辑滥用链**，使攻击者无需真实付款即可从平台的推荐计划中获取真实货币奖励。该向量由五个独立弱点组合而成，单独看均为中等严重，但组合后破坏了推荐计划的经济完整性。 ### 为何 CVSS 低估影响 CVSS 基础分 8.7 仅反映技术链条的严重性。**实际业务影响更大**，因为： - 直接货币化 - 攻击账户数量可线性扩展 - 每笔欺诈推荐的边际成本接近零 - 客户端难以检测 ### 根本原因 **架构层面**：推荐计划缺乏反欺诈模型，无法关联同一 `invitationCode` 创建的多账户、检测多账号行为，或在奖励发放前要求真实付款证明。奖励资格基于**注册**而非**真实交易**。 **实现层面**：内部支付方式 `full_discount`（ intended for internal/promotional use）被公共 `POST /api/participations` 端点接受，且**无角色校验、无折扣码验证、无上下文验证**。由此创建的参与记录可计入奖品池并**触发推荐奖励累积**。 ### 组件发现 | 组件 | 在链条中的作用 | |---|---| | `F-001` — 密码恢复响应中泄露 OTP | 绕过“持有”因素 | | `F-002` — 通用认证响应中泄露 OTP | 支持批量注册而无需真实手机/邮箱 | | `F-004` — 注册 / OTP / 恢复无速率限制 | 支持自动化大规模操作 | | `F-034` — 以可控账户进行推荐农场 | 多账户创建并统一使用 `invitationCode` | | `F-019` — `full_discount` 支付方式公开可用 | 支付绕过 — 创建无需真实付款的参与记录 | ### 攻击流程 ``` ┌────────────────────────────────────────────────────────────────────┐ │ FLAGSHIP CHAIN — Referral Farming × Full-Discount Monetization │ │ │ │ [F-001/002] OTP code returned in HTTP body │ │ │ │ │ ▼ │ │ [F-004] Mass registration, no rate limit │ │ │ │ │ ▼ │ │ [F-034] N accounts registered under attacker's invitation │ │ │ │ │ ▼ │ │ [F-019] Each account creates a participation with │ │ paymentMethod: "full_discount" (no real payment) │ │ │ │ │ ▼ │ │ [F-036] Attacker's primary account accrues referral rewards │ │ (discountAmount / profitsAmount increase observed) │ │ │ │ RESULT: Real monetary value extracted from the platform │ │ Scales ~linearly with number of controlled accounts │ └────────────────────────────────────────────────────────────────────┘ ``` ### 概念验证 **步骤 1 — 攻击者获取自身的 `invitationCode`** ``` GET /api/users/me HTTP/1.1 Host: api.example.com Authorization: Bearer eyJhbGciOi...TRUNCATED ``` ``` { "id": "00000000-0000-0000-0000-000000000001", "invitationCode": "ATTACKER123" } ``` **步骤 2 — 注册被推荐账户（循环 N 次）** ``` POST /api/auth/register HTTP/1.1 Host: api.example.com Content-Type: application/json { "email": "referred01@example.com", "password": "Passw0rd!", "invitationCode": "ATTACKER123" } ``` **步骤 3 — 请求 OTP（持有因素可被绕过）** ``` POST /api/otp/send HTTP/1.1 Host: api.example.com Content-Type: application/json { "email": "referred01@example.com", "type": "registration" } ``` ``` { "status": "ok", "code": "000000" } ``` **步骤 4 — 使用泄露值验证 OTP** ``` POST /api/otp/verification HTTP/1.1 Host: api.example.com Content-Type: application/json { "email": "referred01@example.com", "code": "000000" } ``` **步骤 5 — 以被推荐账户登录** ``` POST /api/auth/login HTTP/1.1 Host: api.example.com Content-Type: application/json { "email": "referred01@example.com", "password": "Passw0rd!" } ``` **步骤 6 — 使用 `full_discount` 创建参与记录（无真实付款）** ``` POST /api/participations HTTP/1.1 Host: api.example.com Authorization: Bearer Content-Type: application/json { "poolId": "00000000-0000-0000-0000-0000000000AA", "predictedResults": [ ... ], "paymentMethod": "full_discount" } ``` ``` { "id": "00000000-0000-0000-0000-0000000000BB", "status": "CONFIRMED", "paymentMethod": "full_discount" } ``` **步骤 7 — 验证推荐账户的奖励累积** ``` GET /api/users/me HTTP/1.1 Host: api.example.com Authorization: Bearer ``` 观察到攻击者账户的 `discountAmount` 与 `profitsAmount` 持续增加。 ### 影响 **技术层面**：推荐计划经济完整性受损；用户显示的小组奖品池与真实资金支持脱节；内部增长指标失真。 **业务层面**：单个活跃攻击账户每月可造成约 **600 美元** 损失（在所测试的周频场景下），且随账户数量线性扩展。攻击者边际成本极低，客户端检测难度高。 ### 修复建议（协调式 — 单一修复无法关闭向量） 1. **从公共参与端点移除 `full_discount`**。限制仅内部角色使用。 2. **排除 `full_discount` 参与记录** 于推荐奖励与奖品池计算之外。 3. **从 `/api/otp/send` 与 `/api/auth/forgot-password` 响应中移除 `code` 字段**；OTP 仅通过带外渠道（邮件/SMS）传递。 4. **对 `/api/auth/register`、`/api/otp/send`、`/api/auth/forgot-password` 实现速率限制**（例如 5 次/分钟/IP），并采用渐进式阻断。 5. **设计推荐计划反欺诈模型**： - 按 IP、设备指纹、电话、注册模式关联账户 - 将“注册推荐人”与“奖励资格推荐人”分离（后者需经真实付款验证） - 在发放货币奖励前要求政府 ID 验证 6. **业务逻辑监控**：对异常推荐网络增长、重复使用 `full_discount`、注册→参与快速序列告警。 --- ## 6. 攻击路径 识别出五条操作攻击路径，每条均将独立发现串联为连贯影响向量。 ### 🔴 路径 1 — 推荐计划货币化（旗舰） 参见 [第 5 节](#5-旗舰发现---推荐农场--完整折扣绕过) ### 🔴 路径 2 — 持久化账户接管 攻击者控制合法账户后，**即使受害者更改密码仍可保持访问**。 ``` [F-001] Password-recovery OTP leaked in HTTP response │ ▼ [F-003] Recovery token accepted more than once (replay) │ ▼ [F-006] Access tokens issued before the password change remain valid │ ▼ [F-023] Refresh tokens issued before the password change remain valid RESULT: Persistent access to the compromised account even after the victim temporarily regains control via password reset. ``` ### 🟠 路径 3 — 竞争情报重建（多点 BOLA 链） 在不破坏任何账户的前提下，重建任意用户的完整历史竞技档案。 ``` [F-007] User enumeration (email / national ID / phone) │ → userId ▼ [BP-AC-01] GET /api/statistics/by-user/{id} │ → lastParticipation.id ▼ [F-012] GET /api/standings/historical?groupId= │ → lastParticipation.id per ranked user ▼ [F-032] GET /api/standings/by-pool/{poolId}?groupId= │ ▼ [F-011] GET /api/winners/by-pool/{poolId}?groupId= │ → participation.id + prize amounts ▼ [F-005] GET /api/participations/{id} │ → predictedResults on finalized pools ▼ [F-016] GET /metrics (real IDs accelerate reconnaissance) RESULT: Full competitive profile of an arbitrary user rebuilt with zero account compromise and low detectability. ``` ### 🟠 路径 4 — 直接金融数据暴露 ``` [F-016] Unauthenticated /metrics leaks real transactionId / userId │ ▼ [F-017] GET /api/transactions/{id} - Ownership oracle via differential error messages - Sensitive financial data (amounts, method, metadata) - metadata.token (external payment-provider integration token) RESULT: Third-party financial data + payment-integration tokens. ~75% of transactionIds scraped from /metrics were queryable in the observed sample. ``` ### 🟡 路径 5 — 跨社群数据泄露 ``` [F-011] winners/by-pool?groupId= [F-012] standings/historical?groupId= [F-032] standings/by-pool?groupId= RESULT: Rankings, prizes and competitive dynamics of private groups visible to non-members — eroding the privacy value prop of the community model. ``` --- ## 7. 精选技术发现 ### 🔴 F-001 — 密码恢复响应中泄露 OTP **CVSS 9.1** — `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N` · API2:2023 密码恢复端点在响应体中**明文返回 OTP**，消除了带外验证渠道。攻击者仅凭已知邮箱即可在单次 HTTP 请求中接管账户。 ``` POST /api/auth/forgot-password HTTP/1.1 Host: api.example.com Content-Type: application/json { "email": "victim@example.com" } ``` ``` { "status": "ok", "code": "000000", "expiresAt": "2026-01-01T00:00:00Z" } ``` **根本原因**：OTP 生成与交付至客户端耦合在同一个 API 响应中，而非仅通过受信外部通道发送。 **修复**：移除 `code` 字段。OTP 仅通过注册邮箱/SMS 传递。API 响应应为通用确认。 --- ### 🔴 F-003 — 恢复令牌重放 **CVSS 8.1** — `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N` · API2:2023 密码重置**令牌在使用后未被失效**。同一令牌可重复使用直至基于时间的过期。结合 F-001，攻击者在受害者临时恢复账户后可再次锁定。 **修复**：首次使用后标记令牌为已消费。发放新令牌时使旧令牌失效。记录重用尝试作为事件信号。 --- ### 🔴 F-005 — 参与记录的水平访问控制（BOLA） **CVSS 7.5** · API1:2023 `GET /api/participations/{id}` 允许任何认证用户读取其他用户的参与记录。对已结束池，返回完整对象（含 `predictedResults`、`paymentMethod` 等）；对活跃池的部分限制是池生命周期副作用，而非授权检查。 ``` GET /api/participations/00000000-0000-0000-0000-000000000BBB HTTP/1.1 Host: api.example.com Authorization: Bearer ``` **根本原因**：授权依赖于池状态（`isFinished`），而非资源所有权。缺少 `assertOwnership(userId, participationId)`。 **修复**：在读取前验证 `participation.userId == authenticatedUser.id`。 --- ### 🔴 F-011 — 优胜者列表的 BOLA **CVSS 7.7** · API1:2023 `GET /api/winners/by-pool/{poolId}?groupId=<任意>` 接受任意 `groupId` 而不验证认证用户是否为其成员。响应暴露完整优胜者列表——包含 `userId`、显示名、头像、`prizeAmount`，以及关键字段 `participation.id`，可直接跳转到 F-005。 **修复**：服务端验证组成员资格。从响应中移除 `participation.id`。 --- ### 🔴 F-015 — 多端点利用链 **CVSS 8.5** — 跨 API1 + API2 + API3 + API8 的横向组合。并非单个端点漏洞，而是**BOLA、枚举与元数据泄露的组合**，使攻击者仅凭一个有效令牌即可重建任意用户的完整竞技历史。 > 说明：将此作为独立发现记录的原因在于：单独修复任一端点不足以阻断该链。需实施跨对象所有权/成员关系策略。 --- ### 🔴 F-017 — 金融数据暴露 + 所有权 oracle **CVSS 8.5** · API1:2023 + API3:2023 `GET /api/transactions/{id}` 存在两个并发问题： 1. **通过差异化错误消息实现的权限 oracle**：响应体因记录是否存在、是否属于当前令牌而不同。攻击者可在不直接访问的情况下判定存在性与所有权。 2. **有效 ID 时返回完整金融数据**：含金额、支付方式、订单元数据，以及 `metadata.token`（外部支付提供方集成令牌）。 结合 F-016（未认证 `/metrics` 泄露真实 `transactionId`），约 75% 的抓取事务 ID 可被成功查询。 **修复**：统一所有错误响应为通用“资源未找到”。强制执行严格所有权验证。移除 `metadata.token` 及内部订单数据。 --- ### 🔴 F-019 — 公共滥用内部支付方法 `full_discount` **CVSS 8.5** · API5:2023 + API6:2023 `POST /api/participations` 接受来自任意认证用户的 `paymentMethod: "full_discount"`——**无角色校验、无折扣码、无文档验证**。由此创建的参与记录： 1. 被视为有效付费参与 2. 计入奖品池 3. 触发创建者的推荐奖励累积 这是**支付绕过原语**，构成 F-036 的基础。 **修复**：将 `full_discount` 限制为内部角色。启用时要求有效 `discountCode`。将其排除在奖品池贡献与推荐奖励之外。在创建参与前对未验证账户强制执行 KYC。 --- ### 🟠 F-006 与 F-023 — 密码更改后会话仍有效 **CVSS 8.1** · API2:2023 访问令牌（F-006）与刷新令牌（F-023）在密码更改后**仍保持有效**。JWT 架构缺少吊销机制——无 `tokenVersion`、无 `jti` 跟踪、无活跃会话表。 **操作后果**：密码更改不是有效的响应控制。若令牌已被捕获，攻击者可无限期保持访问（仅受自然过期限制）。 **修复**：为每个用户引入 `tokenVersion`（密码更改时递增），或使用活跃会话表，或基于 `jti` 的吊销机制。密码更改时使所有刷新令牌失效。实现刷新令牌轮换与重用检测。 --- ### 🟠 F-016 — 未认证的 Prometheus `/metrics` 暴露 **CVSS 7.5** · API8:2023 返回标准 Prometheus 输出，包含： - 真实 `transactionId` 与 `userId` 作为标签值 - 未参数化的 API 路径（如 `/api/transactions/`） - Node.js 运行时版本 - 操作流量模式 这是**侦察加速器**，使 F-017 在规模上可行。 **修复**：认证 `/metrics` 并限制仅内部 IP。参数化指标中间件路径，避免记录真实标识符。对所有标签值进行审计。 --- ### 🟠 F-007 — 多向量用户枚举 **CVSS 7.5** · API3:2023 四个端点支持按不同标识符（邮箱、电话、身份证、邀请码）查询用户，**存在性判断与元数据泄露**均通过差异化响应体现。缺少速率限制（F-004）加剧风险。 身份证查询端点具有额外监管意义：标识符属于当地数据保护法下的受保护个人数据。 **修复**：存在性检查返回统一响应。剥离公共响应中的元数据。应用跨端点速率限制。评估禁用身份证查询或限制为管理员角色。 --- ### 🟠 BP-AC-01、F-012、F-032 — 统计与排位的 BOLA 三者共享同一反模式：端点接受 `userId`/`groupId` 参数却**未验证请求者与资源的关系**。每个均为高严重性 BOLA，但其真实价值在于作为 F-015 链中的**枢纽点**——暴露 `lastParticipation.id` 或 `participation.id`，进而跳转到 F-005。 **修复**：对相关资源家族实施统一的跨对象成员关系策略。 --- ## 8. 端到端攻击叙事 真实攻击者在 QA 条件下执行以下流程： **阶段 0 — 被动侦察** `GET /api-docs`（F-008）获取完整 OpenAPI 规范。`GET /metrics`（F-016）获取真实 `transactionId`、`userId` 及未参数化路径。 **阶段 1 — 用户枚举** 利用四个用户查找端点（F-007）构建目标用户目录及元数据。 **阶段 2 — 账户接管** F-01 泄露恢复 OTP。F-003 使恢复令牌可重放。F-004 无速率限制使自动化成为可能。 **阶段 3 — 持久化** F-006（访问令牌）与 F-023（刷新令牌）在密码更改后仍有效。攻击者保持粘性。 **阶段 4 — 竞争情报** 执行 F-015 链，获取任意用户完整竞技档案。无需账户妥协。 **阶段 5 — 金融暴露** 将 F-016 中获取的 `transactionId` 代入 `GET /api/transactions/{id}`（F-017），枚举第三方金融数据与 `metadata.token`。 **阶段 6 — 支付绕过** `full_discount`（F-019）使攻击者创建无需付款的参与记录。 **阶段 7 — 货币化** 执行完整推荐链（F-036）： ``` register (referred, invitationCode=ATTACKER123) → otp/send (code leaks in response) → otp/verification (using leaked code) → login (referred account) → participation (paymentMethod: full_discount) → observe referral rewards accrue on primary account ``` 在 N 个自动化账户上以周频循环执行。 **操作特性**：接近零边际成本、线性可扩展、客户端无法察觉。 --- ## 9. 影响分析 ### 财务 | 向量 | 预估影响 | |---|---| | **F-036**（旗舰） | 每个活跃攻击账户约 **600 美元/月**，随账户数量线性扩展 | | **F-019** 单独 | 取决于池规模与攻击账户数 | | **F-006 + F-023** | 与 ATO 事件数量成正比（无有效遏制） | | **F-017** | 取决于监管暴露与品牌声誉 | ### 声誉 F-036、F-001/F-002 或 F-017 的公开披露将对平台及其外部支付合作伙伴造成重大声誉影响。 ### 社区模型信任 F-015 链允许任意用户重建其他用户的完整竞技历史。若公开化，将侵蚀私密群组功能的隐私价值主张。 ### 事件响应能力 F-006 与 F-023 意味着**密码更改无法作为响应控制**。在真实 ATO 事件中，安全团队无法通过标准流程驱逐攻击者。此能力缺口会放大未来所有事件的影响。 ### 合规性 以下组合构成合规暴露： - 公共身份证查询端点（F-007） - 金融数据暴露（F-017） - 支付集成令牌出现在响应体（F-017） 在部署至生产环境前，需由法务/合规部门进行专门审查。 --- ## 10. OWASP API Top 10 (2023) 映射 | 类别 | 发现 | 占比 | |---|---|---| | **API1** — 破坏对象级别授权 | F-005、F-011、BP-AC-01、F-012、F-017、F-028、F-032 | 28% | | **API2** — 破坏认证 | F-001、F-002、F-003、F-006、F-023 | 20% | | **API3** — 破坏对象属性级别授权 | F-007 | 4% | | **API4** — 无限制资源消耗 | F-004 | 4% | | **API5** — 破坏函数级别授权 | F-019 | 4% | | **API6** — 无限制访问敏感业务流 | F-034、F-036 | 8% | | **API8** — 安全配置错误 | F-008、F-009、F-010、F-013、F-014、F-015、F-016、F-018 | 32% | **架构诊断**：API1 + API2 + API8 占比 80%，表明平台未将授权设计为跨层策略，且可观察性表面未与功能表面同步加固。逐端点修补无法解决此类问题，需架构级干预。 --- ## 11. 修复路线图 ### 🔴 紧急 — 0–7 天（快速遏制） 在向更高环境推广前必须实施： | # | 行动 | 覆盖发现 | |---|---|---| | 1 | 禁用 `full_discount` 于公共 `POST /api/participations`（功能开关/方法白名单） | F-036、F-019 | | 2 | 排除 `full_discount` 参与记录于推荐奖励与奖品池计算 | F-036、F-019 | | 3 | 从 OTP 响应中移除 `code` 字段 | F-001、F-002 | | 4 | 对 `/api/auth/register`、`/api/otp/send`、`/api/auth/forgot-password` 实现速率限制（5 次/分钟/IP） | F-004、F-034 | | 5 | 恢复令牌使用后失效 | F-003 | | 6 | 密码更改时使所有刷新令牌失效 | F-023 | | 7 | 认证 `/metrics` 并限制仅内部 IP | F-016 | | 8 | 保护或禁用 `/api-docs` | F-008 | | 9 | 从公共错误响应中移除余额、金额、令牌等字段 | F-009 | | 10 | 在 `winners/by-pool` 与 `standings/by-pool` 中验证组成员资格；移除 `participation.id` | F-011、F-032 | | 11 | 从优胜者与统计端点移除 `participation.id` 与 `lastParticipation.id` | F-015、BP-AC-01 | | 12 | 规范化 `GET /api/transactions/{id}` 错误消息 | F-017 | | 13 | 禁用或加门身份证查询端点 | F-007 | ### 🟠 高 — 7–30 天（架构重构） - 推荐计划反欺诈架构（关联账户、检测多账号、付款前奖励资格验证） - 角色限定访问内部支付方法 - 未验证账户 KYC 强制执行 - OTP 流程重构：生成内部、仅外部交付 - 令牌吊销机制（`tokenVersion` / 活跃会话表 / `jti` 跟踪） - 所有权验证覆盖所有资源 - 统一用户搜索响应 + 跨端点速率限制 - 标准化错误消息 - 禁用身份证查询或管理员限定 - 事务数据最小化 - 外部钱包链接的双因素验证 - 多端点序列日志与告警 ### 🟡 中 — 30–90 天（可持续成熟） - 健壮的会话架构（短生命周期刷新令牌、轮换与重用检测） - 跨端点统一错误处理与 ID 脱敏 - 严格输入验证 - 路由级 `Access-Control-Allow-Methods` 配置 - 业务逻辑监控：异常推荐网络增长、重复 `full_discount` 使用、注册→参与突发模式 - 全局异常处理器与 ID 脱敏 - **跨对象授权策略**：`assertOwnership()` 与 `assertGroupMembership()` 作为一级原语 - 财务对账看板：用户看到的奖品池 vs 真实资金支持 - 漏洞管理计划：安全设计、CI/CD 安全测试、定期攻防评估 --- ## 12. 检测缺口分析 本次评估最重要的发现**并非单一漏洞，而是缺乏检测能力**。高影响向量（F-036、F-019、F-034、F-015）均通过请求序列实现，单独看与合法行为无异。检测需**跨端点关联**，而这在评估中并不存在。 ### 缺失的检测模式 | 模式 | 指示 | |---|---| | `register → otp/send → otp/verification → participation(full_discount)` 且 `invitationCode` 重复 | F-036 进行中 | | `statistics → standings → winners → participations` 序列在令牌下短时发生 | F-015 进行中 | | 高错误率访问 `/api/transactions/{id}`（所有权校验失败） | F-017 滥用 | | `/api/auth/refresh` 使用密码更改前的令牌 | F-023 滥用 | | `/metrics` 来自未授权 IP | F-017 前期侦察 | **操作影响**：若上述向量正在被利用，安全团队将无法在可接受时间窗口内识别。这会放大财务、声誉与合规影响——也意味着代码修复若无对应检测能力，无法被验证。 **检测必须与修复同步交付**。 --- ## 13. 经验总结 ### 关于业务逻辑测试 本次评估中最高影响的发现并非传统注入或认证绕过，而是**五个中等问题的逻辑组合**形成可货币化链条。自动化扫描器无法标记其为关键。这再次印证： > **业务逻辑层是黑盒测试回报最高的地方**，因为它最难通过代码审查推理，且对工具不可见。 ### 关于架构性 vs 端点级发现 七个 BOLA 与五个认证缺陷本质上是**两个架构缺失**的表现： - 无跨对象所有权策略 - 无凭证吊销机制 将发现以该框架呈现，使对话从“修补这些端点”转向“重构这些层”，从而获得更优修复效果。 ### 关于积极控制 记录客户已具备的九项积极控制（JWT 签名验证、OTP 速率限制、参与所有权检查等）同样重要，因为它： - 给予工程团队准确认可 - 使修复讨论可操作 - 展示“同一团队既构建强加密也遗漏 OTP 在响应中”的过程差距 ### 关于明确记录已排除假设 七个被验证并排除的假设确保评估被视作全面而非选择性，也能在修复会议中回答“但你是否试过 X？”。 ### 关于 CVSS 与业务影响 旗舰发现 CVSS 为 8.7，但实际业务影响更大——因为 CVSS 未建模货币化、可扩展性与可检测性。我会在报告中附加 **“CVSS vs 业务影响”** 说明，避免数字低估严重性。 ### 关于可观察性即攻击面 `/metrics` 作为运维端点，在本评估中却是最有用的侦察工具。一旦可访问，API 即成为攻击面。可观察性基础设施需要与功能面同等级别的授权纪律。 --- ## 14. 工具与技术栈 | 用途 | 工具 | |---|---| | Android APK 静态分析 | JADX | | HTTP 拦截与请求操作 | Burp Suite Professional | | 移动端动态调试 | Frida | | 请求重放 / PoC 验证 | Postman、curl | | 模式验证自动化 | Python（自定义脚本） | | 参考框架 | OWASP API Top 10 (2023)、MASVS、WSTG v4.2、PTES | --- ## 📎 脱敏说明 - 客户名称、产品名称、域名替换为通用占位符（`api.example.com`） - 所有 UUID 替换为 `00000000-...` 格式占位符 - 邮箱、电话、身份证、真实 OTP 替换为 `@example.com` 哑数据或 `000000` - 真实令牌替换为截断的 `eyJhbGciOi...TRUNCATED` 占位符 - 金额转换为近似美元以消除地理位置信号 - 司法辖区特定的合规引用泛化 - 发现 ID 重新编号为通用 `F-xxx`，原始内部标识已移除 - 作者身份有意不披露；若需进一步合作请直接联系 **许可声明**：本案例研究仅限作品集与教育用途。未经授权的复制不受鼓励。

标签：API安全, Fantasy Pools, JSON输出, OTP漏洞, OWASP API Top 10, REST API, TGT, 业务逻辑漏洞, 付费预测, 会话管理, 反取证, 奖励滥用, 安全评估, 平台安全, 折扣绕过, 攻防演练, 枚举攻击, 案例研究, 移动后端, 身份认证漏洞, 逆向工具, 金融流程漏洞