前后端分离-关于接口加密的实战记录

五六散人

2022 年 01 月 09 日

28 次浏览

暂无评论

1775字数

服务器

## 实现步骤

### 大家都知道前后端分离接口是用 session 或者是 token 进行鉴权，这种方式是无法抵住参数篡改的，可能会被 sql 注入；

参数篡改的概念比如：一个最常见的列表接口，有分页功能，比如 page:1,size:10;攻击者可能会利用这个漏洞直接修改 size:10000,这就会有几率让爬虫直接拉取到我们全部的数据；
![](https://qdqts.oss-cn-qingdao.aliyuncs.com/blog/20220324100632.png)
上图就是一个标准的列表接口，入参是 type、page、size，下图是进行改造后的入参
![](https://qdqts.oss-cn-qingdao.aliyuncs.com/blog/20220324100654.png)

令篡改攻击者无从下手。

### 最终实现加密用了三层：

1、jwt（token 基本鉴权)
2、md5 计算 sign，杜绝参数篡改
3、aes 对称加密，拒绝参数可读
第一层加密就不讲了，大家都会，jwt 鉴权是最基础的。
第二层加密，杜绝参数篡改，具体实现逻辑如下：
前端除了要传的所有的参数，额外多加三个参数：随机字符串、时间戳、自定义秘钥、sign

#### 这三个参数的用处是：

- 随机字符串可以保证 加密串实时变化，每次的加密串必定不会相同。
- 时间戳：后端解析到时间戳以后，可以对比当前时间戳与接口时间戳，如果相差太大 可以直接拒绝请求（我当前实现为 6000 毫秒，即 1 分钟）
- 自定义秘钥：即前端隐式秘钥，后端与前端自定义的秘钥保持一致，前端请求时 需要移除该秘钥；这个自定义秘钥还有一个好处，如果我们是 app 的话，我们之前打的包想一次性全部失效，前后端在新版同步更新秘钥即可。
- sign，综合了所有请求参数的一个计算值，计算方式为：md5(按照字段首字母排序(前端参数+随机字符串+时间戳+自定义秘钥)).

后端拿到请求到的数据，第一时间，用同样的方式，把所有参数按照首字母排序的规则，md5 加密生成 sign，校验与前端传递的 sign 是否一致。
完成了第二层加密的请求图如下：

![](https://qdqts.oss-cn-qingdao.aliyuncs.com/blog/20220324100707.png)

有了上述的校验参数，已经抵住了 99%的参数篡改请求，剩下 1%就是特别想攻破你的接口，就特别特别想，他很坚持，会研究你的加密方式，那这样经过时间也会推敲出来加密方式，包括设置的自定义秘钥也会获得到。
还有一种增加破解难度的方法，就是加密一下前端代码，效果如下：

![](https://qdqts.oss-cn-qingdao.aliyuncs.com/blog/20220324101556.png)

加密后的可读性更差。
到这就完成了第二层的加密。
最后第三层加密，是 aes 对称加密，这一步就比较简单，加载一个 aes 加密包，把所有的参数 以字符串方式进行加密

![](https://qdqts.oss-cn-qingdao.aliyuncs.com/blog/20220324100730.png)

因为 aes 是对称加密，就把最后加密的字符串传递到后端，后端用同样的 aes 秘钥和偏移量进行解密，最终实现如下图：

![](https://qdqts.oss-cn-qingdao.aliyuncs.com/blog/20220324100740.png)

后端的活动
![](https://qdqts.oss-cn-qingdao.aliyuncs.com/blog/20220324101805.png)

分享完毕！

# 总结

这种加密方式其实也是有利有弊：
好处就是能防止 99.9%的参数篡改攻击，所有的加密安全都是防君子不防小人；有人潜心研究你的接口，终究是可以破解的。
坏处就是给测试阶段造成了困扰，入参需要通过打印的方式看控制台，Network 中看到传递的参数都是加密后的。