别再只把JWT当令牌了：一个CTF实战案例，手把手教你用Burp Suite和jwt.io破解伪造

从零破解JWT：Burp Suite与jwt.io实战攻防指南

在CTF竞赛和实际渗透测试中，JSON Web Token（JWT）早已不是简单的身份验证令牌。许多开发者习惯性地将其视为"安全的黑盒子"，却忽略了其底层机制可能存在的致命弱点。本文将带您亲历一场真实的JWT攻防战，从基础的令牌解码到高级的签名伪造，完整重现攻击链的每个技术细节。

1. JWT安全机制深度剖析

JWT由三部分组成，用句点分隔：Header、Payload和Signature。这种结构看似简单，却暗藏玄机。让我们先解剖一个真实案例中的令牌：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhZG1pbiI6ImZhbHNlIn0.oe4qhTxvJB8nNAsFWJc7_m3UylVZzO3FwhkYuESAyUM

1.1 Header的陷阱

使用Burp Suite的Decoder模块对第一部分解码后，我们得到：

{ "alg": "HS256", "typ": "JWT" }

关键点在于alg字段。许多开发者不知道，JWT规范允许将算法指定为"none"。这意味着如果服务器配置不当，攻击者可以完全绕过签名验证。

注意：现代JWT库已默认禁用none算法，但老旧系统仍可能存在此漏洞

1.2 Payload的攻防点

第二部分解码后显示：

{ "admin": "false" }

在CTF比赛中，常见攻击路径是将false改为true。但关键在于如何让修改后的令牌通过服务器验证——这需要突破签名机制。

2. 实战工具链配置

2.1 Burp Suite拦截与修改

1. 配置浏览器代理为127.0.0.1:8080
2. 安装Burp的CA证书（重要！否则无法拦截HTTPS流量）
3. 在Proxy→Intercept开启拦截，触发目标请求
4. 右键发送到Repeater模块进行后续操作

2.2 jwt.io的进阶用法

这个在线工具不仅能解码JWT，还能进行签名验证实验。操作步骤：

1. 粘贴原始令牌到左侧编辑区
2. 观察自动解析出的Header和Payload
3. 尝试修改Payload中的关键字段（如admin值）
4. 在VERIFY SIGNATURE区域测试不同密钥

3. 签名破解实战三法

3.1 算法降级攻击

当发现服务器使用RS256（非对称加密）时，可尝试改为HS256（对称加密）。攻击流程：

# 使用jwt_tool进行算法混淆 python3 jwt_tool.py <JWT> -X a

3.2 密钥爆破实战

使用jwt-cracker进行暴力破解：

docker run -it --rm ichtrojan/jwt-cracker <JWT> <字符集> <最大长度>

推荐爆破字典优先级：

1. 网站名称/域名变形
2. 常见弱密码（如admin123）
3. CTF常见密钥（如flag, secret）

3.3 信息泄露利用

通过.swp文件、Git泄露等途径获取服务器源码，往往能直接发现密钥。案例中的关键代码：

const KEY = 'L3yx----++++----'; $jwt = \Firebase\JWT\JWT::encode($token,KEY);

4. 完整攻击链演示

让我们串联所有技术点，重现一个真实CTF解题过程：

1. 信息收集

   • 发现页面注释中的base32编码：NNVTU23LGEZDG===
   • 解码获得凭证：kk:kk123

2. 源码泄露利用

   • 通过.dirsearch扫描发现/.swp文件
   • 使用vim -r恢复源码获取JWT密钥

3. 令牌伪造

   import jwt forged = jwt.encode({"admin": True}, "L3yx----++++----", algorithm="HS256") print(forged)

4. 权限提升

   • 使用Burp Repeater替换Cookie中的JWT
   • 重放请求获取flag

5. 防御方案设计

针对上述攻击手法，企业级防护应当：

1. 算法层面

   • 强制指定算法（禁止none）
   • 禁用HS256等对称算法（优先使用RS256/PS256）

2. 密钥管理

   • 定期轮换签名密钥
   • 使用密钥管理系统（如HashiCorp Vault）

3. 令牌校验

   // 安全校验示例（Java） Jwts.parserBuilder() .requireIssuer("trusted-domain.com") .setSigningKey(publicKey) .build() .parseClaimsJws(token);

在最近的一次红队评估中，我们发现某金融系统因为未校验JWT的iss字段，导致攻击者可以跨租户伪造令牌。这类细节往往成为系统安全的阿喀琉斯之踵。