两层中间件授权判定与资源路径脱钩（/api/ann* + ../ 绕过）
业务与架构推断
前端 → openresty → Express（X-Powered-By: Express 实锤）→ 内部 inventory 服务。 Express 里有一条通配路由把 /api/ann* 转发到内部 /inventory/agedObjects/； 错误写法（用户推断，形态高度吻合）：
app.get('/api/xxouncement/:id', async (req, res) => { const url = BASE + '/inventory/xxxxObjects/' + req.params.id; const r = await fetch(url, { headers: { Authorization: SERVICE_AC
一、核心思路
- 【方法模板·非来源原文】【多参数联合校验失效（参数互串/凭证自证）】参数角色标注：对象标识(orderId)/凭证(codeId/uuid)/签名/状态，逐个标清
- 来源链接: local://user-case/2026-10-27-middleware-path-bypass
- 分类命中词: {'Authorization Bypass': [], 'Path Traversal / LFI': ['../'], 'Information Disclosure': ['敏感信息'], 'IDOR / BOLA': ['越权']}
落到 QGG 怎么用
可直接落到 QGG 的「Authorization Bypass」测试清单：【多参数联合校验失效（参数互串/凭证自证）】参数角色标注：对象标识(orderId)/凭证(codeId/uuid)/签名/状态，逐个标清；可生成部分自动化规则候选（有请求级证据）
二、成立条件
- 来源未明确写出成立条件（缺失，需在验证阶段补齐）
三、验证方法与步骤
- 【方法模板·非来源原文】【多参数联合校验失效（参数互串/凭证自证）】参数角色标注：对象标识(orderId)/凭证(codeId/uuid)/签名/状态，逐个标清
- 【方法模板·非来源原文】【多参数联合校验失效（参数互串/凭证自证）】单参数消融：删/空/错类型/重复参数，记录错误文案差异，建立'什么是必需'基线
- 【方法模板·非来源原文】【多参数联合校验失效（参数互串/凭证自证）】参数互串：把 A 参数的值塞进 B 参数的槽位（codeId=orderId）；再试 A=B 同时同步递增
- 【方法模板·非来源原文】【多参数联合校验失效（参数互串/凭证自证）】关系判定：只改一个 vs 两个同步改，结果差异说明校验是'逐个校验'还是'关系校验'
- 【方法模板·非来源原文】【多参数联合校验失效（参数互串/凭证自证）】凭证强度：UUID 是否出现在 JS/其他接口/响应里（泄露即等于无凭证）
- 【方法模板·非来源原文】【多参数联合校验失效（参数互串/凭证自证）】枚举可行性：对象 ID 是否顺序/自增/时间戳；只读 1-2 条他人实证即止
- 【方法模板·非来源原文】【多步骤流程的信任模型错位（每步各自校验、步骤间主体不一致）】画状态机：每步 输入 / 服务端产出 / 会话或 token / 下一步依赖，缺一步会误判
- 【方法模板·非来源原文】【多步骤流程的信任模型错位（每步各自校验、步骤间主体不一致）】身份来源标注：每步服务端认定的身份来自输入参数、会话 cookie、数据库、还是上一步响应？
- 【方法模板·非来源原文】【多步骤流程的信任模型错位（每步各自校验、步骤间主体不一致）】步骤跳跃与乱序：直达 step3/step4、跳过 step2、重放 step1 的响应推进 step2
- 【方法模板·非来源原文】【多步骤流程的信任模型错位（每步各自校验、步骤间主体不一致）】参数替换：在某一步替换主体标识（手机号/邮箱/uid），观察最终写入落在谁身上
- 【方法模板·非来源原文】【多步骤流程的信任模型错位（每步各自校验、步骤间主体不一致）】响应篡改：改 success/code/step/returnkey，看服务端是否采信客户端结论
- 【方法模板·非来源原文】【多步骤流程的信任模型错位（每步各自校验、步骤间主体不一致）】state token 跨主体：把 returnkey/flow_id 换到另一会话，是否跨主体生效（只读判定）
- 【方法模板·非来源原文】【多步骤流程的信任模型错位（每步各自校验、步骤间主体不一致）】终态核对：改密/改绑后用'原身份'与'目标身份'分别登录，确认到底改了谁
- 【方法模板·非来源原文】【状态机跳跃 / 前置条件绕过】列出所有状态与合法转移（草稿→已提交→已支付→已发货…）
- 【方法模板·非来源原文】【状态机跳跃 / 前置条件绕过】直接请求终态接口、跳过支付/审批/实名
- 【方法模板·非来源原文】【状态机跳跃 / 前置条件绕过】重放旧的合法步骤响应（改 step 序号/时间戳）
- 【方法模板·非来源原文】【状态机跳跃 / 前置条件绕过】并发：同一资源多个请求同时到达（50-100 并发，一次性，做完即停）
- 【方法模板·非来源原文】【JS 端点扒取 → 未授权可达矩阵（把"猜"变成"枚举"）】从 JS（含 sourcemap、懒加载 chunk）提取全部 API 路径与参数，落盘接口账本
- 【方法模板·非来源原文】【JS 端点扒取 → 未授权可达矩阵（把"猜"变成"枚举"）】对每个端点做未授权探测：无 Cookie、无 Token，只发一次
- 【方法模板·非来源原文】【JS 端点扒取 → 未授权可达矩阵（把"猜"变成"枚举"）】按响应差异分桶：403/401（有鉴权）vs 200/302/405（可疑）vs 业务码差异
- 【方法模板·非来源原文】【JS 端点扒取 → 未授权可达矩阵（把"猜"变成"枚举"）】对可疑端点补参数，再判断是否真能取到数据（不是只看状态码）
- 【方法模板·非来源原文】【补丁绕过链（同一边界跑多轮；补丁只堵症状时继续打）】收集同一产品的多个公告与补丁，按时间排成时间线，标出每次修的是什么
- 【方法模板·非来源原文】【补丁绕过链（同一边界跑多轮；补丁只堵症状时继续打）】判断补丁修的是根因还是过滤规则：只加黑名单/正则 → 尝试编码、大小写、分隔符变异
- 【方法模板·非来源原文】【补丁绕过链（同一边界跑多轮；补丁只堵症状时继续打）】复现前一版 PoC，再试绕过写法；每轮都保留'补丁前可用/补丁后不可用/绕过可用'三条证据
- 【方法模板·非来源原文】【多参数联合校验（凭证自证/参数互串）】参数角色标注：对象标识 / 凭证 / 签名 / 状态
- 【方法模板·非来源原文】【多参数联合校验（凭证自证/参数互串）】单参数消融（删/空/错类型）建立基线；再只改对象 ID（通常会被拒——这是陷阱）
- 【方法模板·非来源原文】【多参数联合校验（凭证自证/参数互串）】把对象 ID 填进凭证槽（codeId=orderId）；再试两参数同步递增
- 【方法模板·非来源原文】【多参数联合校验（凭证自证/参数互串）】判定授权到底绑在哪个参数上：会话主体？还是两者一致性？
- 【方法模板·非来源原文】【多步骤流程身份错位（step 间主体不一致 / 响应篡改 / 终态核对）】画状态机：每步输入 / 服务端产出 / token / 下一步依赖
- 【方法模板·非来源原文】【多步骤流程身份错位（step 间主体不一致 / 响应篡改 / 终态核对）】标注每步'服务端认定的身份'来自参数、cookie、数据库还是上一步响应
- 【方法模板·非来源原文】【多步骤流程身份错位（step 间主体不一致 / 响应篡改 / 终态核对）】步骤跳跃/乱序/重放；某步替换主体标识；篡改 success/step/returnkey
- 【方法模板·非来源原文】【多步骤流程身份错位（step 间主体不一致 / 响应篡改 / 终态核对）】终态核对：改完用'原身份'与'目标身份'分别登录，确认到底改了谁
- 【方法模板·非来源原文】【把发现变成可枚举规则（高信号检测）】提取判据：什么响应差异能区分'可达/不可达'、'有数据/空壳'
- 【方法模板·非来源原文】【把发现变成可枚举规则（高信号检测）】把判据写成可批量执行的最小请求（不含写操作）
- 【方法模板·非来源原文】【把发现变成可枚举规则（高信号检测）】先在小样本上验证假阳性率，再放大；所有批量只读
- 【方法模板·非来源原文】【HTTP 方法覆盖/OPTIONS 绕过鉴权】对受保护端点做方法矩阵：GET/POST/PUT/DELETE/OPTIONS/HEAD/PATCH 各一次，记录状态与响应体差异
- 【方法模板·非来源原文】【HTTP 方法覆盖/OPTIONS 绕过鉴权】试方法覆盖头：X-HTTP-Method-Override / X-Method-Override / _method 参数
- 【方法模板·非来源原文】【HTTP 方法覆盖/OPTIONS 绕过鉴权】对比响应体而不只是状态码（部分网关 OPTIONS 返回 200 + 真实数据）
- 【方法模板·非来源原文】【HTTP 方法覆盖/OPTIONS 绕过鉴权】同族横向：同网关下其他路径是否同样绕过
- 【方法模板·非来源原文】入口发现：低权账号可达的管理/后台接口清单（菜单隐藏但接口存在）
- 【方法模板·非来源原文】前置条件：低权账号 + 高权接口路径（从 JS 路由表与前端菜单反推）
- 【方法模板·非来源原文】测试变量：角色标识、方法切换、路径大小写/分号/双写/编码变体
- 【方法模板·非来源原文】成功证据：高权操作返回真实数据或真实状态变更（写后重读确认）
- 【方法模板·非来源原文】误报过滤：仅返回 403/401 不算；统一网关码需先做不存在路径对照
- 授权判定点与资源真正所在点分离：鉴权在 Express 入口按"公告"语义放行，
:id未归一化：req.params.id直接拼进转发 URL，../、%2f..%2f、
- 通配路由（
/api/ann*）让命中面比预期宽。
四、误报排除
- 【来源原文片段】规范化行为不一致， 最终落在集合接口上（不只是单条）。 3. 通配路由（
/api/ann*）让命中面比预期宽。 反向证据 / 误报排除 - 直连 403 说明资源有授权控制，不是"裸奔"——绕过点在转发链，不是目标服务没鉴权。 - 必须证明响应体是他人/内部主体数据（sel
反向证据
- 规范化行为不一致， 最终落在集合接口上（不只是单条）。 3. 通配路由（
/api/ann*）让命中面比预期宽。 反向证据 / 误报排除 - 直连 403 说明资源有授权控制，不是"裸奔"——绕过点在转发链，不是目标服务没鉴权。 - 必须证明响应体是他人/内部主体数据（sel
五、影响与修复
影响：
分类：Authorization Bypass；来源严重性：未提供。实际影响需以本地/授权靶场复现结果为准，评分与来源自述不构成影响结论。
修复：
统一在服务端做功能级授权（角色-接口映射），并对高危接口做二次鉴权。
关联：CWE-863
六、原始来源
local://user-case/2026-10-27-middleware-path-bypass
Comments | NOTHING