JWT 漏洞.

JSON Web Token 承载着身份验证与授权声明,但其在头部声明签名算法的灵活性催生了几类反复出现的漏洞。alg=none 漏洞由 Tim McLean 于 2015 年披露,当验证方信任令牌自带的 alg 头,并据此分派到一个对空签名返回 true 的 "none" 验证器时便会发生——这让攻击者得以改写载荷并去掉签名。该问题在 Node 的 jsonwebtoken 4.2.2 之前的版本中得到修复(CVE-2015-9235)。

密钥混淆(CVE-2016-10555)则更为隐蔽:如果服务器同时接受 RS256 与 HS256,攻击者便可用 HMAC、以服务器的 公钥 RSA 密钥作为共享密钥来签发令牌;一个不加防范的验证器会把该公钥传入 HS256.verify(),伪造的令牌因此通过校验。相关问题还包括可用 hashcat 离线破解的弱 HS256 密钥、缺失的 exp/nbf 校验,以及头部注入汇点——kid 路径遍历或 SQL 注入,以及可被攻击者控制、指向其自有密钥的 jwk/jku/x5u 字段。2022 年,jsonwebtoken 中的 CVE-2022-23529 曾因构造的密钥对象引发对 RCE 的担忧(后因利用前提条件存在争议而被撤回)。

防御措施:在服务端固定所接受的算法,绝不从不可信输入中读取 alg;使用强非对称密钥;用白名单校验 kid;忽略内嵌的密钥 URL;强制执行过期校验;并将 JWT 的每个字段都视为敌意输入。

flowchart TD
  A[攻击者获得有效 JWT] --> B{篡改头部}
  B -->|alg 设为 none、去掉签名| C[验证器是否跳过校验?]
  B -->|RS256 改为 HS256| D[用公钥做 HMAC]
  B -->|jku / kid 指向攻击者密钥| E[对恶意密钥进行验证]
  C -->|是| F[伪造令牌被接受]
  D -->|是| F
  E -->|是| F
  F --> G[权限提升 / 认证绕过]
  C -->|固定 alg| H[被拒绝]
  D -->|固定 alg| H
  E -->|kid 白名单| H