JWT原理及常见攻击方式

JWT的全称是Json Web Token。它遵循JSON格式，将用户信息加密到token里，服务器不保存任何用户信息，只保存密钥信息，通过使用特定加密算法验证token，通过token验证用户身份。基于token的身份验证可以替代传统的cookie+session身份验证方法。

jwt由三个部分组成：header.payload.signature

官网：https://jwt.io/

JWT原理

0x01  JWT认证流程

在项目开发中，一般会按照上图所示的过程进行认证，即：用户登录成功之后，服务端给用户浏览器返回一个token，以后用户浏览器要携带token再去向服务端发送请求，服务端校验token的合法性，合法则给用户看数据，否则，返回一些错误信息。

0x02 传统token方式和jwt在认证方面有什么差异？

传统token方式：

用户登录成功后，服务端生成一个随机token给用户，并且在服务端(数据库或缓存)中保存一份token，以后用户再来访问时需携带token，服务端接收到token之后，去数据库或缓存中进行校验token的是否超时、是否合法。

jwt方式：

用户登录成功后，服务端通过jwt生成一个随机token给用户（服务端无需保留token），以后用户再来访问时需携带token，服务端接收到token之后，通过jwt对token进行校验是否超时、是否合法。

0x03 JWT原理

jwt的生成token格式如下，即：由 . 连接的三段字符串组成。

?

1	eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

生成规则如下：

• 第一段HEADER部分，固定包含算法和token类型，对此json进行base64url加密，这就是token的第一段。

?

1 2 3 4 5 6 7

{      "alg": "HS256",      "typ": "JWT"   }

• 第二段PAYLOAD部分，包含一些数据，对此json进行base64url加密，这就是token的第二段。

?

1 2 3 4 5 6 7 8 9 10 11

{       "sub": "1234567890",       "name": "John Doe",       "iat": 1516239022        ...   }

• 第三段SIGNATURE部分，把前两段的base密文通过.拼接起来，然后对其进行HS256加密，再然后对hs256密文进行base64url加密，最终得到token的第三段。

?

1 2 3 4 5 6

base64url(       HMACSHA256(              base64UrlEncode(header) + "." + base64UrlEncode(payload),              your-256-bit-secret (秘钥加盐)       ) )

最后将三段字符串通过 .拼接起来就生成了jwt的token。

注意：base64url加密是先做base64加密，然后再将 - 替代 + 及 _ 替代 / 。

 

代码实现参考：https://pythonav.com/wiki/detail/6/67/

JWT攻击方式

加密算法

0x01 空加密算法

JWT支持使用空加密算法，可以在header中指定alg为None

这样的话，只要把signature设置为空（即不添加signature字段），提交到服务器，任何token都可以通过服务器的验证。举个例子，使用以下的字段

?

1 2 3 4 5 6 7 8

{     "alg" : "None",     "typ" : "jwt" }    {     "user" : "Admin" }

生成的完整token为ew0KCSJhbGciIDogIk5vbmUiLA0KCSJ0eXAiIDogImp3dCINCn0.ew0KCSJ1c2VyIiA6ICJBZG1pbiINCn0

(header+'.'+payload，去掉了'.'+signature字段)

空加密算法的设计初衷是用于调试的，但是如果某天开发人员脑阔瓦特了，在生产环境中开启了空加密算法，缺少签名算法，jwt保证信息不被篡改的功能就失效了。攻击者只需要把alg字段设置为None，就可以在payload中构造身份信息，伪造用户身份。

0x02 修改RSA加密算法为HMAC

JWT中最常用的两种算法为HMAC和RSA。

HMAC是密钥相关的哈希运算消息认证码（Hash-based Message Authentication Code）的缩写，它是一种对称加密算法，使用相同的密钥对传输信息进行加解密。

RSA则是一种非对称加密算法，使用私钥加密明文，公钥解密密文。

在HMAC和RSA算法中，都是使用私钥对signature字段进行签名，只有拿到了加密时使用的私钥，才有可能伪造token。

现在我们假设有这样一种情况，一个Web应用，在JWT传输过程中使用RSA算法，密钥pem对JWT token进行签名，公钥pub对签名进行验证。

?

1 2 3 4

{     "alg" : "RS256",     "typ" : "jwt" }

通常情况下密钥pem是无法获取到的，但是公钥pub却可以很容易通过某些途径读取到，这时，将JWT的加密算法修改为HMAC，即

?

1 2 3 4

{     "alg" : "HS256",     "typ" : "jwt" }

同时使用获取到的公钥pub作为算法的密钥，对token进行签名，发送到服务器端。

服务器端会将RSA的公钥（pub）视为当前算法（HMAC）的密钥，使用HS256算法对接收到的签名进行验证。

参考2018CUMTCTF-Final-Web Paterbin：https://skysec.top/2018/05/19/2018CUMTCTF-Final-Web/#Pastebin/

爆破密钥

俗话说，有密码验证的地方，就有会爆破。

不过对 JWT 的密钥爆破需要在一定的前提下进行：

• 知悉JWT使用的加密算法
• 一段有效的、已签名的token
• 签名用的密钥不复杂（弱密钥）

所以其实JWT 密钥爆破的局限性很大。

相关工具：c-jwt-cracker

以下是几个使用示例

 

可以看到简单的字母数字组合都是可以爆破的，但是密钥位数稍微长一点或者更复杂一点的话，爆破时间就会需要很久。

修改KID参数

kid是jwt header中的一个可选参数，全称是key ID，它用于指定加密算法的密钥

?

1 2 3 4 5

{     "alg" : "HS256",     "typ" : "jwt",     "kid" : "/home/jwt/.ssh/pem" }

因为该参数可以由用户输入，所以也可能造成一些安全问题。

0x01 任意文件读取

kid参数用于读取密钥文件，但系统并不会知道用户想要读取的到底是不是密钥文件，所以，如果在没有对参数进行过滤的前提下，攻击者是可以读取到系统的任意文件的。

?

1 2 3 4 5

{     "alg" : "HS256",     "typ" : "jwt",     "kid" : "/etc/passwd" }

0x02 SQL注入

kid也可以从数据库中提取数据，这时候就有可能造成SQL注入攻击，通过构造SQL语句来获取数据或者是绕过signature的验证

?

1 2 3 4 5

{     "alg" : "HS256",     "typ" : "jwt",     "kid" : "key11111111' || union select 'secretkey' -- " }

0x03 命令注入

对kid参数过滤不严也可能会出现命令注入问题，但是利用条件比较苛刻。如果服务器后端使用的是Ruby，在读取密钥文件时使用了open函数，通过构造参数就可能造成命令注入。

"/path/to/key_file|whoami"

对于其他的语言，例如php，如果代码中使用的是exec或者是system来读取密钥文件，那么同样也可以造成命令注入，当然这个可能性就比较小了。

修改JKU/X5U参数

JKU的全称是"JSON Web Key Set URL"，用于指定一组用于验证令牌的密钥的URL。类似于kid，JKU也可以由用户指定输入数据，如果没有经过严格过滤，就可以指定一组自定义的密钥文件，并指定web应用使用该组密钥来验证token。

X5U则以URI的形式数允许攻击者指定用于验证令牌的公钥证书或证书链，与JKU的攻击利用方式类似。

信息泄露

JWT保证的是数据传输过程中的完整性而不是机密性。

由于payload是使用base64url编码的，所以相当于明文传输，如果在payload中携带了敏感信息（如存放密钥对的文件路径），单独对payload部分进行base64url解码，就可以读取到payload中携带的信息。