收据页多参数联合校验失效（orderId + codeId）
业务流程
下单 → 收到收据链接 → 打开收据查看订单详情（含收货地址、支付方式）。
入口
GET /order/receipt?orderId=12345&codeId=<uuid>
试验矩阵（每一步都是一次可复现的请求）
| 请求 | 结果 | 推出的规则 | |
|---|---|---|---|
| 1 | GET /order/receipt?orderId=12345&codeId=<my-uuid> |
200，返回自己的完整订单 | 正常基线 |
| 2 | 移除 codeId |
返回"无效代码"错误 | codeId 为必需参数；错误信息可直接观测 |
| 3 | orderId=12346&codeId=<my-uuid>（只改 ID，凭证仍是自 |
一、核心思路
- 【方法模板·非来源原文】【多参数联合校验失效（参数互串/凭证自证）】参数角色标注：对象标识(orderId)/凭证(codeId/uuid)/签名/状态，逐个标清
- 来源链接: local://user-case/2026-10-20-order-receipt-idor
- 分类命中词: {'IDOR / BOLA': ['idor', '越权']}
落到 QGG 怎么用
可直接落到 QGG 的「IDOR / BOLA」测试清单：【多参数联合校验失效（参数互串/凭证自证）】参数角色标注：对象标识(orderId)/凭证(codeId/uuid)/签名/状态，逐个标清；可生成部分自动化规则候选（有请求级证据）
二、成立条件
- 来源未明确写出成立条件（缺失，需在验证阶段补齐）
三、验证方法与步骤
- 【方法模板·非来源原文】【多参数联合校验失效（参数互串/凭证自证）】参数角色标注：对象标识(orderId)/凭证(codeId/uuid)/签名/状态，逐个标清
- 【方法模板·非来源原文】【多参数联合校验失效（参数互串/凭证自证）】单参数消融：删/空/错类型/重复参数，记录错误文案差异，建立'什么是必需'基线
- 【方法模板·非来源原文】【多参数联合校验失效（参数互串/凭证自证）】参数互串：把 A 参数的值塞进 B 参数的槽位（codeId=orderId）；再试 A=B 同时同步递增
- 【方法模板·非来源原文】【多参数联合校验失效（参数互串/凭证自证）】关系判定：只改一个 vs 两个同步改，结果差异说明校验是'逐个校验'还是'关系校验'
- 【方法模板·非来源原文】【多参数联合校验失效（参数互串/凭证自证）】凭证强度：UUID 是否出现在 JS/其他接口/响应里（泄露即等于无凭证）
- 【方法模板·非来源原文】【多参数联合校验失效（参数互串/凭证自证）】枚举可行性：对象 ID 是否顺序/自增/时间戳；只读 1-2 条他人实证即止
- 【方法模板·非来源原文】入口发现：枚举带对象标识的接口（/{id}、?id=、body 内 objectId/uid/tenantId），从 JS/路由/流量里取参数名
- 【方法模板·非来源原文】前置条件：至少一个自有账号与一个他人对象标识；确认鉴权发生在对象解析之后还是之前
- 【方法模板·非来源原文】测试变量：对象标识（顺序/随机/负数/他人真实 ID）、用户身份（低权/跨租户）、方法（GET→POST/PUT 观察差异）
- 【方法模板·非来源原文】成功证据：返回体含他人主体的真实字段值（带条数/实值），非 200 状态码本身
- 【方法模板·非来源原文】误报过滤：统一错误页、登录跳转、空壳 200、字段名相同但值为掩码
- 【方法模板·非来源原文】影响确认：只读读取为止，不做写操作；记录读取到的字段与条数
- 对象级授权：
order.user_id == session.user_id（服务端强制，不看前端隐藏）。
- 凭证由服务端签发且与对象强绑定（一次性 token，服务端存储映射），禁止对象 ID 作为凭证。
- 收据链接不要把"可推导值"当凭证：改用签名（HMAC(orderId|userId|exp)）或随机一次性 token。
- 统一错误信息，避免泄露"哪一步校验失败"，降低探测效率。
- 订单号改为不可枚举（UUID/加盐哈希），并对同一主体高频访问做限流。
- 参数角色标注：对象标识 / 凭证 / 签名 / 状态。
- 单参数消融：删、空、错类型、重复参数。
- 参数互串：A 的值填进 B 的槽位（
codeId=orderId），再试 A=B 同步递增。
四、误报排除
- 【来源原文片段】- 同一会话下未持有他人 codeId，却拿到了他人对象 → 对象级授权缺失。 - 顺序 ID 使影响面从"单条"扩大到"可枚举批量"。 反向证据 / 误报排除 - 第 3 步被拒绝：说明不是"完全不校验"，而是"校验方式可绕"——只测这一步会得到错误结论。 - 第 2 步的错误信息是业务错误而非 WAF
- 【来源原文片段】QGG 接线 - 接口账本给每个参数加
role，机械生成"参数互串矩阵"，不靠灵感。 - 报告口径：必须写清"哪种改法被拒、哪种改法通过"，否则无法排除误报。
反向证据
- - 同一会话下未持有他人 codeId，却拿到了他人对象 → 对象级授权缺失。 - 顺序 ID 使影响面从"单条"扩大到"可枚举批量"。 反向证据 / 误报排除 - 第 3 步被拒绝：说明不是"完全不校验"，而是"校验方式可绕"——只测这一步会得到错误结论。 - 第 2 步的错误信息是业务错误而非 WAF
- QGG 接线 - 接口账本给每个参数加
role，机械生成"参数互串矩阵"，不靠灵感。 - 报告口径：必须写清"哪种改法被拒、哪种改法通过"，否则无法排除误报。
五、影响与修复
影响：
分类：IDOR / BOLA；来源严重性：未提供。实际影响需以本地/授权靶场复现结果为准，评分与来源自述不构成影响结论。
修复：
在服务端对每个对象访问做主体归属校验（对象级授权），不要依赖前端隐藏或不可枚举 ID。
关联：CWE-639、OWASP API1:2023 BOLA
六、原始来源
local://user-case/2026-10-20-order-receipt-idor
Comments | NOTHING