文章目录
- [一、JWT (json web token)安全](#一、JWT (json web token)安全)
-
- [1. Cookie（放在浏览器）](#1. Cookie（放在浏览器）)
- [2. Session（放在服务器）](#2. Session（放在服务器）)
- [3. Token](#3. Token)
- [4. JWT (json web token)](#4. JWT (json web token))
-
- [4.1 头部](#4.1 头部)
-
- [4.1.1 alg](#4.1.1 alg)
- [4.1.2 typ](#4.1.2 typ)
- [4.2 payload](#4.2 payload)
- [4.3 签名](#4.3 签名)
- [4.4 通信流程](#4.4 通信流程)
- [5. 防御措施](#5. 防御措施)
- 二、漏洞实例（webgoat）
-
- [1. 第四关](#1. 第四关)
- [2. 第五关](#2. 第五关)
- [3. 第七关](#3. 第七关)
一、JWT (json web token)安全
1. Cookie（放在浏览器）
cookie由服务器生成，发送给浏览器，浏览器把cookie以kv形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该cookie发送给服务器。由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的cookie数量是有限的
2. Session（放在服务器）
session从字面上讲，就是会话。这个就类似于你和一个人交谈，你怎么知道当前和你交谈的是张三而不是李四呢？对方带定有某种特征（长相等）表明他就是张三。
session也是类似的道理，服务器要知道当前发请求给自己的是谁。为了做这种区分，服务器就要给每个客户端分配不同的身份标识"，然后客户端每次向服务器发请求的时候，都带上这个"身份标识"，服务器就知道这个请求来自于谁了。至于客户端怎么保存这个"身份标识"，可以有很多种方式，对于浏览器客户端，大家都默认采用cookie的方式。
服务器使用session把用户的信息临时保存在了服务器上，用户离开网站后session会被销毁。这种用户信息存储方式相对cookie来说更安全，可是session有一个缺陷：如果web服务器做了负载均衡，那么下一个操作请求到了另一台服务器的时候session会丢失。
3. Token
在Web领域基于Token的身份验证随处可见.在大多数使用Web API的互联网公司中，tokens是多用户下处理认证的最佳方式。
以下几点特性会让你在程序中使用基于Token的身份验证
- 无状态、可扩展
- 支持移动设备
- 跨程序调用
- 安全
4. JWT (json web token)
JWT(JSON Web Token)由三部分组成：头部(Header)、载荷(Payload)、签名(Signature）:
头部(Header):
头部通常由两部分组成，算法类型和令牌类型。
算法类型：指定用于生成签名的算法，例如HMAC、RSA或者ECDSA。
令牌类型：指定令牌的类型，常见的是JWT
头部使用Base64Url编码表示，并作为整个JwT的第一部分。头部的一个示例：
{
"alg":"Hs256",none #默认alg是未加密的，加上none后不加密
"typ":"JwT"
}
载荷(Payload):
载荷存储了有关用户或实体的声明和其他有关信息。
声明：如用户ID、角色、权限等信息
注册声明：包含一些标准的声明（比如发行人、过期时何等）和一些自定义的声明。
载荷也使用Base64Url编码表示，并作为整个JWT的第二部分。载荷的一个示例：
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}
签名（Signature）：
签名是对头部和载荷进行签名的结果，用于验证 JWT 的完整性和真实性。
签名生成方式：将头部和载荷进行 Base64Url 编码后拼接在一起，然后使用指定的加密算法（如 HMAC、RSA）进行签名，将生成的签名添加到 JWT 中。
4.1 头部
4.1.1 alg
是说明这个 JWT 的签名使用的算法的参数，常见值用 HS256（默认），HS512 等，也可以为
None。HS256 表示 HMAC SHA256。
4.1.2 typ
说明这个 token 的类型为 JWT
4.2 payload
payload载荷就是存放有效信息的地方。这个名字像是特指飞机上承载的货品，这些有效信息包含三个部分
- 标准中注册的声明
- 公共的声明
- 私有的声明
标准中注册的声明（建议但不强制使用）：
- iss：jwt签发者
- sub：jwt所面向的用户
- aud：接收jwt的一方
- exp：jwt的过期时间，这个过期时间必须要大于签发时间
- nbf：定义在什么时间之前，该jwt都是不可用的.
- iat：jwt的签发时间
- jti：jwt的唯一身份标识，主要用来作为一次性token,从而回避重放攻击。
4.3 签名
服务器有一个不会发送给客户端的密码（secret），用头部中指定的算法对头部和声明的内容用此密码进行加密，生成的字符串就是 JWT 的签名
4.4 通信流程
第一步：使用用户名和密码进行登录
第二步：服务器认证成功后创建一个加密的 JWT的cookie
第三步：服务器返一个 JWT给浏览器
第四步：浏览器发送 JWT给服务器
第五步：服务器检查 JWT，从JWT中获取用户信息
第六步：服务器向客户端发送响应
5. 防御措施
- 使用强大的密钥和算法：选择足够强大的加密算法和密钥长度，如HMAC-SHA256或RSA-2048等。使用长而随机的密钥可以增加JWT的安全性，并提高防止暴力破解和字典攻击的能力。
- 令牌有效期限制：设置合理的令牌过期时间。较短的过期时间可以减少令牌被滥用的风险。定期刷新和更新过期的令牌可以确保令牌的时效性和安全性。
- 验证令牌签名和完整性：在接收到JWT后，验证令牌的签名和完整性以确保其真实性。检查签名时使用的密钥和算法必须与发放JWT的一方保持一致。
- 避免在JWT中存储敏感信息：尽量避免在JWT的载荷中存储敏感信息，如密码、社会安全号码等。如果必须存储敏感信息，应使用加密技术对其进行加密。
- 加密敏感信息：如果需要在JWT中传输敏感信息，应使用加密算法对其进行加密。在加密前，确保选择合适的加密算法，并采取适当的密钥管理措施，确保加密信息的安全性。
- HTTPS传输：始终使用HTTPS来传输JWT，以保护令牌在传输过程中的安全性。HTTPS提供了端到端的加密传输，防止令牌被窃听或篡改。
- 令牌刷新和撤销机制：实施令牌刷新和撤销机制，以应对丢失、泄露或被盗用的令牌。可以使用黑名单、短有效期令牌或存储令牌的数据库来实现这些机制。
- 令牌审计和监控：建立令牌审计和监控系统，对令牌的使用进行监测和追踪。这有助于及时发现任何异常活动或未经授权的令牌使用。
- 密钥安全管理：安全地管理和存储用于签名和验证JWT的密钥。密钥应该存放在受保护的环境中，访问权限应限制在必要的人员范围内。
二、漏洞实例（webgoat）
启动靶场
java -jar webgoat-server-8.1.0.jar --server.port=8888 --server.address=本机ip
注意大小写
访问
127.0.0.1:8888/WebGoat
1. 第四关
页面给出的要求是成为管理员，并重置投票结果
点击小人像选择一个用户，再点击删除键。然后使用bp抓包
获得 JWT：
eyJhbGciOiJIUzUxMiJ9.eyJpYXQiOjE2OTU0NzI3OTYsImFkbWluIjoiZmFsc2UiLCJ1c2VyIjoiVG9tIn0.P0RGe6YEKWHBk22JJ3ug9kbWxcb97Ca8mLVV_EQza5AjvkVS6RsKRwitBqnx--WLRBdHbmwN_zPySBDK_MIKjw
使用jwt.io解密 JWT
使用JSON校验格式化工具将修改过的 JWT 数据（payload中admin 修改为 true，header中加密方式修改为 none）进行base64加密
修改payload内容并进行加密
修改过内容的payload经过base64加密的结果要在两点之间，两点不可删除
**注意：**不要删除或修改原有格式
修改header内容并进行加密
修改过内容的header经过base64加密的结果要在点之前，点不可删除
因为头部的加密方式改为了none，那么签名就没有意义了。舍弃签名将修改过的JWT复制到bp的数据包中。注意payload和签名之间的点不能丢弃
ewogICJhbGciOiAibm9uZSIKfQ.ewogICJpYXQiOiAxNjk1NDcyNzk2LAogICJhZG1pbiI6ICJ0cnVlIiwKICAidXNlciI6ICJUb20iCn0.
2. 第五关
题目要求在给出的令牌中找到密钥，改变用户为WebGoat并使用找到的密钥加密签名
在页面中点击F12，选中给出的令牌
eyJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJXZWJHb2F0IFRva2VuIEJ1aWxkZXIiLCJhdWQiOiJ3ZWJnb2F0Lm9yZyIsImlhdCI6MTY5NDYxMzY3MSwiZXhwIjoxNjk0NjEzNzMxLCJzdWIiOiJ0b21Ad2ViZ29hdC5vcmciLCJ1c2VybmFtZSI6IlRvbSIsIkVtYWlsIjoidG9tQHdlYmdvYXQub3JnIiwiUm9sZSI6WyJNYW5hZ2VyIiwiUHJvamVjdCBBZG1pbmlzdHJhdG9yIl19.TMb4Of0VRzFWfyVtmpxCVpLIrrmKwnAPM-7juWw9_qA
将令牌复制到jwt.io中解密
在Unix时间戳中修改 exp 有效时间
1694697596
爆破密钥
将题目给出的令牌复制到桌面下的 jwt.txt 中，并子啊桌面下创建密码字典 1.txt 内容包含（victory）
使用命令爆破密钥
SH
hashcat -m 16500 jwt.txt -a 3 -w 3 1.txt
#-m 16500 ：这里的 16500 对应的就是 jwt 的 token 爆破；
#-a 3 ：代表蛮力破解
#-w 3 ：可以理解为高速破解，就是会让桌面进程无响应的那种高速
#jwt.txt ：是我把题目要求破解的 token 保存到的文件
#pass.txt ：密码字典获得密钥：victory
使用爆破出的密钥加密签名
将得出的结果提交
eyJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJXZWJHb2F0IFRva2VuIEJ1aWxkZXIiLCJhdWQiOiJ3ZWJnb2F0Lm9yZyIsImlhdCI6MTY5NDYwODEwNywiZXhwIjoxNjk0Njk3NTk2LCJzdWIiOiJ0b21Ad2ViZ29hdC5vcmciLCJ1c2VybmFtZSI6IldlYkdvYXQiLCJFbWFpbCI6InRvbUB3ZWJnb2F0Lm9yZyIsIlJvbGUiOlsiTWFuYWdlciIsIlByb2plY3QgQWRtaW5pc3RyYXRvciJdfQ.hsPDzQ945fDfLUcMzDUQViFTfohikcXicLFHovNdGNk
3. 第七关
题目要求让tom付款
点击付款使用bp抓包
点击here获取日志，从日志中获取jwt
eyJhbGciOiJIUzUxMiJ9.eyJpYXQiOjE1MjYxMzE0MTEsImV4cCI6MTUyNjIxNzgxMSwiYWRtaW4iOiJmYWxzZSIsInVzZXIiOiJUb20ifQ.DCoaq9zQkyDH25EcVWKcdbyVfUL4c9D4jRvsqOqvi9iAd4QuqmKcchfbU8FNzeBNF9tLeFXHZLU4yRkq-bjm7Q
使用jwt.io解码
修改exp和加密方法
修改头中的加密方法
修改exp
因为加密方式为none那么签名就可以舍弃了
ewogICJhbGciOiAibm9uZSIKfQ.ewogICJpYXQiOiAxNTI2MTMxNDExLAogICJleHAiOiAxNjk0Njk3NTk2LAogICJhZG1pbiI6ICJmYWxzZSIsCiAgInVzZXIiOiAiVG9tIgp9.
因为抓到的数据包中没有jwt的位置那么就可以在数据包中找一个位置存放jwt，此数据包可放置在Authorization中
添加:
反序列化漏洞是因为链式调用
越权漏洞是因为凭证（Cookie，Session，Token，JWT）
现如今常见的都是越权和逻辑漏洞，学习JWT就是为了攻击凭证（越权）
web漏洞只有一个入口：http
authz：bp中验证越权的插件，页面有误cookie大小和响应都相同的话就是说cookie无用，存在越权