前后端分离架构带来的好处一搜一大堆,我们来看一下分离后后端接口的安全问题。
前后端分离架构现状:
这样的情况后端api是暴露在外网中,因为常规的web项目无论如何前端都是要通过公网访问到后台api的,带来的隐患也有很多。
1.接口公开,谁都可以访问
2.数据请求的参数在传输过程被篡改
3.接口被重复调用
...
session和cookie局限性
session和cookie都是客户端与服务端通讯需要提供的认证,当客户端的值和服务器的值吻合时,才允许请求api,解决了第1个问题,但是当攻击者获取到了传输过程中的session或者cookie值后,就可以进行第2、3种攻击了
JWT的token机制
JWT标准的token包含三部分:
头部(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": "jrocket@example.com",
"from_user": "B",
"target_user": "A"
}
这里面的前五个字段都是由JWT的标准所定义的。
* `iss`: 该JWT的签发者
* `sub`: 该JWT所面向的用户
* `aud`: 接收该JWT的一方
* `exp`(expires): 什么时候过期,这里是一个Unix时间戳
* `iat`(issued at): 在什么时候签发的
将上面的JSON对象进行[base64编码]
可以得到下面的字符串。这个字符串我们将它称作JWT的Payload
eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0
签名(Sign)
将上面的两个编码后的字符串都用句号.
连接在一起(头部在前),就形成了
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0
最后,我们将上面拼接完的字符串用HS256算法
进行加密。在加密的时候,我们还需要提供一个密钥(secret)
。如果我们用mystar
作为密钥的话,那么就可以得到我们加密后的内容
rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM
这一部分叫做签名
最后将这一部分签名也拼接在被签名的字符串后面,我们就得到了完整的JWT
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0.rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM
为什么要使用签名
签名解决了数据传输过程中参数被篡改的风险
一般而言,加密算法对于不同的输入产生的输出总是不一样的,如果有人对Header以及Payload的内容解码之后进行修改,再进行编码的话,那么新的头部和载荷的签名和之前的签名就将是不一样的。而且,如果不知道服务器加密的时候用的密钥的话,得出来的签名也一定会是不一样的。
如何防范Replay Attacks
解决了篡改数据的问题,还有第3个问题,那就是攻击者不修改数据,只是重复攻击
比如在浏览器端通过用户名/密码验证获得签名的Token被木马窃取。即使用户登出了系统,黑客还是可以利用窃取的Token模拟正常请求,而服务器端对此完全不知道,因为JWT机制是无状态的。
可以在Payload里增加时间戳并且前后端都参与来解决: