在 API 安全领域，有时一个字符就足以颠覆整个防护体系。安全研究员在一次针对某金融科技公司移动 API 的渗透测试中发现了令人震惊的现象：GET /v1/accounts 返回 401 未授权，而仅添加一个尾部斜杠的 GET /v1/accounts/ 却返回 200 OK 并暴露完整的账户数据。这一发现最终获得了 12,000 美元的漏洞赏金，同时也揭示了 AWS API Gateway HTTP API 在路径匹配与授权检查之间存在的关键安全边界断裂。
HTTP API 与 REST API 的路径匹配差异
AWS 提供两种 API Gateway 服务：历史悠久的 REST API 和相对较新的 HTTP API。后者以更低的延迟和成本吸引用户，但在路径匹配行为上存在本质差异。
REST API 采用严格的路径匹配策略，要求请求路径与配置的路由完全一致。而 HTTP API 默认启用贪婪路径匹配（greedy path matching），将配置的路径视为前缀而非精确匹配。这意味着 /v1/accounts 不仅会匹配自身，还会匹配 /v1/accounts/、/v1/accounts/123 等变体。
这种设计初衷是简化路由配置，减少重复定义相似路径的工作量。然而，当贪婪匹配与授权检查发生在不同处理阶段时，就产生了可被利用的竞态条件。
漏洞机制：授权上下文在路径重写中丢失
该漏洞的核心在于 HTTP API 处理请求时的分层架构。当请求到达网关时，系统依次执行以下操作：
首先，路由匹配层根据贪婪前缀规则确定请求对应的路由。对于 /v1/accounts/，系统识别其匹配 /v1/accounts 路由定义，触发关联的 Lambda 授权器。授权器验证 JWT 令牌并返回 IAM 策略，其中包含 context.authorizer.userId 等身份上下文。
随后，集成层接管请求处理。HTTP API 在执行集成前对路径进行规范化重写，将 /v1/accounts/ 转换为 /v1/accounts。问题恰恰出在这一步：路径重写过程中，授权器设置的上下文信息被意外丢弃。
最终，后端 Lambda 接收到重写后的路径，但 userId 字段变为 undefined。如果后端服务仅依赖 API Gateway 传递的身份上下文而不执行独立验证，就会将未认证的请求视为合法访问。
攻击复现与影响评估
研究员使用 ffuf 工具对目标 API 进行路径模糊测试，结果呈现出明显的模式：
| 请求路径 | 响应状态 | 说明 |
|---|---|---|
GET /v1/accounts |
401 Unauthorized | 正常认证要求 |
GET /v1/accounts/ |
200 OK + 数据 | 授权绕过成功 |
GET /v1/accounts// |
200 OK | 多重斜杠同样绕过 |
GET /v1/accounts?foo=bar |
401 Unauthorized | 查询参数不改变认证要求 |
GET /v1/accounts%2f |
404 Not Found | URL 编码斜杠不匹配 |
更令人担忧的是，同样的绕过方式适用于敏感操作端点。POST /v1/transfers/ 在未提供有效 JWT 的情况下成功执行了转账操作。由于后端代码在 userId 为 undefined 时默认使用系统账户，攻击者实际上获得了高权限操作的执行能力。
深层原因：安全边界的职责分离失效
这一漏洞暴露了一个常见的架构误区：过度依赖网关层的统一认证。在理想的零信任架构中，每个服务层都应该独立验证安全断言。
API Gateway 的授权器确实提供了第一道防线，但它无法保证下游服务接收到的上下文完整性。路径重写、代理传递、甚至中间件处理都可能意外修改或丢弃身份凭证。当后端服务假设 "既然请求到达这里，必然已经过认证" 时，就引入了单点失效风险。
此外，HTTP API 的贪婪匹配行为虽然在文档中有说明，但其与授权检查的阶段分离并未得到充分强调。开发者在迁移从 REST API 到 HTTP API 时，往往沿用相同的安全假设，却忽略了底层实现差异。
修复方案与防御建议
针对该漏洞，受影响组织采取了双重修复策略：
架构层面：将 HTTP API 迁移回 REST API。REST API 的严格路径匹配消除了贪婪前缀带来的不确定性，确保授权检查与路由执行针对同一路径进行。
代码层面：在每个 Lambda 函数中增加 userId 存在性验证。不再假设网关传递的上下文必然有效，而是显式检查必需字段，对缺失或异常值返回 403 拒绝响应。
对于正在使用 HTTP API 的组织，建议采取以下预防措施：
- 路径规范化前置：在 API Gateway 前部署 CloudFront 或 WAF，统一将尾部斜杠请求重定向到标准形式，避免歧义匹配
- 双重验证策略：Lambda 授权器验证 JWT，后端服务独立验证
userId等关键声明 - 自动化审计：使用工具扫描所有端点的斜杠变体响应，识别潜在的授权绕过
- 最小权限原则：即使发生认证绕过，后端资源策略也应限制可访问的数据范围
总结
尾部斜杠授权绕过并非 AWS API Gateway 独有的问题，它反映了分布式系统中路径规范化与访问控制之间的普遍张力。当网关层执行路径重写时，必须确保身份上下文的原子性传递；当后端服务接收请求时，不应盲目信任上游的安全断言。
这一案例再次证明，安全架构需要在每个边界都设置验证点。单一依赖点的失效不应导致整个防护体系的崩溃。对于使用托管 API 网关服务的团队而言，深入理解不同服务类型的行为差异，并在代码层面实施防御性编程，是避免类似漏洞的关键。
参考来源
- GuptaLog: I bypassed AWS API Gateway auth with a trailing slash. Got $12K bounty
- Hacker News Discussion: Item 48256367
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。