Spring Boot如何保障接口安全?
1. 数据加密
数据在传输过程中是很容易被抓包的,如果直接传输,数据可以被任何人获取,所以必须对数据加密。加密方式有对称加密和非对称加密:
对称加密:对称密钥在加密和解密的过程中使用的密钥是相同的,常见的对称加密算法有 DES、AES。优点是计算速度快,缺点是在数据传送前,发送方和接收方必须商定好密钥,并完好保存。如果一方的密钥被泄露,那么加密信息也就不安全了;
非对称加密:服务端会生成一对密钥,私钥存放在服务器端,公钥可以发布给任何人使用。与对称加密相比,这种方式更安全,但速度慢太多了。
现在主流的做法是使用 HTTPS 协议,在 HTTP 和 TCP 之间添加一层加密层 (SSL 层),这一层负责数据的加密和解密。HTTPS 的实现方式结合了对称加密与非对称加密的优点,在安全和性能方面都比较突出。关于如何开启https,可以参考这篇https://jxausea.medium.com/spring-boot-integrated-https-quick-start-demo-0f5b1ae86286
2. 数据加签
数据加签就是由发送者产生一段无法伪造的数字串,来保证数据在传输过程中不被篡改。数据如果已经通过 HTTPS 加密了,其加密部分只是在外网,而加签可以防止内网中数据被篡改。数据签名使用较多的是 MD5 算法,将需要提交的数据通过某种方式组合,然后通过 MD5 生成一段加密字符串,这段加密字符串就是数据包的签名。而其中的用户密钥,客户端和服务端都保留一份,会更加安全。3. 时间戳机
3. 时间戳机制
数据经过如上的加密、加签处理后,就算被抓包也不能看到真实的数据。但是有的不法者不关心真实数据,而是直接拿到抓取的数据包进行恶意请求。这时可以使用时间戳机制,在每次请求中加入当前的时间,服务器端会拿到当前时间与消息中的时间相减,看看是否在一个固定的时间范围内,比如 5 分钟,这样恶意请求的数据包是无法更改时间的,所以 5 分钟后就视为非法请求了。
4. AppId 机制
大部分网站都需要用户名和密码才能登录,这其实也是一种安全机制。相应的对外接口也需要这么一种机制,使用接口的用户需要在后台开通 AppID,提供给用户相关的密钥。在调用的接口中需要提供 AppID+ 密钥,服务器端会进行相关的验证。生成唯一的 AppID 即可,根据实际情况看是否需要全局唯一,同时密钥使用字母、数字等特殊字符随机生成。
5. 限流机制
本来就是真实的用户,并且开通了 AppID,但出现了频繁调用接口的情况,这时需要给相关 AppID 限流处理,常用的限流算法包括:令牌桶限流、漏桶限流、计数器限流。令牌桶算法的原理是系统以一定速率向桶中放入令牌,填满了就丢弃令牌。请求来时会先从桶中取出令牌,如果能取到令牌,则可以继续完成请求,否则等待或者拒绝服务。令牌桶允许一定程度突发流量,只要有令牌就可以处理,支持一次拿多个令牌。漏桶算法的原理是按照固定常量速率流出请求,流入请求速率任意,当请求数超过桶的容量时,新的请求等待或者拒绝服务,漏桶算法可以强制限制数据的传输速度。计数器算法比较简单粗暴,主要用来限制总并发数,比如数据库连接池、线程池、秒杀的并发数。计数器限流只要一定时间内的总请求数超过设定的阀值,就会进行限流。
6. 黑名单机制
如果一个 AppID 进行过很多非法操作,或者专门有一个中黑系统,经过分析之后可以直接将此 AppID 列入黑名单,所有请求直接返回错误码。如何查看黑名单列表呢?可以给用户设置一个状态比如:初始化状态、正常状态、中黑状态、关闭状态等等。或者直接通过分布式配置中心,保存黑名单列表,每次检查用户是否在列表中即可
7. 数据合法性校验
这是每个系统都会有的处理机制,只有在数据合法的情况下才会进行数据处理。每个系统都有自己的验证规则,当然也可能有一些常规性的规则,比如身份证号码长度和组成、电话号码长度和组成等等。合法性校验包括常规性校验以及业务校验,前者包括签名校验、必填校验、长度校验、类型校验、格式校验等,后者根据实际业务而定,比如订单金额不能小于 0 等等。