公众号矩阵
移动端

Web 安全 - 同事告诉我 JWT 是明文的...

安全 应用安全
JWT 由服务端生成可以存储在客户端,对服务端来说是无状态的,可扩展性好。一旦 token 泄漏,任何人都可以使用,为了减少 token 被盗用,尽可能的使用 HTTPS 协议传输,token 的过期时间也要设置的尽可能短。

一天 “小张” 接到一个需求 “一旦用户登陆认证成功之后,后续的请求可以携带一个令牌,无需再次身份认证”。

这时 “小张” 咨询了资深搬砖工程师 “小李”,凭借多年的搬砖经验,同事 “小李” 说到:HTTP 协议是无状态的,在第一次登陆认证成功后,下一次请求时,服务器也不知道请求者的身份信息。通常有两种实现方式:

  • 一种传统的做法是在服务器上存储用户 session 信息,每次请求时携带 sessionID 进行验证,这种方式缺点是会占用服务器内存,当用户越来越多会增加服务器的内存开销、由于存储在内存还会带来扩展性问题。
  • 第二种方法是采用 JWT 技术,它是一种无状态的身份验证。只做校验,将用户状态分散到了客户端,服务器端不会进行信息存储。

“小张” 听完后,连忙说到第二种听着不错哦,搜索了一些必威体育中文app相关的文章介绍之后就开始了愉快的代码编写。完成之后提交了代码给同事 “小李” 做 code review,做为资深搬砖工程师的 “小李”,一眼看出了问题:“怎么能在 JWT 生成的 token 里放用户密码呢!JWT 默认是明文的,不能存储隐私信息”。

“小张” 不解,反问道:怎么会是明文呢,加密之后的数据我看了的,是一堆乱码啊,下面是打印的 token 信息。

// jwt 签名后生成的 token
"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6IuW8oOS4iSIsInBhc3N3b3JkIjoxMjM0NTYsImlhdCI6MTY2MTg2OTQxMX0.3-60HUf_cKIo44hWUviNzqdUoUGngGQfrqffg0A6uqM"

“小李” 通过一段 Node.js 代码展示了如何解密出 JWT 签名后的 token 数据。

图片

此时的 “小张” 陷入了沉思,顿时心里产生了两个疑问🤔️:

  • 签名时使用了 secret 了,生成的 token 看着就是一串乱码的字符啊,为什么是明文呢?
  • 按照上面这样解析 token 中签名的数据,数据会不会被篡改呢?

带着这两个疑问,下一步让我们一块了解下 JWT 的原理。

JWT 原理

JWT 全称 JSON Web Token,是一种基于 JSON 的数据对象,通过技术手段将数据对象签名为一个可以被验证和信任的令牌(Token)在客户端和服务端之间进行安全的传输。

JWT Token 由三部分组成:header(头信息)、payload(消息体)、signature(签名),之间用 .​ 链接,构成如下所示:

图片

Header 部分由 JSON 对象 ​{ typ, alg }​ 两部分构成,使用 base64url(header) 算法转为字符串:

  • typ:表示令牌类型,JWT 令牌统一写为JWT
  • alg:签名算法,默认为HS256​,支持的算法为['RS256', 'RS384', 'RS512', 'ES256', 'ES384', 'ES512', 'HS256', 'HS384', 'HS512', 'none']

Payload 部分为消息体,用来存储需要传输的数据,同样也是一个 JSON 对象使用base64url(payload) ;算法转为字符串,JWT 提供了 7 个可选字段供选择,也可以自定义字段:

  • iss (issuer):签发人
  • exp (expiration time):过期时间
  • sub (subject):主题
  • aud (audience):受众
  • nbf (Not Before):生效时间
  • iat (Issued At):签发时间
  • jti (JWT ID):编号

Signature 是对 Header、Payload 两部分数据按照指定的算法做了一个签名,防止数据被篡改。需要指定一个 sceret,产生签名的公式如下:

HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
your-256-bit-secret
)

生成签名后,将 header.payload.signature 三部分链接在一起,形成一个令牌(token)返回给客户端。

问题答疑

这就是 JWT 的原理,了解之后并没有那么神秘,回答上面的几个问题。

签名时使用了 secret,为什么是明文?

header、payload 部分是使用 base64 算法进行的编码,并没有被加密,自然也可以被解码。但注意这里的 base64 算法有点不一样的地方在于,token 可能会被放在 url query 中传输,URL 里面有三个特殊字符会被替换。下面是 JWT 中 base64url 的实现方式:

// https://github1s.com/auth0/node-jws/blob/HEAD/lib/sign-stream.js#L9-L16
function base64url(string, encoding) {
return Buffer
.from(string, encoding)
.toString('base64')
.replace(/=/g, '')
.replace(/\+/g, '-')
.replace(/\//g, '_');
}

还需要注意 payload 对象放置的内容越多,base64 之后的字符串就越大,同理签名后的 token 也一样。

数据会不会被篡改?

数据一旦被篡改,到服务端也会认证失败的,服务端在生成签名时有一个重要的参数是 secret,只要保证这个密钥不被泄漏,就没问题,就算篡改也是无效的。

Node.js 示例演示

在 Node.js 中使用 JWT 需要用到 jsonwebtoken 这个库,API 很简单,主要用到两个方法:

  • sign():生成签名
  • verify():验证签名
const crypto = require('node:crypto');
const jwt = require('jsonwebtoken');

const secret = crypto.createHmac('sha256', 'abcdefg')
.update('')
.digest('hex');

const payload = {
"username": "张三",
"password": 123456,
iat: 1516239022
};
const token = jwt.sign(payload, secret)
const result = jwt.verify(token, secret)

总结

JWT 由服务端生成可以存储在客户端,对服务端来说是无状态的,可扩展性好。

上文我们也讲了 JWT 中传输数据的 payload 默认是使用 base64 算法进行的编码,看似一串乱码,实则是没有加密,因此不要将涉及到安全、用户隐私的数据存放在 payload 中,如果要存放也请先自己进行加密。

一旦 token 泄漏,任何人都可以使用,为了减少 token 被盗用,尽可能的使用 HTTPS 协议传输,token 的过期时间也要设置的尽可能短。

防止数据被篡改,服务端密钥(secret)很重要,一定要保管好。

责任编辑:武晓燕 来源:
相关推荐

2022-08-14 09:00:00

2022-08-19 08:17:36

2021-05-26 08:49:15

2022-08-15 09:22:12

2022-05-25 09:00:00

2022-04-21 09:00:00

2022-04-06 07:50:57

2022-03-23 12:45:12

2022-03-02 07:43:32

2022-05-11 08:45:49

2022-05-17 07:35:13

2022-03-01 09:31:06

2021-12-30 08:13:00

2021-02-19 08:20:42

2019-10-18 14:33:21

2022-01-18 08:12:34

2021-09-28 06:57:22

2022-01-06 21:16:57

2021-07-11 12:12:49

2021-10-11 20:22:27

点赞
收藏

51CTO技术栈公众号

业务
速览
在线客服
  • 媒体
  • 51CTO
  • 社区
  • 教育
  • 必威体育app手机下载 龙8国际龙 必威体育app官方版下载 龙8官网手机版国际 龙8国际pt官方网站 龙8国际官网注册 必威体育精装版app下载 龙8娱乐游戏国际 必威体育app官方版下载 必威体育app手机版