找回密码
立即注册
搜索
热搜: Java Python Linux Go
发回帖 发新帖

2765

积分

0

好友

393

主题
发表于 17 小时前 | 查看: 0| 回复: 0

本文章仅用网络安全研究学习,请勿使用相关技术进行违法犯罪活动。

声明:本文搬运自互联网,如你是原作者,请联系我们!

大家好,我是漏洞赏金猎人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

JWT结构示意图:展示了Header、Payload、Signature三部分及其Base64编码示例

漏洞发现与复现过程

在一次对目标子域名(假设为 target.example.com)的常规侦察中,经过数小时的测试,我最终发现了一个严重的权限提升漏洞。问题的核心在于服务器错误地处理了JWT的签名算法。

重现步骤

  1. 注册账户:在目标站点 https://target.example.com/ 使用任意有效邮箱和密码注册一个新账户。
  2. 验证邮箱:通过邮件中的验证链接激活账户。
  3. 拦截登录请求:使用刚注册的凭证登录,并利用Burp Suite拦截登录请求。
  4. 查看响应:在Burp Suite中,右键点击拦截到的请求,选择 Do Intercept -> Response to this request
  5. 定位JWT:在服务器的登录响应中,从响应正文里找到并复制下发的JWT令牌。
  6. 解码分析:访问 https://jwt.io ,将复制的JWT粘贴进去,查看其头部和有效载荷内容。
  7. 篡改有效载荷:在解码出的有效载荷(Payload)中,找到表示角色的字段,将其值从 "role":"user" 修改为 "role":"admin"
  8. 篡改算法:这是关键一步。在头部(Header)中,将签名算法从 "alg":"RS256" 修改为 "alg":"HS256"
  9. 生成新令牌jwt.io 会根据你的修改,在右侧生成一个新的、伪造的JWT令牌字符串,将其复制。
  10. 替换令牌:回到Burp Suite,拦截一个需要身份认证的请求(或者重放登录响应),将请求头(通常是 Authorization: Bearer <原令牌>)或响应体中的原始JWT替换为刚才伪造的新令牌。
  11. 转发请求:放行这个被篡改的请求。
  12. 验证结果:此时,服务器错误地使用HS256算法(对称加密,使用公钥作为密钥)验证了我们篡改后的签名,从而认可了我们伪造的“admin”角色。成功访问管理员面板,完成权限提升。

漏洞原理:这个漏洞属于 JWT算法混淆攻击。服务器原本使用RS256算法(非对称加密,使用私钥签名,公钥验证)。攻击者将算法声明改为HS256(对称加密,使用密钥签名和验证),并利用服务器暴露的公钥作为HS256的密钥,重新计算签名。服务器在验证时,误以为仍在使用HS256,并尝试用公钥去验证签名,导致验证通过。

漏洞影响与结果

成功利用此漏洞,攻击者可以在没有管理员凭证的情况下,将任意普通用户账户的权限提升至管理员级别。这可能导致敏感的个人身份信息(PII)、内部业务数据甚至整个后台控制系统被泄露或接管。

管理员面板界面截图,显示文件上传等功能

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

漏洞报告界面截图,显示状态为已解决,并获得奖励

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




上一篇:应对Qt 5.15安装方式变革:离线部署与源码编译全攻略
下一篇:MT798x路由器刷机指南:编译与刷入支持Web刷机的多功能U-Boot
您需要登录后才可以回帖 登录 | 立即注册

手机版|小黑屋|网站地图|云栈社区 ( 苏ICP备2022046150号-2 )

GMT+8, 2026-1-28 19:11 , Processed in 0.368911 second(s), 42 queries , Gzip On.

Powered by Discuz! X3.5

© 2025-2026 云栈社区.

快速回复 返回顶部 返回列表