freeBuf
主站

分类

云安全 AI安全 开发安全 终端安全 数据安全 Web安全 基础安全 企业安全 关基安全 移动安全 系统安全 其他安全

特色

热点 工具 漏洞 人物志 活动 安全招聘 攻防演练 政策法规

点我创作

试试在FreeBuf发布您的第一篇文章 让安全圈留下您的足迹
我知道了

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

JWT身份验证相关安全问题
dopromax 2022-08-07 22:34:48 213096
所属地 广东省

前言:工作中需要基于框架开发一个贴近实际的应用,找到一款比较合适的cms框架,其中正好用到的就是jwt做身份信息验证,也记录一下学习jwt相关的安全问题过程。

JWT介绍

Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准((RFC 7519).该token被设计为紧凑且安全的,特别适用于分布式站点的单点登录(SSO)场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源,也可以增加一些额外的其它业务逻辑所必须的声明信息,该token也可直接被用于认证,也可被加密。

JWT组成

JWT可分为三部分,分别为头部(header)、载荷(payload)、签名(signature),简单介绍一下每个部分的作用。

整体组成如下,以“.”分隔为三头部、载荷、签名部分:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

JWT加解密网站:https://jwt.io/

头部(header)

作用:声明类型、加密算法等

原始格式:eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

解base64:

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

typ:声明算法类型,这里是JWT,

alg:声明加密算法,这里是HS256,为对称算法(前后端使用同一密钥进行加密,并非能够解密),常用的还有RS256和ES256两个非对称算法(签名时使用私钥,验证时使用公钥)。

载荷(payload)

作用:存储有效数据

原始格式:eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ

解base64:

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

载荷部分默认字段:

iss (issuer):JWT的发行者
exp (expiration time):过期时间
sub (subject):JWT面向的主题
aud (audience):JWT的用户
nbf (Not Before):生效时间
iat (Issued At):签发时间
jti (JWT ID):JWT唯一标识

注:用户可根据需求自定义字段

签名(signature)

作用:签名部分,服务端校验此字段来验证载荷(payload)字段是否合法

原始格式:SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

该字段加密方式如下:

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

这里的HMACSHA256就是在header中alg字段指定的HS256加密算法,而RS256和ES256则是服务端使用私钥加密,好处是可以将验证委托给其他应用,只要散发自己的公钥即可。

JWT用法

JWT被用于身份验证中,作用类似于session,但相比于session这种方式各有优劣,下面简述一下JWT的使用流程

一、用户登录,输入登录所需的信息,后端验证后,返回jwt格式的token

二、用户携带token访问需要身份验证的资源或接口

三、服务端验证jwt格式token中的signature(使用相应加密算法重新加密token中的header和payload,验证是否相等)

四、验证成功,允许访问资源

登录获取token代码示例(lin-cms-springboot)

首先入口是login方法

/**
* 用户登陆
*/
@PostMapping("/login")
public Tokens login(@RequestBody @Validated LoginDTO validator, @RequestHeader(value = "Tag", required = false) String tag) {
UserDO user = userService.getUserByUsername(validator.getUsername());
if (user == null) {
throw new NotFoundException(10021);
}
boolean valid = userIdentityService.verifyUsernamePassword(
user.getId(),
user.getUsername(),
validator.getPassword());
if (!valid) {
throw new ParameterException(10031);
}
return jwt.generateTokens(user.getId());
}

判断用户名和密码正确后,将user.getId(即用户的ID)传入generateTokens方法

public Tokens generateTokens(long identity) {
String access = this.generateToken("access", identity, "lin", this.accessExpire);
String refresh = this.generateToken("refresh", identity, "lin", this.refreshExpire);
return new Tokens(access, refresh);
}

根据固定的字段和传入的用户ID,调用generateToken方法获取token(这里调用了两次,分别生成两个token,access_token和refresh_token,后面会讲)

public String generateToken(String tokenType, long identity, String scope, long expire) {
Date expireDate = DateUtil.getDurationDate(expire);
return this.builder.withClaim("type", tokenType).withClaim("identity", identity).withClaim("scope", scope).withExpiresAt(expireDate).sign(this.algorithm);
}

——————以下调用是com.auth0.jwt第三方库中的内容——————

这里反复调用了withClaim方法

public JWTCreator.Builder withClaim(String name, Long value) throws IllegalArgumentException {
this.assertNonNull(name);
this.addClaim(name, value);
return this;
}
public JWTCreator.Builder withClaim(String name, String value) throws IllegalArgumentException {
this.assertNonNull(name);
this.addClaim(name, value);
return this;
}
...
重载的所有withClaim方法具体内容都一样

因为这个方法返回的还是this,所以可以直接循环调用,是为了生成并绑定不同字段的值。

接着调用了assertNonNull方法、addClaim方法

private void assertNonNull(String name) {
if (name == null) {
throw new IllegalArgumentException("The Custom Claim's name can't be null.");
}
}

private void addClaim(String name, Object value) {
if (value == null) {
this.payloadClaims.remove(name);
} else {
this.payloadClaims.put(name, value);
}
}

assertNonNull方法就是判空处理,addClaim方法就将键值对put到payloadClaims这个map对象中,也就是最终生成的payload字段。

这里执行完成后,接着还跳回generateToken方法,因为调用完withClaim方法后,就会调用withExpiresAt(expireDate).sign(this.algorithm),

withExpiresAt方法,就是添加exp字段

public JWTCreator.Builder withExpiresAt(Date expiresAt) {
this.addClaim("exp", expiresAt);
return this;
}

接着进入最关键的sign方法

public String sign(Algorithm algorithm) throws IllegalArgumentException, JWTCreationException {
if (algorithm == null) {
throw new IllegalArgumentException("The Algorithm cannot be null.");
} else {
this.headerClaims.put("alg", algorithm.getName());
if (!this.headerClaims.containsKey("typ")) {
this.headerClaims.put("typ", "JWT");
}

String signingKeyId = algorithm.getSigningKeyId();
if (signingKeyId != null) {
this.withKeyId(signingKeyId);
}

return (new JWTCreator(algorithm, this.headerClaims, this.payloadClaims)).sign();
}
}

headerClaims方法就是向header字段中添加typ和alg的值,重点在最终return的地方,接着跟入new JWTCreator(algorithm, this.headerClaims, this.payloadClaims)

JWTCreator类的实例化,其中传入的参数分别是加密算法对象、header、payload

private JWTCreator(Algorithm algorithm, Map<String, Object> headerClaims, Map<String, Object> payloadClaims) throws JWTCreationException {
this.algorithm = algorithm;

try {
ObjectMapper mapper = new ObjectMapper();
SimpleModule module = new SimpleModule();
module.addSerializer(ClaimsHolder.class, new PayloadSerializer());
mapper.registerModule(module);
mapper.configure(MapperFeature.SORT_PROPERTIES_ALPHABETICALLY, true);
this.headerJson = mapper.writeValueAsString(headerClaims);
this.payloadJson = mapper.writeValueAsString(new ClaimsHolder(payloadClaims));
} catch (JsonProcessingException var6) {
throw new JWTCreationException("Some of the Claims couldn't be converted to a valid JSON format.", var6);
}
}

简单看一下上面的逻辑,就是对算法、header、payload进行绑定,然后接着往下走,跳回上一步的sign方法,在对JWTCreator实例化后,紧接着又调用了sign方法,不过这个sign方法没有传入参数,也就是下面这个方法

private String sign() throws SignatureGenerationException {
String header = Base64.encodeBase64URLSafeString(this.headerJson.getBytes(StandardCharsets.UTF_8));
String payload = Base64.encodeBase64URLSafeString(this.payloadJson.getBytes(StandardCharsets.UTF_8));
byte[] signatureBytes = this.algorithm.sign(header.getBytes(StandardCharsets.UTF_8), payload.getBytes(StandardCharsets.UTF_8));
String signature = Base64.encodeBase64URLSafeString(signatureBytes);
return String.format("%s.%s.%s", header, payload, signature);
}

方法中对header和payload的生成就是简单的对json数据进行base64编码,最终生成signature字段的操作为this.algorithm.sign(header.getBytes(StandardCharsets.UTF_8), payload.getBytes(StandardCharsets.UTF_8)),接着跟入sign方法

public byte[] sign(byte[] headerBytes, byte[] payloadBytes) throws SignatureGenerationException {
try {
return this.crypto.createSignatureFor(this.getDescription(), this.secret, headerBytes, payloadBytes);
} catch (InvalidKeyException | NoSuchAlgorithmException var4) {
throw new SignatureGenerationException(this, var4);
}
}

进入到createSignatureFor方法,传入了加密算法、密钥、header和payload

byte[] createSignatureFor(String algorithm, byte[] secretBytes, byte[] headerBytes, byte[] payloadBytes) throws NoSuchAlgorithmException, InvalidKeyException {
Mac mac = Mac.getInstance(algorithm);
mac.init(new SecretKeySpec(secretBytes, algorithm));
mac.update(headerBytes);
mac.update((byte)46);
return mac.doFinal(payloadBytes);
}

就不继续往里跟了(里面最后是调javax.crypto.Mac类中的方法进行的加密,调来调去太乱了),大致原理我们已经搞清楚了,差不多就是根据header和payload字段,然后用secret当salt做一次hash,最后再base64编码传出来,就是我们最终的token。

以上就是从登录到获取token的大致过程。

通过jwt进行身份校验代码示例

这里是拦截器中的一个方法,就不一步一步的跟了,

public boolean handleLogin(HttpServletRequest request, HttpServletResponse response, MetaInfo meta) {
//获取请求头中的Authorization头
String tokenStr = verifyHeader(request, response);
Map<String, Claim> claims;
try {
//在这里做的校验
claims = jwt.decodeAccessToken(tokenStr);
} catch (TokenExpiredException e) {
throw new io.github.talelin.autoconfigure.exception.TokenExpiredException(10051);
} catch (AlgorithmMismatchException | SignatureVerificationException | JWTDecodeException | InvalidClaimException e) {
throw new TokenInvalidException(10041);
}
return getClaim(claims);
}

最终验证的地方在com.auth0.jwt.algorithms.HMACAlgorithm#verify方法中

public void verify(DecodedJWT jwt) throws SignatureVerificationException {
byte[] signatureBytes = Base64.decodeBase64(jwt.getSignature());

try {
//然后调用verifySignatureFor方法校验
boolean valid = this.crypto.verifySignatureFor(this.getDescription(), this.secret, jwt.getHeader(), jwt.getPayload(), signatureBytes);
if (!valid) {
throw new SignatureVerificationException(this);
}
} catch (InvalidKeyException | NoSuchAlgorithmException | IllegalStateException var4) {
throw new SignatureVerificationException(this, var4);
}
}

跟入

boolean verifySignatureFor(String algorithm, byte[] secretBytes, String header, String payload, byte[] signatureBytes) throws NoSuchAlgorithmException, InvalidKeyException {
return this.verifySignatureFor(algorithm, secretBytes, header.getBytes(StandardCharsets.UTF_8), payload.getBytes(StandardCharsets.UTF_8), signatureBytes);
}

boolean verifySignatureFor(String algorithm, byte[] secretBytes, byte[] headerBytes, byte[] payloadBytes, byte[] signatureBytes) throws NoSuchAlgorithmException, InvalidKeyException {
return MessageDigest.isEqual(this.createSignatureFor(algorithm, secretBytes, headerBytes, payloadBytes), signatureBytes);
}

跟入

byte[] createSignatureFor(String algorithm, byte[] secretBytes, byte[] headerBytes, byte[] payloadBytes) throws NoSuchAlgorithmException, InvalidKeyException {
Mac mac = Mac.getInstance(algorithm);
mac.init(new SecretKeySpec(secretBytes, algorithm));
mac.update(headerBytes);
mac.update((byte)46);
return mac.doFinal(payloadBytes);
}

可以看到,这里的createSignatureFor方法,那么最终实现的原理也就是根据传入的header和payload,再调用创建签名方法根据secret密钥创建签名,如果最终创建出来的签名和你传入的jwttoken中的Signature字段值相等,则判定为真。

JWT安全问题

secret硬编码

将加密使用的secret密钥硬编码在框架中,如果开发者不注意的话,使用默认密钥,没有进行修改,那么只要获取到密钥,就可以伪造token。

知道密钥后,那么可以通过该网站https://jwt.io或者编写脚本伪造token

例如该cms:

1659882676_62efccb4e7be5d7abeaa3.png!small?1659882677806

通过在线网站生成token:

1659882686_62efccbe2184e186d88e3.png!small?1659882686985

那么我们直接使用这个token即可访问网站中需要身份验证的接口资源。

1659882697_62efccc9a29fc0fb41501.png!small?1659882698632

后端未校验Signature字段或

攻击方法:可任意修改或者直接删除

原理:后端未对Signature字段进行校验,就取payload中的数据进行后续操作

alg=none签名绕过漏洞(CVE-2015-2951)

攻击方法:将header中的alg的键值改为none,然后将Signature删除即可

原理:后端未对传入的header中的alg字段进行校验,直接使用其中指定的加密算法对Signature

针对以上两种安全问题,如果没有原始jwt_token,可以使用如下脚本生成token:

使用之前需要先使用pip安装PyJWT,而不是JWT,直接python37 -m pip install PyJWT即可

import jwt
payload = {
"identity": 1,
"scope": "lin",
"type": "access",
"exp": 1659797574
}
print(jwt.encode(payload,None,algorithm="none"))

Secret爆破

上面我们知道硬编码的话我们可以任意伪造token,其实原理就是知道secret密钥,除了开源CMS的这种泄露,或者其他系统备份文件、日志之类的泄露密钥,我们还可以通过爆破的方法获取密钥(如果不是弱密钥,难度非常大)

可以使用这个工具:https://github.com/ticarpi/jwt_tool

修改非对称密码算法为对称密码算法(CVE-2016-10555)

这个漏洞只针对使用非对称加密算法(RS256)做校验的系统,当后端使用RS256加密时,使用私钥加密,而校验时用到的是公私钥对中的公钥做校验,而公钥是公开的,我们很容易获取。

那么当我们修改RS256为HS256时,后端会以为使用的是HS256对称加密做校验,即使用公钥当作HS256校验时的secret来进行加密对比是否相等,把公钥当成secret来使用,也就相当于泄露了secret,所以我们就可以使用公钥来伪造token。

伪造密钥(CVE-2018-0114)

我理解这个漏洞和上面的漏洞比较像,上一个漏洞是后台新人了我们提供的header中的算法,这个是使用了JWS,里面也是存储的公钥,那么我们自己生成公私钥对,然后使用私钥生成token,再将自己生成的公钥放到JWS中,让后台使用这个公钥解密,这样就可以巧妙地绕过后台的验证。

# web安全 # 漏洞分析 # 网络安全技术 # 认证加密 # 认证安全
免责声明
1.一般免责声明:本文所提供的技术信息仅供参考,不构成任何专业建议。读者应根据自身情况谨慎使用且应遵守《中华人民共和国网络安全法》,作者及发布平台不对因使用本文信息而导致的任何直接或间接责任或损失负责。
2. 适用性声明:文中技术内容可能不适用于所有情况或系统,在实际应用前请充分测试和评估。若因使用不当造成的任何问题,相关方不承担责任。
3. 更新声明:技术发展迅速,文章内容可能存在滞后性。读者需自行判断信息的时效性,因依据过时内容产生的后果,作者及发布平台不承担责任。
本文为 dopromax 独立观点,未经授权禁止转载。
如需授权、对文章有疑问或需删除稿件,请联系 FreeBuf 客服小蜜蜂(微信:freebee1024)
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
dopromax LV.5
  • 32 文章数
  • 344 关注者
HTTPS单双向认证流程详解与联想
2022-03-08
逆向分析教程(七)——栈
2022-03-02
逆向分析教程(六)——CPU寄存器
2022-03-02
文章目录