关注这个靶场的其他相关笔记: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 时,你给其签名部分填任何值,后端都不会对其进行验证(没啥用,帮你省点测试时间):