什么！JWT还能这么玩

概述

JWT（JSON Web Token）是一种开放标准（RFC 7519），用于在网络应用间安全传输信息。然而，由于实现不当，JWT 常常成为攻击者的突破口。本文将深入探讨三种最常见的 JWT 安全漏洞：弱密钥、空签名和验证缺失。

一、弱密钥漏洞

1.1 漏洞原理

JWT 使用 HMAC 算法（如 HS256）时，需要一个密钥来生成和验证签名。如果密钥强度不足（过短、常见单词、可预测），攻击者可以通过暴力破解或字典攻击获取密钥，从而伪造任意 Token。

1.2 攻击场景

原始 JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. eyJ1c2VyIjoiYWRtaW4iLCJyb2xlIjoidXNlciJ9. [签名部分]
常见弱密钥示例：

secret
123456
password
jwt
admin
空字符串 ''

1.3 漏洞挖掘方法

正常测试的时候遇到用户身份凭证使用的是JWT格式可以直接使用JWT爆破工具Tscan进行秘钥爆破

当我们爆破出来的时候，不管是否能进行利用伪造JWT，都是可以交一个JWT弱密钥的，如果能伪造成功那就是严重！

1.4 实战利用

以靶场为例，正常我们JWT如下：

通过爆破得到秘钥test123

将明文中的uid改为他人uid在加密回去进行替换就可以直接查看他人信息

二、空签名漏洞（None 算法攻击）

2.1 漏洞原理

JWT 头部中的 alg 字段指定签名算法。某些库允许使用 none 算法，表示不验证签名。攻击者可将算法改为 none 并移除签名，服务端可能错误地接受此 Token。

2.2 攻击场景

`原始 JWT 头部:
{
"alg": "HS256",
"typ": "JWT"
}

篡改后:
{
"alg": "none",
"typ": "JWT"
}`

2.3 漏洞挖掘方法

只需要将加密算法改为none，然后直接修改明文中的uid值，无需秘钥，编码回去可直接利用

三、JWT验证缺失漏洞

3.1 漏洞原理

JWT 由三段 Base64 编码组成，用 . 拼接：
Header.Payload.Signature
其中 Signature（签名）是服务器用密钥对 Header.Payload 计算出来的，用来保证中间两段没有被篡改。
正常流程下，服务器收到 JWT 后应该：
1、用自己的密钥重新计算签名
2、与 Token 中的签名对比
3、签名一致才信任 Payload 的内容
但有些服务端的实现有缺陷 —— 它只是把 JWT 做 Base64 解码，直接读取 Payload 里的字段（比如 user_id、role），但没有验证签名。
这时候攻击者可以做：
1、修改解密后的值（比如 "role": "user" 改成 "role": "admin"）
2、重新编码回去
3、拼上原来的 Signature，发给服务器。
服务器因为根本没验签，直接把伪造的数据当真了。

3.2 攻击场景

看到JWT认证的试一试

3.3 漏洞挖掘方法

解密--》改数据--》编码回去--》直接用（简单粗暴）