WebGoat JWT 漏洞实战：第六关与第十一关逻辑越权解析
JWT（JSON Web Token）是现在 Web 开发中非常常见的身份认证方案。它的核心结构分为 Header、Payload 和 Signature 三部分，其中签名机制是保障令牌完整性和真实性的关键。
JWT 的核心机制
简单来说，JWT 的签名是为了防止客户端篡改令牌内容。服务端在接收请求时，必须先验证签名，确认令牌未被修改后再执行后续操作。
常用的签名算法包括对称加密（如 HMAC-SHA256）和非对称加密（如 RSASSA-PKCS1-v1_5）。这里有个关键点：令牌在交付给客户端前必须签名。如果服务端配置不当，比如允许 alg: none 或者根本忽略签名验证，攻击者就能轻易伪造身份。
为了理解这个漏洞，我们先区分一下 Session 和 Token：
- Session：服务器存信息，给用户一个'编号'。依赖服务器存储，适合单点场景。
- Token：用户带信息，服务器只验真伪。不依赖服务器存储，更适合多服务器或 APP 场景。
举个例子，假设攻击者拿到了自己的 JWT：header.payload.signature。
- 解码 payload 看到：
{"user_id":123, "role":"user"}（普通用户）。 - 把
role改成"admin"，重新编码 payload。 - 构造新 Token：
原 header.篡改后的 payload.随便填（甚至把 signature 删掉）。 - 如果服务器收到后直接解析 payload 就用，没验证签名 → 攻击者瞬间变成管理员。
靶场第六关：未签名 Token 提权
这一关主要演示的是'未签名 Token 提权'的场景。我们需要以一个普通用户的身份，行使管理员权限，造成水平越权。
先登录一个普通用户（比如 Tom），尝试重置投票。系统会提示我们只有管理员才能操作。
打开抓包工具（如 Yakit），查看响应头，会发现提示信息表明当前用户没有权限。这时候我们需要检查 Cookie 中的 Token。
我们可以利用在线工具 jwt.io 来解码并验证 JWT。这一步很关键，它能帮我们看清 Payload 里到底存了什么。
