Unauthenticated DoS in PyJWT via unbounded Base64URL decoding in detached JWS

漏洞概述 标题: Unauthenticated DoS via unbounded Base64URL decoding of unused payload segment in b64=false detached JWS 描述: 在验证使用 选项的未签名负载选项时，PyJWT 会在强制执行分离负载规则之前对紧凑序列化负载段进行 Base64URL 解码。对于 ，PyJWT 会丢弃解码的负载并用调用者提供的 替换它。实际上，这会在攻击者控制的“工作放大器”中替换中间段：远程客户端可以提供任意大的 Base64URL 负载段，强制 CPU 工作和内存分配，即使签名无效。这创建了一个针对任何验证分离 JWS 的未认证 DoS 向量。 影响范围 受影响组件: - - / - (解析和 Base64URL 解码) 根本原因: - 在 的 方法中，首先调用 解码令牌段，然后检查 是否为 ，如果是，则用 替换 并重建签名输入。 - 在 处理之前发生，然后 和 在之后发生。 - 在 中，PyJWT 无条件执行 ，这是攻击者可以放大的昂贵步骤。 为什么成为漏洞: - 对于 分离的 JWS，紧凑格式中的负载段在 PyJWT 的自身逻辑中实际上不需要用于验证（因为库使用 作为实际负载）。然而，PyJWT 仍然首先解码它，意味着： - 即使签名无效，成本也会支付 - 解码的字节被丢弃 - 攻击者控制此成本通过令牌长度 影响: - 安全影响: - 未认证的远程 DoS：解码工作发生在签名拒绝之前，攻击者不需要签名密钥。 - CPU 放大：Base64URL 解码时间与负载段大小线性增长。 - 内存放大：解码输出分配大型字节缓冲区（每个请求数十 MB）。 - 操作影响：请求排队/工作者在适度并发突发下饥饿。 受影响版本: - 确认受影响：PyJWT 2.12.1（从本地编辑安装和回购测试）。 - 可能受影响：所有包括分离负载支持的版本，该支持在 2.4.0 中引入（“添加对 JWS 编码和解码的分离负载支持”）。 修复方案 目标: 防止从攻击者控制的负载段中消耗未绑定的资源，该段在 分离流中未使用。 最小更改策略: - 在 中（或通过重构解析顺序），在知道是否应用 之前，不要对 进行 Base64 解码。 两个安全选项: 1. 当 时拒绝非空负载段: - 首先解析头 - 如果 为 且 非空，则在解码之前引发 - 然后验证仅使用 2. 当 时完全跳过解码负载段: - 将负载段保留为原始字节或空 - 使用分离负载作为签名输入 变通方法: - 在 HTTP 边界（代理/网关）强制执行严格的 - 在验证端点上应用速率限制 - 如果不需要分离 JWS（ ），则拒绝包含 的令牌 POC 代码 PoC #1 - 本地验证服务器 文件: 目的: 真实 HTTP 端点（POST ）调用 PyJWT 分离验证并打印：ok / time_ms / peak_bytes / token_len / error... 结果（服务器控制台输出）: 关键要点: 在 8,000,000 个字符时，单个无效签名请求仍然导致： - ~23 ms 服务器工作 - ~32 MB 峰值分配 - 返回 401（无效签名）——攻击者不需要密钥 PoC #2 - 本地网络客户端 文件: 目的: 生成基线（无效签名）+（有效签名）令牌并通过 HTTP 发送到本地主机服务器。 结果（客户端输出）: 为什么这是强证据: 服务器在拒绝无效签名之前确实做了大量工作 “有效签名”案例显示即使接受的请求也因未使用的负载段而浪费资源 PoC #3 - 本地洪水/突发并发 文件: 目的: 发送 N 并发无效签名请求通过 HTTP 以演示排队/工作者饥饿。 结果（你的运行：20 并发 @ 8,000,000 个字符）: 解释: 每个请求仍然花费 ~20-23 ms 服务器处理和 ~32 MB 峰值分配。 但客户端观察到的延迟上升到 ~1.15 秒，因为请求排队彼此之后——清晰的工作者饥饿/忙阻塞。 所有都被拒绝为 401 InvalidSignatureError——仍然未认证。

Goal Reached Thanks to every supporter — we hit 100%!

Unauthenticated DoS in PyJWT via unbounded Base64URL decoding in detached JWS

More from this source