加密那点小事

Posted 2021-01-29 damai

几个月前，我们前端被通知要在请求头上加几个请求头，都是加密的内容，目的是解决前后数据的安全性。之前一点不理解，一直觉得前端没有秘密可言，安全的事情交给后台就完事了。。。

 

然后最近看了一些书，发现自己有点年轻，传输的数据没有加密就传送给后台，只要中间人拿到请求的参数token后，就可以为所欲为了。

故事背景：

事情是这样的，鄙司是前后分离的，所以数据都是走的接口，就拿登录来说吧（其实我个人觉得登录时最难），通常前端传入后台两个字段 `user`和`password`当然都是明文的。

user:‘admin‘,
passWord:‘123456‘

然后后台会返回前端一个`token`，然后以后的每次请求我们都会在接口的head上面多加一个字段`token`用来验证用户是否正在登陆，当然`token`也是有实效的，固定时间内检测是否过期。

这里面就会存在一个问题，中间人拿到其他人的tonke来伪造的话就会造成很大的问题，当时也没有做其他的验证方式。比如某某发表一篇言论‘*****‘又或者提现等等。。。问题特别严重。

那么这种问题该如何解决呢？

首先想到的是https，用他来传输应该没问题吧，大公司出品，必出精品！

1. 浏览器发送请求(https://xxx.com)   到服务器
2. 服务器发送数字证书(包含服务器的公钥)
3. 浏览器用预置的CA列表验证证书，如果有问题就提示有风险，你别登陆了！！
4. 浏览器生成随机的对称秘钥，用服务器的公钥加密
5. 服务器用自己的秘钥进行解密，等到对称的秘钥
6. 前后端都知道了秘钥，用他来加密通信

好像问题解决了，但是尴尬的问题还是出现了，之前写的那么多接口咋办，而且我们当时也没有写接口文档的习惯，都是口口相传（其实就是有一些临时的bug修改增删改接口参数），但是极少成多，这个问题就变得十分严重！！！

我们又想到一个办法，既然知道https是怎么处理的，那我们自己写一套自己的规则不就行了。

接口还是原来的接口，前后端在处理登录接口的时候需要加密一下请求的参数，登录的时候必须保障安全。其次每个请求头加一个前后公用的加密解密规则，（如：xx + 当前的时间戳 + 6位随机位），还有当前的域名 ，时间 + 6位随机数 加密。在加上当前的版本号。

1. 登录必须用加密的参数的请求
2. 前后端的通信方式用加密方式，后台只要存储加密的结果就行了，然后返回tonken(用户的密码是加密不可逆的)
3. 验证前端的请求头，时间，6位随机数，当前的域名，版本号，这些是必填的，后台也是必须验证的，如果出现时间+随机数相同那么断开请求，重新登录
4. 后台拿着前端给的加密结果返回tonken，后面的所以接口的请求头必须要有上面的参数做验证

后台解密需要知道加密算法，这样拿到解密之后的请求参数在去返回数据，这样最大限度的方式解决被盗用的风险。

举个例子：后台想要解密 一段加密的请求参数，需要获取 时间戳+6随机数 

 

 这样登录的安全问题似乎是解决了，最起码中间人不知道算法的情况下是无法解析请求的参数的，即使拿到tonken也不行！

我尝试逆向的解发现在不知道密码的情况下，我个人的水平无法解开。

这样问题就解决了，也不会对代码产生多大的影响，可以说是当下最好的解决方案了。