今天跟大家聊一聊优雅的接口防刷处理方案._接口防重刷策略设计-CSDN博客

本文链接：https://blog.csdn.net/2301_76936922/article/details/130159637

防篡改

如何解决

防重放

基于timestamp的方案

基于nonce + timestamp 的方案

代码实现

1、构建请求头对象

2、工具类从HttpServletRequest获取请求参数

3、签名验证工具类

4、HttpServletRequest包装类

5、创建过滤器实现安全校验

6、Redis工具类

对于互联网来说，接口安全问题是无法避免的。如果你的接口在外网裸奔，黑客只需要知道接口的地址和参数就可以调用，这将导致严重的安全威胁。

让我们来举个例子。当用户在您的网站上注册时，他们需要填写手机号码并接收手机验证码。如果发送验证码的接口没有得到特殊的安全处理，那么黑客可能会利用这个漏洞盗刷短信接口，并且您也不会知道他们浪费了多少钱。

因此，为了保证接口的安全性，我们需要采取一些措施。例如，我们需要在暴露在外网的API接口上实施防篡改和防重放的措施，这样才能称之为安全的接口。

防篡改

我们知道http 是一种无状态的协议，服务端并不知道客户端发送的请求是否合法，也并不知道请求中的参数是否正确。

举个例子, 现在有个充值的接口，调用后可以给用户增加对应的余额。

如果非法用户通过抓包获取到接口参数后，修改user_id 或 amount的值就可以实现给任意账户添加余额的目的。

如何解决

采用https协议可以将传输的明文进行加密，但是黑客仍然可以截获传输的数据包，进一步伪造请求进行重放攻击。如果黑客使用特殊手段让请求方设备使用了伪造的证书进行通信，那么https加密的内容也会被解密。

一般的做法有2种：

采用https方式把接口的数据进行加密传输，即便是被黑客破解，黑客也花费大量的时间和精力去破解。
接口后台对接口的请求参数进行验证，防止被黑客篡改；

一般情况下，黑客从抓包重放请求耗时远远超过了60s，所以此时请求中的timestamp参数已经失效了。如果黑客修改timestamp参数为当前的时间戳，则sign1参数对应的数字签名就会失效，因为黑客不知道签名秘钥，没有办法生成新的数字签名。

对于重放攻击一般有两种做法：

基于timestamp的方案

每次HTTP请求，都需要加上timestamp参数，然后把timestamp和其他参数一起进行数字签名。因为一次正常的HTTP请求，从发出到达服务器一般都不会超过60s，所以服务器收到HTTP请求之后，首先判断时间戳参数与当前时间比较，是否超过了60s，如果超过了则认为是非法请求。

步骤1：客户端使用约定好的秘钥对传输的参数进行加密，得到签名值sign1，并且将签名值也放入请求的参数中，发送请求给服务端
步骤2：服务端接收到客户端的请求，然后使用约定好的秘钥对请求的参数再次进行签名，得到签名值sign2。
步骤3：服务端比对sign1和sign2的值，如果不一致，就认定为被篡改，非法请求。

防重放

防重放也叫防复用。简单来说就是我获取到这个请求的信息之后什么也不改,，直接拿着接口的参数 重复请求这个充值的接口。此时我的请求是合法的, 因为所有参数都是跟合法请求一模一样的。

重放攻击会造成两种后果：
针对插入数据库接口：重放攻击，会出现大量重复数据，甚至垃圾数据会把数据库撑爆。
针对查询的接口：黑客一般是重点攻击慢查询接口，例如一个慢查询接口1s，只要黑客发起重放攻击，就必然造成系统被拖垮，数据库查询被阻塞死。