多步骤找回密码：步骤间主体不一致 + 响应篡改
业务流程（状态机）
step1 验证手机号 → step2 绑定手机并发送短信 → step3 修改密码 → step4 完成
试验矩阵
| 动作 | 结果 | 推出的规则 | |
|---|---|---|---|
| 1 | step1 填入找到的手机号 166xxxxxxxx |
通过 | step1 只校验号码存在/格式，不校验归属，也不证明"号码属于你" |
| 2 | step2 用同一号码触发短信 | 短信发到数据库中的绑定手机，拿不到验证码 | step2 的身份来源是数据库绑定号，与 step1 的输入是两个不同概念 |
| 3 | 观察 step2 响应包 | 发现 returnkey 用于绑定会话 |
步骤之间靠一个客户端可观测的 state |
一、核心思路
- 【方法模板·非来源原文】【多步骤流程的信任模型错位（每步各自校验、步骤间主体不一致）】画状态机：每步 输入 / 服务端产出 / 会话或 token / 下一步依赖，缺一步会误判
- 来源链接: local://user-case/2026-10-20-password-reset-multistep
- 分类命中词: {'Authentication Bypass': [], 'Account Takeover': ['账号接管'], 'Authorization Bypass': ['bfla'], 'Business Logic': ['业务逻辑']}
落到 QGG 怎么用
可直接落到 QGG 的「Authentication Bypass」测试清单：【多步骤流程的信任模型错位（每步各自校验、步骤间主体不一致）】画状态机：每步 输入 / 服务端产出 / 会话或 token / 下一步依赖，缺一步会误判；可生成部分自动化规则候选（有请求级证据）
二、成立条件
- 来源未明确写出成立条件（缺失，需在验证阶段补齐）
三、验证方法与步骤
- 【方法模板·非来源原文】【多步骤流程的信任模型错位（每步各自校验、步骤间主体不一致）】画状态机：每步 输入 / 服务端产出 / 会话或 token / 下一步依赖，缺一步会误判
- 【方法模板·非来源原文】【多步骤流程的信任模型错位（每步各自校验、步骤间主体不一致）】身份来源标注：每步服务端认定的身份来自输入参数、会话 cookie、数据库、还是上一步响应？
- 【方法模板·非来源原文】【多步骤流程的信任模型错位（每步各自校验、步骤间主体不一致）】步骤跳跃与乱序：直达 step3/step4、跳过 step2、重放 step1 的响应推进 step2
- 【方法模板·非来源原文】【多步骤流程的信任模型错位（每步各自校验、步骤间主体不一致）】参数替换：在某一步替换主体标识（手机号/邮箱/uid），观察最终写入落在谁身上
- 【方法模板·非来源原文】【多步骤流程的信任模型错位（每步各自校验、步骤间主体不一致）】响应篡改：改 success/code/step/returnkey，看服务端是否采信客户端结论
- 【方法模板·非来源原文】【多步骤流程的信任模型错位（每步各自校验、步骤间主体不一致）】state token 跨主体：把 returnkey/flow_id 换到另一会话，是否跨主体生效（只读判定）
- 【方法模板·非来源原文】【多步骤流程的信任模型错位（每步各自校验、步骤间主体不一致）】终态核对：改密/改绑后用'原身份'与'目标身份'分别登录，确认到底改了谁
- 【方法模板·非来源原文】入口发现：登录/重置/SSO 回调/验证码/记住我/多因子各分支
- 【方法模板·非来源原文】测试变量：字段省略（如 captcha 整体不传）、类型污染、大小写、注释截断、响应篡改
- 【方法模板·非来源原文】成功证据：无凭据拿到受保护资源（带响应体）或进入他人账号
- 【方法模板·非来源原文】误报过滤：仅 302 到首页不算；必须验证会话真的可访问受保护页面
step1 验证手机号 → step2 绑定手机并发送短信 → step3 修改密码 → step4 完成
- 步骤间没有"同一主体"的一致性约束：step1 校验 A、step2 绑定 B、step3 改 C 的密码。
- 状态机掌握在客户端：
returnkey只在请求/响应里流转，服务端未复核它绑定的主体。
- 前端响应被当作安全边界：篡改响应即可让前端放行并进入下一步。
- 服务端为整条流程维护单一主体上下文（
flow_id+ 绑定主体，服务端存储，客户端仅持不透明引用）。
- 每一步都要校验"当前请求主体 == flow 绑定主体"，主体一旦确定不得中途变更。
- 关键结论（是否验证通过）只由服务端状态决定，不接受客户端回填。
- 验证码与目标号码强绑定；改密/改绑后强制失效旧会话与旧 token。
四、误报排除
- 【来源原文片段】可在客户端修改（潜在跨主体复用面）。 - 终态核对：改密落在 step2 的号码上而非预期账号 → 证明"每步身份解析不一致"。 反向证据 / 误报排除 - "改密成功"但登录不上，不等于漏洞打通：本例最终并未接管目标账号（改的是未注册号）。 真实定级必须做终态核对：用「原身份」和「目标身份」分
反向证据
- 可在客户端修改（潜在跨主体复用面）。 - 终态核对：改密落在 step2 的号码上而非预期账号 → 证明"每步身份解析不一致"。 反向证据 / 误报排除 - "改密成功"但登录不上，不等于漏洞打通：本例最终并未接管目标账号（改的是未注册号）。 真实定级必须做终态核对：用「原身份」和「目标身份」分
五、影响与修复
影响：
分类：Authentication Bypass；来源严重性：未提供。实际影响需以本地/授权靶场复现结果为准，评分与来源自述不构成影响结论。
修复：
统一鉴权中间件覆盖全部路由，验证码字段缺失即拒绝，禁止客户端可控的信任标记。
关联：CWE-287
六、原始来源
local://user-case/2026-10-20-password-reset-multistep
Comments | NOTHING