前言
JWT(Json Web Token)是一种用于在网络应用之间安全地传输信息的开放标准。它通过将用户信息以JSON格式加密并封装在一个token中,然后将该token发送给服务端进行验证,从而实现身份验证和授权。
流程
JWT的加密和解密过程如下:
1、 生成JWT Token :
客户端登录成功后,服务器使用用户的信息(如用户ID、用户名等)以及服务器端的密钥,通过特定的加密算法(如HMACSHA256、RSA等)生成JWT Token。
2、发送JWT Token :
客户端将生成的JWT Token发送给服务器,通常是通过HTTP请求的头部Authorization字段或者其他方式发送。
3、服务器验证JWT Token :
服务器收到JWT Token后,首先会对Token进行解析,检查Token的格式是否正确,并获取到头部和载荷部分的内容。
然后,服务器使用存储在服务器端的密钥和相同的加密算法,对头部和载荷进行签名验证,以确认Token的真实性和完整性。
4、响应处理 :
如果JWT Token验证成功,服务器可以根据用户的请求执行相应的操作,并向客户端返回相应的响应。
如果JWT Token验证失败,则服务器通常会返回相应的错误信息或拒绝服务。
认证区别
这里以传统Token验证方式与JWT验证方式做区分。
在传统Token方式中,用户登录成功后,服务端生成一个随机Token并分配给用户,同时在服务端(如数据库或缓存)保存一份Token记录。随后,用户在后续的请求中需携带该Token。服务端在接收到Token后,会进行数据库或缓存的查询,以验证Token的有效性和合法性,包括检查Token是否超时或被篡改。
在JWT方式中,用户登录成功后,服务端使用JWT生成一个随机Token,并将其发送给用户,服务端无需在数据库或缓存中保存Token记录。用户在后续的请求中需要携带该Token。服务端在接收到Token后,通过JWT对Token进行验证。
这两种方式的本质区别在于Token的验证和存储方式。
JWT组成
JWT包含三个部分:头部(Header)、载荷(Payload)和签名(Signature)。
1、头部(Header):头部包含了两部分信息,分别是令牌的类型(typ)和所使用的加密算法(alg),它们由json格式经base64url编码得到。(base64url编码:base64编码后,用 - 替代 +,用 _ 替代/)
例如:
bash
{
"alg": "HS256",
"typ": "JWT"
}
加密得到:
bash
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
该字符串成为了Header部分
2、载荷(Payload):载荷包含了要传输的用户信息,如用户ID、用户名等。此外,也可以包含其他自定义的信息。载荷的内容是经过base64url编码的,能够被解码。
例如:
bash
{
"name": "ice",
"phone": 123456789,
"address": "ice.home"
}
编码得到:
bash
eyJuYW1lIjoiaWNlIiwicGhvbmUiOjEyMzQ1Njc4OSwiYWRkcmVzcyI6ImljZS5ob21lIn0
该字符串成为了Payload部分
3、签名(Signature):签名用于验证token的真实性和完整性。签名是由头部、载荷以及密钥结合特定的加密算法生成的。
加密算法例如:
js
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
ice
)
本例中,对Header.Payload进行HS256加密(密钥为ice)后,再进行base64url加密,从而得到签名。
bash
GJd4DLWt-IWWhE4ELHUXiLJjJG5C_HcvTY87c2s74Z0
最后将三段字符串通过.拼接起来就生成了JWT的token:
bash
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoiaWNlIiwicGhvbmUiOjEyMzQ1Njc4OSwiYWRkcmVzcyI6ImljZS5ob21lIn0.GJd4DLWt-IWWhE4ELHUXiLJjJG5C_HcvTY87c2s74Z0
https://jwt.io/
可用于编码、解码和验证JSON Web Tokens(JWT):
JWT攻击方式
1、修改加密算法伪造token
JWT中最常用的两种算法为HMAC和RSA。
HMAC是一种对称加密算法,使用相同的密钥对传输信息进行加解密。
RSA是一种非对称加密算法,使用私钥加密明文,公钥解密密文。
若存在一场景:某应用程序在JWT传输过程中使用RSA算法,同时使用密钥ice对JWT token进行签名,公钥abc对签名进行验证。
bash
{
"alg" : "RS256",
"typ" : "jwt"
}
通常情况下密钥ice是无法获取到的,但是公钥abc却可以通过某些途径得到,此时将JWT的加密算法修改为HMAC,同时使用获取到的公钥abc作为算法的密钥,对token进行签名,发送到服务器端:
bash
{
"alg" : "HS256",
"typ" : "jwt"
}
服务器端会将RSA的公钥(abc)视为当前算法(HMAC)的密钥,而HMAC是对称加密算法,故服务器使用密钥abc对接收到的签名进行验证,从而造成token伪造问题。
2、None算法攻击绕过验证
在Header中指定alg为None,同时不添加signature,服务器在验证JWT时会认为这个JWT是不需要签名的,从而跳过了对签名的验证,直接信任JWT中的信息,实现伪造身份绕过服务器验证。
HEADER:
bash
{
"alg" : "None",
"typ" : "jwt"
}
Payload:
bash
{
"username" : "Admin"
}
生成的完整token为
bash
ew0KCSJhbGciIDogIk5vbmUiLA0KCSJ0eXAiIDogImp3dCINCn0.ew0KCSJ1c2VyIiA6ICJBZG1pbiINCn0
3、KID参数
"kid" 是 JWT 头部中的一个可选参数,全称为 "Key ID",它用于指定加密算法所使用的密钥。
例如:
bash
{
"alg": "HS256",
"typ": "JWT",
"kid": "signing_key"
}
或
bash
{
"alg": "HS256",
"typ": "JWT",
"kid": "/home/jwt/.ssh/pem"
}
由于该参数可控,将导致以下漏洞。
3.1任意文件读取
系统并不会验证kid参数路径指向的文件是否是有效的密钥文件。因此,在没有对参数进行过滤或验证的情况下,可造成任意文件读取。
例如:
bash
{
"alg" : "HS256",
"typ" : "jwt",
"kid" : "../../etc/passwd"
}
3.2SQL注入
"kid"参数也可能从数据库中提取数据,故存在SQL注入攻击的风险。
例如:
bash
{
"alg" : "HS256",
"typ" : "jwt",
"kid" : "ice' || union select 'users' -- "
}
3.3命令注入
若服务器后端使用的是Ruby,在读取密钥文件时使用了open函数,通过构造参数可能实现命令注入。
例如:
bash
{
"alg" : "HS256",
"typ" : "jwt",
"kid" : "/path/to/key_file|whoami"
}
其它语言可进行思路延申。
4、信息泄露
JWT确保的是数据传输过程中的完整性和真实性,而不是机密性。由于payload是使用Base64url编码的,相当于明文传输。因此,如果在payload中携带了敏感信息(例如存放密钥对的文件路径),那么仅对payload部分进行Base64url解码就可以读取其中携带的信息。