本文章仅用网络安全研究学习,请勿使用相关技术进行违法犯罪活动。
声明:本文搬运自互联网,如你是原作者,请联系我们!
大家好,我是漏洞赏金猎人Ashish Yadav。今天分享我在一个私有漏洞赏金项目中发现的第一个关键漏洞,它涉及JWT(JSON Web Token)的配置错误。
什么是 JWT?
JSON Web Token (JWT) 是一种用于在网络间安全传输声明的开放标准。简单来说,它是一个经过数字签名的JSON对象,常用于身份验证和授权。与传统的服务器端会话不同,JWT将用户信息(声明)直接编码在令牌里,客户端持有这个令牌,服务器通过验证签名来确认其真实性。这种无状态特性使其在分布式系统中很受欢迎。
JWT 的结构是怎样的?
一个标准的JWT由三部分组成,每部分用点号(.)连接:
- 头部 (Header):通常包含两部分信息——令牌类型(
typ,通常是“JWT”)和签名算法(alg,如HS256或RS256)。这部分会经过Base64Url编码。
{
"alg": "RS256",
"typ": "JWT"
}
- 有效载荷 (Payload):包含实际的声明,比如用户ID(
sub)、角色(role)、令牌签发时间(iat)和过期时间(exp)等。这部分同样经过Base64Url编码,但并未加密,意味着任何人都可以解码查看其中的内容。
{
"sub": "12345",
"email": "user@example.com",
"role": "user",
"iat": 1710000000,
"exp": 1710003600
}
- 签名 (Signature):这是JWT安全性的核心。签名通过将编码后的头部和有效载荷,加上一个密钥(secret),使用头部指定的算法(如HMAC SHA256)计算得出。签名用于验证消息在传输过程中未被篡改,并确认发送者的身份。
signature = sign(
base64url(header) + "." + base64url(payload),
secret_or_private_key
)
最终,完整的JWT看起来像这样:Header.Payload.Signature。

漏洞发现与复现过程
在一次对目标子域名(假设为 target.example.com)的常规侦察中,经过数小时的测试,我最终发现了一个严重的权限提升漏洞。问题的核心在于服务器错误地处理了JWT的签名算法。
重现步骤
- 注册账户:在目标站点
https://target.example.com/ 使用任意有效邮箱和密码注册一个新账户。
- 验证邮箱:通过邮件中的验证链接激活账户。
- 拦截登录请求:使用刚注册的凭证登录,并利用Burp Suite拦截登录请求。
- 查看响应:在Burp Suite中,右键点击拦截到的请求,选择
Do Intercept -> Response to this request。
- 定位JWT:在服务器的登录响应中,从响应正文里找到并复制下发的JWT令牌。
- 解码分析:访问
https://jwt.io ,将复制的JWT粘贴进去,查看其头部和有效载荷内容。
- 篡改有效载荷:在解码出的有效载荷(Payload)中,找到表示角色的字段,将其值从
"role":"user" 修改为 "role":"admin"。
- 篡改算法:这是关键一步。在头部(Header)中,将签名算法从
"alg":"RS256" 修改为 "alg":"HS256"。
- 生成新令牌:
jwt.io 会根据你的修改,在右侧生成一个新的、伪造的JWT令牌字符串,将其复制。
- 替换令牌:回到Burp Suite,拦截一个需要身份认证的请求(或者重放登录响应),将请求头(通常是
Authorization: Bearer <原令牌>)或响应体中的原始JWT替换为刚才伪造的新令牌。
- 转发请求:放行这个被篡改的请求。
- 验证结果:此时,服务器错误地使用HS256算法(对称加密,使用公钥作为密钥)验证了我们篡改后的签名,从而认可了我们伪造的“admin”角色。成功访问管理员面板,完成权限提升。
漏洞原理:这个漏洞属于 JWT算法混淆攻击。服务器原本使用RS256算法(非对称加密,使用私钥签名,公钥验证)。攻击者将算法声明改为HS256(对称加密,使用密钥签名和验证),并利用服务器暴露的公钥作为HS256的密钥,重新计算签名。服务器在验证时,误以为仍在使用HS256,并尝试用公钥去验证签名,导致验证通过。
漏洞影响与结果
成功利用此漏洞,攻击者可以在没有管理员凭证的情况下,将任意普通用户账户的权限提升至管理员级别。这可能导致敏感的个人身份信息(PII)、内部业务数据甚至整个后台控制系统被泄露或接管。

我及时向漏洞赏金平台提交了详细的漏洞报告。平台团队验证后,将此漏洞评级为 最高优先级(P1),并支付了相应的高额赏金。

这个案例清晰地展示了JWT实现不当可能带来的巨大风险。对于开发者而言,在验证JWT签名时,必须严格校验算法头(alg)是否与预期一致,绝不能信任客户端传来的算法声明。对于安全研究者而言,理解各种认证机制的潜在弱点,是进行有效漏洞复现和安全测试的基础。希望这个分享对大家有所启发。
|