如何让你的API接口更加的安全？

个人博客原文链接

 

前言

---

作为一名后端开发，可能你所认为的接口设计，就是定义好以下几大要素：

• 接口名

• 接口参数

• 接口返回值

• 接口访问URL（包括访问方式，GET/POST/PUT/DELETE）

• 接口版本

 

确实没错，以上是接口设计的基本且必要的元素，但，它们所表达的只是一种接口API规范，安全与否，另有门道！

 

*以下所说的接口，皆指对外接口，即提供给外部访问的接口API。

 

作为后端开发，我们需要设计接口提供给前端访问做数据交互。通常，我们设计的接口是否够安全，主要体现在两方面：

• 如何保证数据在传输过程中的安全性，体现为数据的保密性与一致性

• 服务器如何缜密地接收并处理数据，保证不被攻击

 

设计方案

---

我们可以从以下几个方面来让我们的接口更加的安全：

• 数据加密

• 数据加签

• 时间戳机制

• 黑名单

• 数据合法性校验

• Token机制

• 限流访问

  ​

其中，前两种，我们用作数据传输时，保证传输过程的更加安全可靠；后五种，则用于服务器对数据及访问者的缜密处理，加固自身防范。

 

数据加密

数据加密很好理解了，我们平时做的登录操作，涉及到了最敏感的用户名和密码数据，如果不做数据加密，这些敏感、隐私数据随时都有可能会泄漏，造成各种各样的损失。而数据加密，通常有以下两种方式：

• 对称加密：对称加密即密钥对称，加密和解密的过程使用的密钥是相同的。常见的对称加密算法有DES、AES。

  优点：计算处理速度快

  缺点：由于使用加密解密使用的是相同的密钥，密钥本身的安全性并不是十分乐观，只要一方泄漏，全盘皆输。

• 非对称加密：非对称加密则使用一对不同的密钥（公钥和私钥）做加解密。公钥加密，私钥可解密；反过来，私钥加密，公钥可解密。但通常可不会像后者那样干，所谓的公钥即对外公布的，私钥则自己掌管，所以公钥加密，私钥解密，更加安全，也更加合理。常见的非对称加密有RSA。

  优点：安全性高

  缺点：计算处理速度慢

我们平时访问网站时用到的https协议，即结合了对称加密和非对称加密的优点，在处理速度和安全方面做到了比较好的平衡，因此https相对于http更加安全，前者是做过数据加密的，攻击者不容易进行数据窥探。

此时可能你会有疑问，我们平时所做的抓包，或者直接使用浏览器的调试工具进行调试时，尽管是https协议，不也照样看到了数据明文，所谓的数据加密在哪？其实你在抓包时，看到的都是抓包软件处理过后的数据，那么你是否了解抓包软件在拿到原始数据时做了哪些处理和操作吗？关于这点，我打算在另外一篇文章讲述，这不是本篇文章的关注点。

 

数据加签

数据加密让我们的数据在传输过程中不容易泄漏，而数据加签则是让我们的数据不被篡改，或者不能说不被篡改（攻击者想要篡改数据很简单），应该说是让我们能够分辨出数据是否有被篡改。

数据签名使用比较多的算法则是我们耳熟能详的MD5算法，数据签名校验基本流程如下：

对要传输数据的某一部分，通过MD5算法生成一段字符串，然后把这段字符串与数据一起加密传输；接受者拿到数据后先进行数据解密，并得到那一段字符串，然后使用MD5算法对同样一段数据进行处理，得出的字符串如果与接受到的字符串一致，则证明数据没有被篡改，否则就是被篡改过了。原理很简单是吧？

 

时间戳机制

数据经过加密、加签后，数据就比较安全了，就算被抓包也不会泄露真实数据。但是有些时候攻击者并不关心你的数据是否真实，他可能是想恶意请求以攻击或者骚扰我们的服务器。这种情况，可以考虑对接口API加上时间戳，即规定每次像服务器发送请求都必须带上当前请求的时间戳，服务器则设定一个时间间隔，对于同样一个URL请求，服务器拿到当前的时间戳与上一次的时间戳做对比，如果在设设定的时间间隔内，则认为请求过于频繁，属于恶意请求，不予以处理或者返回错误码响应。

 

