聊聊怎么设计一个安全的对外接口

【摘要】我们在做公司项目的时候，特别是大数据相关的项目，经常会遇到需要提供对外的api接口，通常这些接口需要保证持续稳定地运行并且能够保障数据的安全，所以如何使用设计开发一个安全稳定的对外接口就显得尤为重要。

一、密码学基础

密码技术是网络安全的基础，也是核心。现在对隐私保护、敏感信息尤其重视，所以像平台类的系统如果要对外暴露接口，就一定有网络通信，很多信息都需要进行加密，以防止被截取篡改。现在先来了解一下密码学的基础概念。

1、基本概念

• 明文M：指没有经过加密的信息/数据。
• 密文C：明文被加密算法加密之后，会变成密文，以确保数据安全。
• 密钥K：是一种参数，它是在明文转换为密文或将密文转换为明文的算法中输入的参数。密钥分为对称密钥与非对称密钥。
• 加密E：将明文变成密文的过程。
• 解密D：将密文还原为明文的过程。

一个密码系统由以上五元组（M、C、K、E、D）组成，如图所示：

2、密码体制

(1)对称加密

对称加密是我们在发送方和接收方拥有相同密钥的地方，它可能是最常见的密码学形式。比如有一个加密邮件的密码或密钥，我有相同的密码来解密邮件，其他人无法阅读我们的消息或数据。

安全性依赖于：1、加密算法的安全性 2、密钥的秘密性
优点：算法公开、速度快、保密强度高、占用空间小
缺点：建立安全的信道之前，如何实现通信双方的加密密钥的交换
用途：适合批量存储或流应用
代表算法：DES算法、3DES算法、IDEA算法、AES算法

(2)非对称加密

在非对称加密算法中，有公钥和私钥两种密钥，其中公钥是公开的，不需要保密，私钥由个人持有，必须妥善保管和注意保密。加密和解密使用两种不同的密钥，用公钥加密，只有私钥能解密，用私钥加密，只有公钥能加密。

优点：通信双方不需要通过建立一个安全信道来进行密钥的交换，密钥空间小，降低了密钥管理的难度
缺点：实现速度慢，不适合通信负荷较重的情况；公钥对外公开，传输过程易被篡改
用途：加密关键性的、核心的机密数据
代表算法：RSA算法、ElGamal算法、椭圆曲线加密算法

(3)混合加密机制

对称加密的一个很大问题就是通信双方如何将密钥传输给对方，为了安全，一般采取带外传输，也就是说如果加密通信是在网络，那么密钥的传输需要通过其他途径，如短信，即使如此，也很难保证密钥传输的安全性。非对称加密加解最大的优点是事先不需要传输密钥，但速度慢，因此实际应用中，经常采取混合密码体制。假设A与B要实现保密通信，工作过程如下：

1、A找到B的公钥
2、A选择一个大随机数作为此次会话的加密密钥，即会话密钥
3、A以会话密钥加密通信内容，再以B的公钥加密会话密钥后发送给B
4、B收到数据以后，先用自己的私钥解密出会话密钥，然后用会话密钥解密出通信内容

二、常见安全风险

1、未授权访问

攻击者知道API地址和传入参数后，访问未授权的数据或操作

2、越权问题

攻击者试图访问权限范围外（水平越权或垂直越权）的数据或操作。

3、数据窃听

在调用API的传输过程中，数据可能会被窃听，比如恶意WIFI、DNS劫持、网络设备被黑等。

4、DDoS攻击

攻击者控制一群肉鸡，发起DDoS攻击（分布式拒绝服务攻击），导致接口被网络请求堵塞，无法正常服务。

5、资源耗尽攻击

攻击者利用接口漏洞来耗尽服务端资源。

6、重放攻击（Replay Attack）

攻击者获取一段报文后，重复多次请求接口。

7、注入攻击

攻击者传入一些畸形数据，让接口执行一些意想不到的操作。

8、篡改数据

攻击者获得一段报文后，篡改报文中的内容，再请求接口。

9、代码泄漏

代码或程序中含有敏感信息，当代码或程序泄漏后，敏感信息也被泄漏。

10、数据泄漏

接口返回了过多的数据，包括敏感数据。

11、API URL泄漏

使用HTTP GET调用API时，API URL上带有参数，因为API URL是明文传输的，因此网络中的网络节点都可能窃取这些参数数据。

三、接口安全方案

了解了密码学的基础概念以及常见的接口安全风险，个人觉得安全措施大体来看主要在两个方面，一方面就是如何保证数据在传输过程中的安全性，另一个方面是数据已经到达服务器端，服务器端如何识别数据，如何不被攻击；下面具体看看都有哪些安全措施。

1、 数据加密

我们知道数据在传输过程中是很容易被抓包的，如果直接传输比如通过 http 协议，那么用户传输的数据可以被任何人获取；所以必须对数据加密，常见的做法对关键字段加密比如用户密码直接通过 md5 加密；现在主流的做法是使用 https 协议，在 http 和 tcp 之间添加一层加密层 (SSL 层)，这一层负责数据的加密和解密。

现在主流的加密方式有对称加密和非对称加密，在前面密码技术介绍中已经提到，在此处不再作描述。

2、数据加签

