type
status
date
slug
summary
tags
category
icon
password
😀
前言： 在某一次ctf比赛中遇到了这个CVE漏洞，也算是比较常见的一个漏洞，网上也有许多学习分享。写下此篇文章，仅为学习笔记。 参考文章： https://blog.csdn.net/qq_45766062/article/details/121412607 https://blog.csdn.net/qq_70303095/article/details/134105948 https://ruanyifeng.com/blog/2018/07/json_web_token-tutorial.html https://blog.csdn.net/weixin_53090346/article/details/134277438 https://www.secpulse.com/archives/193450.html

JWT

什么是JWT

JWT（JSON Web Tokens）是一种常用的身份验证和授权机制，它允许安全地在双方之间传输信息。JWT 可以在用户和服务之间安全地传输信息，并且因其轻量级和可扩展性而广泛使用。
JWT 由三部分组成：头部（Header）、载荷（Payload）和签名（Signature）。其中，头部通常包含令牌的类型和所用的加密算法，载荷包含了令牌的声明（如用户身份信息、权限等），签名用于验证令牌的真实性。
 

JWT的数据结构

头部-Header

描述JWT源数据的JSON对象

有效载荷-Payload

也是一个 JSON 对象，用来存放实际需要传递的数据。JWT 规定了7个官方字段，供选用;也可以在这个部分定义私有字段

签名-Signature

是对前两部分的签名加密，防止数据篡改。
需要指定一个密钥（secret_key）。这个密钥只有服务器才知道，不能泄露给用户。然后，使用 Header 里面指定的签名算法（默认是 HMAC SHA256），按照下面的公式产生签名。
（注意此处是SHA，不是MD5，笔者在此处踩过坑）
JWT 作为一个令牌（token），某些场合可能会放到 URL（比如 example.com/?token=xxx），抓包即可见，可作进一步判断。
 
关于base64Url
如上，头部（Header）和有效载荷（Payload）串行化的算法是Base64Url。这个算法跟Base64算法相似，但有所不同。JWT作为一个token令牌，有些场合会放到URL中（e.g. api.example.com/?token=xxx）。而Base64有三个字符+、/、=，在URL中有特殊含义，所以要被替换掉，+替换成-，/替换成_，=被省略。
 

JWT使用流程

  1. 用户认证
      • 登录验证：用户通过用户名和密码等凭证向服务器发起登录请求
      • 生成JWT：服务器验证用户的凭证无误后，会生成一个JWT。JWT通常包含三部分：头部（Header）、载荷（Payload）和签名（Signature）。头部包含有关签名算法的信息，载荷携带用户信息（如用户ID、角色、过期时间等），签名则是基于前两部分和一个密钥计算得出，确保JWT不被篡改。
  1. 客户端接收与存储
      • 服务器将生成的JWT返回给客户端（可以通过HTTP响应的Body或Cookie）。
      • 客户端（如Web浏览器、移动应用）接收到JWT后，通常会将其存储在本地（如LocalStorage、SessionStorage或Secure Cookie中），以便后续请求时使用。
  1. 请求附带JWT
      • 发送JWT：在客户端发起后续请求时，JWT会被附加在HTTP请求中，常见的做法是放在Authorization头部，格式为 Bearer {token}。
  1. 服务器验证JWT
      • 验证签名与有效性：服务器接收到带有JWT的请求后，会验证JWT的签名是否正确（确保JWT未被篡改），同时检查JWT的有效期、是否撤销等，以决定是否继续处理请求。
      • 提取用户信息：验证成功后，服务器可以从JWT的载荷中提取用户信息，用于授权判断，决定用户是否有权限访问请求的资源。
  1. 访问控制与授权
      • 根据JWT载荷中的信息，服务器实施细粒度的访问控制，如判断用户角色是否允许访问特定资源。
notion image
 

JWT的特点

  • JWT包含了所有必要的用户信息和认证数据，一旦签发，在有效期内，所有需要验证JWT的服务都不需要查询数据库或进行额外的后端验证。这意味着JWT自身携带了验证用户身份及权限所需的所有数据。
  • 服务器无需存储JWT的会话信息，降低了服务器的存储负担，提高了可扩展性。每次客户端请求都携带JWT，服务器仅需验证JWT的有效性即可。
  • JWT默认不加密，但可以选择对JWT的Payload部分进行加密，以保护敏感数据。
  • 可以设置过期时间（Expiration Time）
  • JWT最大的缺点：服务器不保存session状态，因此无法在使用过程中废止某个token，或者更改token权限。一旦JWT被发出，在有效期内都是有效的，服务器无法直接废止一个已经发出的JWT，除非服务器部署额外的逻辑、使用黑名单或其他外部机制。
  • 如果签名密钥泄露，JWT可能被伪造，因此密钥的安全管理至关重要。
  • 不适合存放大量数据，应仅包含验证和授权所必需的信息。
  • 为了减少盗用，JWT 不应该使用 HTTP 协议明码传输，要使用 HTTPS 协议传输。
（敏感信息、用户身份和权限、时间限制、存储点）
 

JWT的安全问题，

  1. 修改算法为none（一些JWT库默认支持不安全的签名算法，如HMAC使用的”none”算法，攻击者可生成未签名的JWT，伪造有效的JWT）
  1. 修改算法从RS256到HS256
  1. 信息泄漏 密钥泄漏
  1. 爆破密钥
  1. 令牌劫持（通过中间人攻击（MITM）或XSS，截获JWT并在有效期内使用该令牌进行未授权操作）
  1. 存在的漏洞: CVE-2015-9235 Alg：无攻击 CVE-2016-5431密钥混淆攻击 CVE-2018-0114密钥注入攻击 其他已知攻击 JWKS欺骗 “kid”注射 跨服务中继攻击 弱密钥……
 

JWT的攻击利用

  • 伪造任意JWT(密钥泄露)，绕过认证或提权
  • 敏感信息泄露
  • 捕获并重复利用有效的JWT（未实现防重放机制）
 
 
 
 
 
相关文章
记一次简单的非域间横向移动练习_PPT
书籍是人类进步的阶梯
玄机
记一次非域间横向移动实战_PTH
非域间横向移动实战_WPAD
红日靶场（一）
记一次简单的非域间横向移动练习_PPT书籍是人类进步的阶梯