背景:
设计一个 http 接口,给客户端访问,但是这个接口会访问 redis 和 mysql,所以这个接口如果被别人知道,恶意攻击,可能会导致 redis 或 mysql 炸掉,所以有没有什么可行性的方案? 我的解决方法:
后端和前端约定一个 token,该接口是 post 方法请求,客户端每次请求都会在 form 中携带这个 token,后端通过比较这个 token,如果一致则执行业务代码,反之返回。因为 web 服务器前有一层 slb,ssl/tls 加在 slb 上,所以这样中间人应该获取不到这个 token 吧? 这样安全吗?比如说,攻击人能从 app 程序二进制获取 token? 或者还有没有别的方案?
最近开项目，就遇到同样的问题我的做法是这样的（也是比较通用的做法）：
具体思路就是，客户端与服务端约定一个密钥（密码串），然后将请求的 GET POST 数据与客户端版本，当前时间戳，唯一随机数打包成一个字符串后用密钥签名（ RSA Sign or hash ），放进 header 头传回服务器。
服务器根据客户端版本选择密钥对数据进行验签核对时间，并检查 Redis 是否存在此唯一随机数，通过就将 唯一随机数存至 Redis，一分钟后过期。
只要保证客户端这边没有被反编译，就基本安全（没有绝对的安全，涉及到客户端的，一定有可能被破解）
约定好加密方法然后每次请求带上时间戳和加密数据, 用事先交换好的密钥去加密 请求参数+时间戳, 得到的数据和服务器上计算对比, 不一致直接返回错误
如果你想问 4l 这种风控的问题, 就没那么简单了
限制访问可以用限流+拉黑这种方法
为了防止恶意重放攻击，可以实现如下:
api?data=abc&time=时间戳&code=1000&hash=xxxx
其中 hash 规则是 md5(abc + 时间戳 + 干扰码)
时间戳和 time 的保持一致，为了后端做超时检测, 干扰码和 code=1000 存在对应关系。
即你有一张表,事先生成了一堆序号和干扰码,干扰码对应的序号只有你和 APP 知晓，保证不能泄漏(实际上坏人需要花时间破解)
你每次收到消息后按照同样的方法计算 hash 比较，发现 hash 比对不上，就说明数据被篡改，时间戳超时可能是重放。服务器就直接丢弃，返回错误给前端