前言
在最近的ctf比赛中，经常可以碰到一些jwt相关的题目，然后感觉思路挺有意思，拿出来分享一下，后边也总结一下ctf比较常见的集jwt相关题目解题思路
算法混淆漏洞
腾龙杯 web[这又是一个登录页面]
使用zkaq/zkaq登录之后，又跳到了一个登录页面。账号密码我用的是admin/admin（随便输入的）
之后会跳转到http://ckqongk8.lab.aqlab.cn/fl4g页面，告诉我们只有`@dministr@t0r`用户可以访问
解题思路
用yakit抓一下这个页面的登录包看看
很容易可以看出来是jwt做的身份校验，解密发现使用的算法是RSA256
使用的事RSA算法，弱密钥有点不太现实，试了一下另外两个jwt简单绕过：未对签名进行验证、未对加密算法进行强验证，不过都没成功
原理挺简单的，可以看看我之前的文章奇安信攻防社区-JWT渗透姿势 (butian.net)
后边经过测试在robots.txt拿到了公钥
然后就想起之前打过的一个靶场，大概思路就是对签名方法过滤不严
比如：
function verify(token, secretOrPublicKey){ algorithm = token.getAlgHeader(); if(algorithm == "RS256"){ // Use the provided key as an RSA public key }else if (algorithm == "HS256"){ // Use the provided key as an HMAC secret key }
}当随后使用此方法的网站开发人员假设它将专门处理使用 RS256 等非对称算法签名的 JWT 时，就会出现问题。由于这个有缺陷的假设，他们可能总是将固定的公钥传递给该方法，如下所示：
publicKey = <public-key-of-server>;
token = request.getCookie("session");
verify(token, publicKey);在这种情况下，如果服务器收到使用 HS256 等对称算法签名的令牌，则库的通用verify()方法会将公钥视为 HMAC 密钥。这意味着攻击者可以使用 HS256 和公钥对令牌进行签名，并且服务器将使用相同的公钥来验证签名。
复现
1、把pem格式的秘钥base64编码
2、在Burpsuite的JWT Editor 中
3、base64加密过的那个替换k
4、抓包，需要改两个地方
5、点击sign，选择刚刚创建的JWT
6、复制新生成的秘钥
7、替换之前的旧JWT
Other
未验证签名
首先看到jwt相关题目，第一个想法就是先直接修改，看看能不能过签
未对签名算法强验证
若直接修改内容无法过签，那就在尝试修改Header部分加密算法
秘钥泄露
翻一番robots等文件，看看有无秘钥泄露，有的话就可以直接构造
弱密钥
弱密钥，我们就可以通过一些工具来进行爆破
