redirect_uri 校验为什么关键
OAuth 授权码流程里，授权码会被发往注册的回调地址。校验不严时，攻击者可以构造一个通过校验但实际指向自己域名的回调地址，把授权码拿走换取令牌。常见的宽松点有：只比对域名前缀而不比对完整路径、允许追加路径或参数、大小写与端口处理不一致、通配符域名放行。检查方式是用自有测试应用走一遍授权流程，观察不同回调参数的受理情况。
基本信息
| 检查点 | 精确匹配、路径与参数追加、通配符、大小写与端口处理 |
|---|---|
| 测试方式 | 用自有应用与自有账号走授权流程，记录受理与拒绝的边界 |
| 边界 | 只用自己的测试应用，绝不使用第三方或真实用户账号 |
| 修复方向 | 精确匹配注册地址，禁用通配；回调变更走审批 |
| 进阶建议 | 隐式流程迁移到授权码加 PKCE |
典型使用场景
- 自建身份平台的授权流程评审
- 评估单点登录接入方的回调地址管理规范
- 第三方开放平台的安全性核查（自有应用视角）
- 为令牌泄露类风险提供证据：回调是否可被劫持
- 修复验证：确认校验已改为精确匹配且错误响应不再回显有效回调
检查步骤
检查步骤
# 1. 记录自有应用注册的 redirect_uri 白名单
# 2. 在授权请求中替换或追加回调参数，观察是否受理
curl -s -o /dev/null -w '%{http_code}\n' \
'https://sso.example.com/authorize?client_id=<自有应用>&redirect_uri=https://app.example.com/cb'
curl -s -o /dev/null -w '%{http_code}\n' \
'https://sso.example.com/authorize?client_id=<自有应用>&redirect_uri=https://app.example.com/cb/../other'
# 3. 观察错误响应是否回显了服务端认可的有效回调地址
# 4. 记录受理与拒绝的边界规则（路径、参数、大小写、端口）受理情况与判断
| 受理情况 | 含义 | 处置 |
|---|---|---|
| 仅完全一致的回调受理 | 精确匹配，符合要求 | 记录为已核查 |
| 追加路径或参数被受理 | 校验不严，存在劫持风险 | 列缺陷，建议精确匹配 |
| 通配符域名被受理 | 范围过大，易被利用 | 要求收敛到具体域名与路径 |
| 错误响应回显有效回调 | 信息泄露，辅助攻击者构造 | 建议改为统一错误提示 |
修复视角：回调地址精确匹配、禁用通配符、变更走审批；公开客户端尽量使用授权码加 PKCE，避免隐式流程把令牌直接暴露在前端。
不要用公开演示应用或第三方应用做验证：会误伤其他接入方，甚至造成真实令牌泄露，只能用自有测试应用与自有账号。