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 里到底存了什么。









