关注这个靶场的其他相关笔记：Authentication Lab ------ 靶场笔记合集-CSDN博客
0x01：JWT None Algorithm 前情提要
本关的考点是 JWT（Json Web Token）漏洞，JWT 是一个用于跨域认证的技术。如果你不了解 JWT，可以参考这篇文章：JWT 详解。
JWT 标准支持不安全的 JWT 算法，适用于不需要加密和签名的场景，例如受信任的服务器之间的通信。在这些情况下，可以通过在 JWT 标头中指定算法 alg 为 none 来省略签名的内容。但经过这种签名的 JWT，是不应该发送给用户使用的。
0x02：JWT None Algorithm Write UP
使用 BurpSuite 自带的浏览器打开靶场（这里主要是为了抓包）：
点击页面上的 Validate Token 按钮，获取 JWT 用户信息：
从查询出来的结果包括用户权限来看，本关考验的就是越权。此时回到 BurpSuite，查看之前抓的包：
可以发现，在我们给服务器发送的请求包中除了 Authorization 字段外，并没有什么特殊的内容来表明发送此信息的人的身份，所以，我们有合理的理由来怀疑，这个 Authorization 字段就是我们用户的登录凭证，其中包含了我们用户的个人信息。
在解密 Authorization 中的 JWT 之前，我们看一下上面那个 JS 文件。（你难道不疑惑一下 Authorization 字段中的值是哪里来的吗？）
可以看到，这个 JWT 内容是写在 JavaScript 脚本中直接发送给后端的。并且，除了发送的那条外，还注释了一条信息：
javascript
// JWT with none
// let token = "eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJsZXZlbCI6InVzZXIiLCJ1c2VyIjoic2lkIn0."这条信息中的 token 可以让你很快速的联想到 JWT，但是它与普通的 JWT 又不同，它省略了签名部分的内容（这个时候，聪明如你应该已经想到过关的方法了）。
这个发现先按下不表，我们对第 5 条数据包中，我们发给服务端的那个 JWT 进行一个解码（去 JWT 官网即可：JSON Web Tokens - jwt.io）：
可以发现，解密后的内容中，JWT 的 Payload 部分正好包含用户名和用户等级。这告诉了我们一个可能，只要能修改 JWT 的值，我们就可能完成越权！
那么怎么修改呢？JWT Payload 部分使用的是 Base64URL 编码，这个很好蒙混过关，可是它还有一个签名字段，用来验证 Header 与 Payload 是否被人为修改过，要是不要这个字段就好了。。。。是的，过关的方式，不要这个字段！
记得，注释掉的那条信息吗：JWT With none，我们将那条 Token 也放到 JWT 官网进行解密：
可以看到，解密后的 alg 的字段为 none。我们知道，在 JWT 中，Header 中的 alg 表名的是签名部分使用的算法，这里值为 none，且其又无签名部分，是否可以说明，只要修改 JWT 的签名算法为 none，就可以绕过签名。
我们将这条签名为 none 的 JWT，发送给服务器身份验证接口进行验证（就是上面那个回显 User、Level 的数据包）：
可以看到，其返回了 'none' signature type is not allowed，说明 alg 为 none 是不允许的，为 none 不允许，那为 None 允许吗？思维打开，我们找到一个 Base64URL 编码的站点，将 JWT 的 Header 部分重新进行编码：
将重构后的 JWT Header 传递给服务端，可以看到，服务端成功完成了回显：
光回显没用，我们还要提权，假设它们站点最高权限是 admin 我们对 JWT 的 Payload 部分也进行修改，看看能不能提权成功：
从回显中可以看到，Level 为 admin，成功提权！
如果此时进一步测试，你还可以发现，当 JWT 签名算法为 None 时，你给其签名部分填任何值，后端都不会对其进行验证（没啥用，帮你省点测试时间）：
