浅析JWT安全问题 - 网安 - 专业的网络安全产业、社区、知识平台

重生之我是JWT

前不久研究websocket时发现port-swigger出了新的靶场，一看，发现是关于jwt安全的，刚好来总结回忆一下

JWT简介

Json web token (JWT)，是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（RFC 7519）

•RFC 7519:https://datatracker.ietf.org/doc/html/rfc7519

他定义了一种紧凑且自包含的方式，用于在各方之间安全地传输信息作为 JSON 对象，特别适用于分布式站点的单点登录（SSO）场景

JWT与cookie/session的异同

•JWT与cookie/session一样，都是作用于前后端认证

•cookie/session：后端有个session，前端有个cookie，这样的基于session的认证会要求服务端不断存储用户登录信息，而随着不同客户端用户的增加，独立的服务器会逐渐无法承载更多的用户，导致其服务器的压力十分巨大，且cookie一旦被窃取还可能造成CSRF攻击

•JWT：当我们把前后端分离开来，后端不再有session，当不再需要保存session文件，这就降低了服务端的负担，而我们就可以利用JWT这么一个基于token的鉴权认证，而基于token认证机制的应用就不需要去考虑用户在哪个服务器登录，客户端也可以将通过服务器认证后的json对象存储起来，下次访问时连同请求内容一同发送即可

JWT格式

JWT由Header、Payload、Signature组成

Header.Payload.Signature

•Header

{"alg":"加密算法","typ":"JWT"}

•Payload

 iss: The issuer of the tokensub: The subject of the tokenaud: The audience of the tokenexp: JWT expiration time defined in Unix timenbf: "Not before" time that identifies the time before which the JWT must not be accepted for processingiat: "Issued at" time, in Unix time, at which the token was issuedjti: JWT ID claim provides a unique identifier for the JWT//可以自定义其它字段

•Signature

Signature = HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload),"secret")

secret保存在后端，就是来解析确定验证的key

JWT&JWS&JWE

•JWS，即JSON Web Signature，只是 JWT 的一种实现

•JWE，即JSON Web Encryption，也只是 JWT 的一种实现

潜在漏洞

•签名未校验

•算法被篡改

•敏感信息泄露

•加密算法不安全

•伪造密钥(CVE-2018-0114)

JWT安全问题

未对签名进行验证

我们前面说过，JWT存在一个Signature 签名，如若没对签名进行认证，就可能存在越权情况

•靶场

Lab: JWT authentication bypass via unverified signature

•解法

To solve the lab, modify your session token to gain access to the admin panel at /admin, then delete the user carlos.

我们需要把carlos删掉，而这就需要登录管理员账号，但是又没有给管理员的账号，只有一个普通用户，那我们就要想办法提升权限

先抓包

观察确定为JWT，将payload处字符base64解码得

把sub的wiener修改为administrator，重新传参

成功越权，然后就是删除用户即可

未对加密算法进行强验证

回顾一下Header的构成

{"alg":"加密算法","typ":"JWT"}

这里alg可以说明加密算法，但如果对该设置不进行强认证也会造成越权问题

我们可以把加密算法设成none来进行验证绕过

•靶场

Lab: JWT authentication bypass via flawed signature verification

•解法

先和上题一致，将sub内容修改为administrator，然后发现还是没能成为管理员，接着修改header的alg为none，把后续的Signature删除，因为Signature是通过alg算法生成的，既然alg都为none了，那Signature也应该为空了

成功变成管理员

然后就是正常删除用户就行

绕过弱签名密钥进行越权

Signature = HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload),"secret")

我们知道，签名存在一个secret密钥，这个一般都会保存在后端，别人无法查看，但是类同于弱口令，一旦这个密钥不复杂就有可能被爆破，gayhub上也有很多爆破的字典

•靶场

Lab: JWT authentication bypass via weak signing key

•解法

还是一样先抓包得到JWT

然后用到hashcat来进行爆破，kali自带

hashcat -a 0 -m 16500/path/to/jwt.secrets.list

爆破得到secret为secret1

然后前往jwt.io生成我们需要的的jwt，把sub和secret进行修改

重新传包，成功

JWT标头注入

与很多注入一样，JWT标头注入也可大致分为两种情况，一是与数据库连接，搭配sql注入使用，一是不与数据库连接，单独进行越权操作

通过jwk参数注入自签名的JWT

还记得我们说过的JWS吗

JWS，即JSON Web Signature，只是 JWT 的一种实现

我们就可以通过JWK注入JWT，形成JWS

•那什么是JWK呢

JWK 英文全称为 JSON Web Key，是一个JSON对象，表示一个加密的密钥，他不同于alg属性，JWK是可选的，以下就是一个示例

 {    "kid": "ed2Nf8sb-sD6ng0-scs5390g-fFD8sfxG",    "typ": "JWT",    "alg": "RS256",    "jwk": {        "kty": "RSA",        "e": "AQAB",        "kid": "ed2Nf8sb-sD6ng0-scs5390g-fFD8sfxG",        "n": "yy1wpYmffgXBxhAUJzHHocCuJolwDqql75ZWuCQ_cb33K2vh9m"    }}

•在理想情况下，服务器应该是只使用公钥白名单来验证JWT签名的，但对于一些相关配置错误的服务器会用JWK参数中嵌入的任何密钥进行验证，攻击者就可以利用这一行为，用自己的RSA私钥对修改过的JWT进行签名，然后在JWK头部中嵌入对应的公钥进行越权操作

•靶场

Lab: JWT authentication bypass via jwk header injection

•解法

需要先安装一个插件，方便后续的操作

–JWT Editor