首页 时政热点 科技头条 智能AI 安全攻防 数码硬件 开发者生态 汽车 游戏 社会热点 开源推荐 医疗健康 归档 标签 关于

利用尾斜杠绕过 AWS API Gateway 授权

摘要

安全研究员 Piyush Gupta 发现 ",在 AWS HTTP API( API Gateway 的一种更新且更经济的替代方案)的 API 路径末尾添加一个斜杠,即可完全绕过 Lambda 授权程序的身份验证。GET /v1/accounts 请求会返回 401 未授权,而 GET /v1/accounts/ 请求则会返回 200 成功,并包含完整的账户数据。

API HTTP 授权程序 Lambda AWS
2026-06-08 1 阅读 约7分钟阅读 作者:Steef-Jan Wiggers
分享:
字号:
安全研究员 Piyush Gupta 发现 ",在 AWS HTTP API( API Gateway 的一种更新且更经济的替代方案)的 API 路径末尾添加一个斜杠,即可完全绕过 Lambda 授权程序的身份验证。GET /v1/accounts 请求会返回 401 未授权,而 GET /v1/accounts/ 请求则会返回 200 成功,并包含完整的账户数据。同样的绕过方法也适用于 POST /v1/transfers/ 请求,这使得 Gupta 无需有效的 JWT 即可发起电汇。 问题的根本原因在于两个独立决策的 HTTP API 层之间路径规范化机制不一致。路由匹配层负责判断路径是否存在,而授权层则负责判断请求是否被允许。这两个层对“匹配”的定义存在分歧。 Gupta 解释 "说: HTTP API 默认采用贪婪路径匹配。/v1/accounts/ 会匹配成以 /v1/accounts 为前缀的路由。授权程序运行并返回了 Allow 状态码。随后执行集成流程,但集成映射存在模糊性。路径被重写,授权上下文被丢弃,结果就是我竟在没有有效 JWT 的情况下进入了系统内部。 对于任何使用 HTTP API Lambda 授权程序的团队来说,都很有必要了解下其工作原理。授权程序会在经过身份验证的请求中设置 context.authorizer.userId 字段。后端 Lambda 会通过读取该字段来控制数据访问范围。当路径末尾带有斜杠的请求到达集成点时,userId 字段被设为 undefined。后端并未单独验证该字段,而是信任授权程序已经做了妥当的设置。由于 userId 为 undefined,集成点默认使用系统账户,进而返回了所有数据。 通过使用 ffuf " 对路径进行模糊测试,证实了这一行为: 这家金融科技公司次日便解决了该问题,具体做法是将 HTTP API 切换为 REST API(后者对路径匹配的要求更为严格),并在每个 Lambda 函数中添加了 userId 验证,而非仅依赖授权程序。在 Reddit " 上,Gupta 提供了重现步骤,供各团队验证其自身的 API 是否受到了影响: 如果你想复现这个问题,请创建一个使用 Lambda 授权程序的 HTTP API,分别带尾斜杠和不带尾斜杠地调用该路由,然后在集成 Lambda 中检查 event.requestContext.authorizer。不带尾斜杠时该属性会存在,带尾斜杠时则不存在。这就是问题所在。 一位 Reddit 评论者补充了关于 HTTP API 发展轨迹的背景信息,团队在开发时应考虑到这一点: 虽然这个 API 比较新,但其开发工作早在 4、5 年前就已经悄然暂停了。据说是因为其内部基本架构存在问题,所以他们决定停止对新功能的投入。 如果情况属实,那些出于成本考虑而选择 HTTP API 而非 REST API 的团队,就应该权衡一下,该产品是否可能针对此类路径匹配行为进行修复。 这并非一个孤立的漏洞类型。2026 年 3 月, CVE-2026-33186 " 披露了 gRPC-Go 中存在几乎相同的漏洞模式:当服务器接收到省略了强制性前导斜杠的 :path 伪头部请求,并成功将其路由到正确的处理程序时,授权拦截器对原始的非规范化路径进行了评估,但未能匹配到拒绝规则。修复方案是在请求到达授权层之前,直接拒绝任何包含非规范化路径的请求,这一原则同样适用于本案例。 AWS API Gateway 中的尾斜杠问题并非什么新鲜事。2024 年, 一个 AWS re:Post 讨论帖 "就曾经记录过这种路径剥离行为,而 AWS Chalice " 框架早在 2018 年就对其本地开发模式进行了修补,以适应 API Gateway 对尾斜杠的处理方式。这次的新发现在于,有人证明了路径匹配与授权机制之间的不一致性不仅会导致路由混乱,还能被利用来完全绕过身份验证。 在 Hacker News " 上,这场争论不出所料地分成了两派:一派认为这是配置错误,另一派则认为这是平台设计问题。其中一位评论者认为责任在于亚马逊云科技: 我最讨厌别人这么说,仿佛有什么情况我会希望 AWS API 网关这么做似的,更别说是不小心弄成这样了。HTTP 里到处都是这种“自伤陷阱”,带斜杠和不带斜杠的区别就是个典型的例子。一款优秀的软件应该让这种误操作难以发生,而且最好默认,无论是否带尾斜杠行为都保持一致。 还有人指出,这种模式比亚马逊云科技的历史要久远得多: 几十年前,在我第一份工作的时候。当时我无法在笔记本电脑上更新某个内容,因为客户的网关屏蔽了 http://foo.com/update.exe。猜猜怎么着?http://foo.com/update.exe? 居然能绕过屏蔽。 对于使用 AWS HTTP API 并搭配使用 Lambda 授权程序的团队,应立即采取以下措施:检查受保护路由的尾斜杠变体是否会返回不同的响应;确保后端 Lambda 函数单独验证授权上下文字段,而非仅依赖授权程序作为唯一的守门人;对于安全性敏感的端点,考虑一下 REST API 更严格的路径匹配是否更为合适,尽管其成本更高且性能较低。 原文链接: https://www.infoq.com/news/2026/06/aws-api-gateway-auth-bypass/ "
这篇文章对您有帮助吗?

订阅66必读

每日精选科技资讯,直达你的邮箱