JWT的安全问题

一、前言

在如今,微服务架构越来越流行了,项目也越来越多采用前后端项目分离,一般在权限控制中采用JWT进行处理。

二、JWT介绍

JWT是一种认证协议是最后输出为token,然后把token进行传到客户端,客户端访问api通过filter解析token,获得jwt中的信息,进行判断操作。

jwt分为三部分 ,header、body、sign 。 header是具有哈希算法、以及typ类型。

哈希算法可以采用SHA256等 ,哈希算法不是加密算法。它是值把一个值进行通过哈希碰撞生成一个加密的值,是不存在解密的,唯一解密的方式就是重复试值进行碰撞产生相同的值。

body是值我们需要传入的信息,一般不要进行敏感的信息。然后header算法对body数据加密的

sign签名就是对上面二个值进行签名,然后生成签名概要,是通过自己的私钥进签名,可以避免数据的修改。

三、安全问题

1.如果其他用户获得我们电脑上的token,那么他们就能模仿真实用户进行操作(黑客监控电脑,获得网站发送的token,进行操作)?

     对于敏感的api接口,需使用https 。https是在http超文本传输协议加入SSL层,它在网络间通信是加密的,所以需要加密证书。

2.我们是否可以伪造用户token进行访问?

不可以,因为你无法使用服务器的签名,就是你自己的密钥签名的信息服务器识别不了。

3.我们是否可以修改token中body的信息?

不能,修改了之后签名信息就不正确,然后就无法验证签名,说明数据被修改了。

四. csdn中的http和https的一种回复

Question:app登录后,服务端返回一个token,app存在客户端,下次再打开app时,直接读token,传token到服务端做验证,免去重新输入用户密码的麻烦,这个token存储在header里,目前看大多数app都是这样做,但如果黑客抓包获取到token,伪造http 请求,对服务器做操作,那岂不是很不安全。。。

Answer:这方法确实不好啊,不能只依赖于http的header里的东西来认证,太容易模仿。最简单的方法可能就是走https,客户端只要接受服务器端的签名即可。

理解:签名就是验证信息的唯一性,如果中间人进行获得token,那么无法进行公钥签名,服务器获得token之后还要进行解密的,因此这个方法可以进行避免攻击。

中间人如何抓包获取局域网的http请求?

五、总结

     对于敏感的api接口,需使用https 。https是在http超文本传输协议加入SSL层,它在网络间通信是加密的,所以需要加密证书。

猜你喜欢

转载自www.cnblogs.com/fc520/p/11944362.html