JWT-token—前后端分离架构的api安全问题

admin 2021年11月18日17:17:00JWT-token—前后端分离架构的api安全问题已关闭评论422 views字数 2123阅读7分4秒阅读模式

前后端分离架构带来的好处一搜一大堆,我们来看一下分离后后端接口的安全问题。
前后端分离架构现状:

前端:vue项目,Nginx部署
后端:node.js和java项目

这样的情况后端api是暴露在外网中,因为常规的web项目无论如何前端都是要通过公网访问到后台api的,带来的隐患也有很多。
1.接口公开,谁都可以访问
2.数据请求的参数在传输过程被篡改
3.接口被重复调用
...

session和cookie局限性

session和cookie都是客户端与服务端通讯需要提供的认证,当客户端的值和服务器的值吻合时,才允许请求api,解决了第1个问题,但是当攻击者获取到了传输过程中的session或者cookie值后,就可以进行第2、3种攻击了

JWT的token机制

JWT标准的token包含三部分:

1.header(头部),头部信息主要包括(参数的类型--JWT,签名的算法--HS256)
2.poyload(负荷),负荷基本就是自己想要存放的信息(因为信息会暴露,不应该在载荷里面加入任何敏感的数据),有两个形式,下边会讲到
3.sign(签名),签名的作用就是为了防止恶意篡改数据

头部(Header)

头部用于描述关于该JWT的最基本的信息,例如其类型以及签名所用的算法等

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

将上面的JSON对象进行[base64编码]可以得到下面的字符串。这个字符串我们将它称作JWT的Header

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
载荷(Payload)

Payload也是一个JSON对象。包含了一些其他的信息

{
 "iss": "John Wu JWT",
 "iat": 1441593502,
 "exp": 1441594722,
 "aud": "www.example.com",
 "sub": "[email protected]",
 "from_user": "B",
 "target_user": "A"
}

这里面的前五个字段都是由JWT的标准所定义的。

*   `iss`: 该JWT的签发者
*   `sub`: 该JWT所面向的用户
*   `aud`: 接收该JWT的一方
*   `exp`(expires): 什么时候过期,这里是一个Unix时间戳
*   `iat`(issued at): 在什么时候签发的

将上面的JSON对象进行[base64编码]可以得到下面的字符串。这个字符串我们将它称作JWT的Payload

eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0

注意:Base64是一种编码,也就是说,它是可以被翻译回原来的样子来的。它并不是一种加密过程。

签名(Sign)

将上面的两个编码后的字符串都用句号.连接在一起(头部在前),就形成了

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0

最后,我们将上面拼接完的字符串用HS256算法进行加密。在加密的时候,我们还需要提供一个密钥(secret)。如果我们用mystar作为密钥的话,那么就可以得到我们加密后的内容

rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM

这一部分叫做签名

image

最后将这一部分签名也拼接在被签名的字符串后面,我们就得到了完整的JWT

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0.rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM

为什么要使用签名

签名解决了数据传输过程中参数被篡改的风险
一般而言,加密算法对于不同的输入产生的输出总是不一样的,如果有人对Header以及Payload的内容解码之后进行修改,再进行编码的话,那么新的头部和载荷的签名和之前的签名就将是不一样的。而且,如果不知道服务器加密的时候用的密钥的话,得出来的签名也一定会是不一样的。

sig2.png

服务器应用在接受到JWT后,会首先对头部和载荷的内容用同一算法再次签名。如果服务器应用对头部和载荷再次以同样方法签名之后发现,自己计算出来的签名和接受到的签名不一样,那么就说明这个Token的内容被别人动过的,我们应该拒绝这个Token

如何防范Replay Attacks

解决了篡改数据的问题,还有第3个问题,那就是攻击者不修改数据,只是重复攻击

所谓重复攻击就是攻击者发送一个后端服务器已接收过的包,来达到攻击系统的目的。

比如在浏览器端通过用户名/密码验证获得签名的Token被木马窃取。即使用户登出了系统,黑客还是可以利用窃取的Token模拟正常请求,而服务器端对此完全不知道,因为JWT机制是无状态的。

可以在Payload里增加时间戳并且前后端都参与来解决:

1.前端生成token时,在payload里增加当前时间戳
2.后端接收后,对解析出来的时间戳和当前时间进行判断,
3.如果相差特定时间内(比如2秒),允许请求否则判定为重复攻击

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2021年11月18日17:17:00
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   JWT-token—前后端分离架构的api安全问题http://cn-sec.com/archives/638953.html