数据加签就是由发送者产生一段无法伪造的一段数字串，来保证数据在传输过程中不被篡改；你可能会问数据如果已经通过 https 加密了，还有必要进行加签吗？数据在传输过程中经过加密，理论上就算被抓包，也无法对数据进行篡改；但是我们要知道加密的部分其实只是在外网，现在很多服务在内网中都需要经过很多服务跳转，所以这里的加签可以防止内网中数据被篡改。

数据签名使用比较多的是 md5 算法，将需要提交的数据通过某种方式组合和一个字符串，然后通过 md5 生成一段加密字符串，这段加密字符串就是数据包的签名，可以看一个简单的例子：

str：参数1={参数1}&参数2={参数2}&......&参数n={参数n}$key={用户密钥}; MD5.encrypt(str);

注意最后的用户密钥，客户端和服务端都有一份，这样会更加安全。

3、时间戳机制

数据是很容易被抓包的，但是经过如上的加密，加签处理，就算拿到数据也不能看到真实的数据；但是有不法者不关心真实的数据，而是直接拿到抓取的数据包进行恶意请求。这时候可以使用时间戳机制，在每次请求中加入当前的时间，服务器端会拿到当前时间和消息中的时间相减，看看是否在一个固定的时间范围内比如 5 分钟内；这样恶意请求的数据包是无法更改里面时间的，所以 5 分钟后就视为非法请求了。

解密后的数据，经过签名认证后，我们拿到数据包中的客户端时间戳字段，然后用服务器当前时间去减客户端时间，看结果是否在一个区间内，伪代码如下：

long clientTime = request.getparameter("clientTime");
long serverTime = System.currentTimeMillis();
if (serverTime - clientTime > interval) {
    return new Response("超过处理时长");
}

4、AppId 机制

大部分网站基本都需要用户名和密码才能登录，并不是谁来能使用我的网站，这其实也是一种安全机制；对应的对外提供的接口其实也需要这么一种机制，并不是谁都可以调用，需要使用接口的用户需要在后台开通 appid，提供给用户相关的密钥；在调用的接口中需要提供 appid + 密钥，服务器端会进行相关的验证。

生成一个唯一的 AppId 即可，密钥使用字母、数字等特殊字符随机生成即可；生成唯一 AppId 根据实际情况看是否需要全局唯一；但是不管是否全局唯一最好让生成的 Id 有如下属性：

• 趋势递增：这样在保存数据库的时候，使用索引性能更好

• 信息安全：尽量不要连续的，容易发现规律

• 关于全局唯一 Id 生成的方式常见的有类 snowflake 方式等

5、限流机制

本来就是真实的用户，并且开通了 appid，但是出现频繁调用接口的情况；这种情况需要给相关 appid 限流处理，常用的限流算法有令牌桶和漏桶算法。

常用的限流算法包括： 令牌桶限流， 漏桶限流， 计数器限流；

1. 令牌桶限流 令牌桶算法的原理是系统以一定速率向桶中放入令牌，填满了就丢弃令牌；请求来时会先从桶中取出令牌，如果能取到令牌，则可以继续完成请求，否则等待或者拒绝服务；令牌桶允许一定程度突发流量，只要有令牌就可以处理，支持一次拿多个令牌；

2. 漏桶限流 漏桶算法的原理是按照固定常量速率流出请求，流入请求速率任意，当请求数超过桶的容量时，新的请求等待或者拒绝服务；

可以看出漏桶算法可以强制限制数据的传输速度；

3. 计数器限流 计数器是一种比较简单粗暴的算法，主要用来限制总并发数，比如数据库连接池、线程池、秒杀的并发数；计数器限流只要一定时间内的总请求数超过设定的阀值则进行限流；

具体基于以上算法如何实现，Guava 提供了 RateLimiter 工具类基于基于令牌桶算法：

RateLimiter rateLimiter = RateLimiter.create(5);

以上代码表示一秒钟只允许处理五个并发请求，以上方式只能用在单应用的请求限流，不能进行全局限流；这个时候就需要分布式限流，可以基于 redis+lua 来实现。

6、黑名单机制

如果此 appid 进行过很多非法操作，或者说专门有一个中黑系统，经过分析之后直接将此 appid 列入黑名单，所有请求直接返回错误码。

如何为什么中黑我们这边不讨论，我们可以给每个用户设置一个状态比如包括：初始化状态，正常状态，中黑状态，关闭状态等等；或者我们直接通过分布式配置中心，直接保存黑名单列表，每次检查是否在列表中即可。

7、数据合法性校验

这个可以说是每个系统都会有的处理机制，只有在数据是合法的情况下才会进行数据处理；每个系统都有自己的验证规则，当然也可能有一些常规性的规则，比如身份证长度和组成，电话号码长度和组成等等；

合法性校验包括：常规性校验以及业务校验；

常规性校验：包括签名校验，必填校验，长度校验，类型校验，格式校验等；

业务校验：根据实际业务而定，比如订单金额不能小于 0 等。

四、总结

基于接口的安全防范要求，保障接口的安全稳定运行，可以通过以上各种方法结合的方式来实现。如果有条件的情况下，也可以建立一套比较完备的授权认证解决方案来保障对外接口的安全性。