黑名单机制

API接口做了时间戳机制后，服务器拦截了那些高频率的相同请求，保证了服务器压力不容易过载。但是，有些时候，我们的API接口是以正常频率被访问，却接受到了很多恶意非法操作。怎样算非法，可在服务器端自行定义，比如服务器规定，用户登录注册接口的密码参数不允许带中文，若在短时间内，连续接受到同一个用户（同一个IP）带中文密码的注册请求，则可认定是恶意非法操作。此时可采用黑名单机制，在服务器存储一个黑名单表，若检测到有恶意操作用户，则将其加入黑名单，每当用户请求时，都先查询黑名单，如果在在黑名单中，则不予以处理或反回错误码。

 

数据合法性校验

黑名单原则中，我们通过了参数校验来判定用户操作是否非法，即我们的接口要做数据合法性校验。数据合法性校验是每个API接口最基本的安全防护手段了，它甚至可以说成是一种应该要遵循的规范，服务器要更有效的运作，则需要过滤掉那些无效的请求，同时确保服务器上存储的数据是有效的，比如用户注册，要是不做数据合法性校验，用户直接传来一个空值作为用户名或者密码，然后服务器直接存储，是非常不合理也不安全的。因此，为我们的每一个API接口定制好数据合法性规则，十分必要。

 

Token机制

有些时候，我们设计的API接口是有定制性的，即只提供给指定的用户访问，其他用户均予以拦截，这种情况就可以采用token机制了。所谓的token机制理解起来跟我们平时的登录差不多，有些操作需要在登录之后才能请求，非登录状态下请求须登录状态的API，则直接拦截。token机制也同理，我们在服务器生成存储一份用户唯一身份的令牌token，然后对于特定的接口规定必须带有有效且合法的token才允许访问，否则拦截不予以处理。至于合法用户如何得到token或者服务器如何分配并传输token，这又是另外一门说法了，本文不做讲述。

 

限流机制

也有些时候，服务器接收到的请求，本来就是真实且合法用户，同时用户也属于正常操作请求，但却出现了同一个接口被频繁请求或者同时多次请求的情况，导致服务器压力过载，进而引起用户响应时间长，严重则服务器挂掉。这种时候，我们就可以考虑采用限流机制，即限制同一时间内请求访问的并发数。

常用的限流机制可分为：

• 令牌桶限流

• 漏桶（或漏斗）限流

• 计数器限流

 

令牌桶限流：

服务器以一定的速率向桶中放入令牌，填满了就丢弃。请求来时先从桶中取出令牌，如果能拿到令牌，则处理请求；否则请求进入等待队列或者拒绝处理。令牌桶允许一定程度的突发流量，只要有令牌就可以处理，支持一次拿多个令牌。

用个通俗易懂的例子在说：

你和你的朋友四个人去海底捞吃火锅，只要足够的位置，你们就可以立即进去就餐。但是由于海底捞比较火爆，很多人都喜欢去，且都喜欢在中午12点或者晚上7点去，这时候海底捞的位置可能很快就满了。恰好你们去得稍微迟了点，没有位置或者不够四个位置了，那么，你们要么选择等待等到有位置位置（进入等待队列），要么走人（拒绝服务）。

 

漏桶限流：

漏桶限流也可以理解为漏斗式限流，即服务器按照指定的容量或者并发数来处理请求，超出容量后的新请求要么等待、要么拒绝。好比于漏斗，流出的那端就这么大，能同时流出多少就是多少，但不会超过流出端的容量大小。

 

计数器限流：

计数器比较简单粗暴，直接限定一个并发数值，只要一定时间内的请请求数超过设定的阈值，则开始限流，要么等待要么拒绝。

 

其实，三种限流方式既有相同之处，也有不同之处，他们之间的异同，留给你仔细品味咯，所谓我思故我在~

 

另外须知：

没有绝对安全的接口，只有更加安全的接口。尽管魔高一尺，道高一丈，但魔也还会继续长高的。

 

*本文到这里就结束啦~希望对你有所帮助，欢迎留言或私信~

个人博客原文链接