十种接口安全方案！！！

其他系列文章导航

Java基础合集
数据结构与算法合集

设计模式合集

多线程合集

分布式合集

ES合集

文章目录

前言

日常开发中，如何保证接口数据的安全性呢？接口数据安全的保证过程，主要体现在这几个方面：一个就是数据传输过程中的安全，还有就是数据到达服务端，如何识别数据，最后一点就是数据存储的安全性。介绍下保证接口数据安全的10个方案。

一、数据加密，防止报文明文传输。

数据在网络传输过程中，很容易被抓包。如果使用的是 http 协议，因为它是明文传输的，用户的数据就很容易被别人获取。所以需要对数据加密。

常见的实现方式，就是对关键字段加密。比如，你一个登录的接口，你可以对密码加密。一般用什么加密算法呢？简单点可以使用对称加密算法（如

AES

）来加解密，或者哈希算法处理（如

MD5

）。

什么是对称加密：加密和解密使用相同密钥的加密算法。

非对称加密：非对称加密算法需要两个密钥（公开密钥和私有密钥）。公钥与私钥是成对存在的，如果用公钥对数据进行加密，只有对应的私钥才能解密。

更安全的做法，就是用非对称加密算法（如

RSA

或者

SM2

），公钥加密，私钥解密。

如果想对所有字段都加密的话，一般都推荐使用https协议。

https

其实就是在

http

和

tcp

之间添加一层加密层SSL。

日常业务呢，数据传输加密这块的话，用https就可以啦，如果安全性要求较高的，比如登陆注册这些，需要传输密码的，密码就可以使用

RSA

等非对称加密算法，对密码加密。如果你的业务，安全性要求很高，你可以模拟https这个流程，对报文，再做一次加解密。

二、数据加签验签

数据报文加签验签，是保证数据传输安全的常用手段，它可以保证数据在传输过程中不被篡改。以前我做的企业转账系统，就用了加签验签。

2.1 什么是加签验签呢？

• 数据加签：用Hash算法（如MD5，或者SHA-256）把原始请求参数生成报文摘要，然后用私钥对这个摘要进行加密，就得到这个报文对应的数字签名sign（这个过程就是加签）。通常来说呢，请求方会把数字签名和报文原文一并发送给接收方。

• 验签：接收方拿到原始报文和数字签名（sign）后，用同一个Hash算法(比如都用MD5)从报文中生成摘要A。另外，用对方提供的公钥对数字签名进行解密，得到摘要B，对比A和B是否相同，就可以得知报文有没有被篡改过。

其实加签，我的理解的话，就是把请求参数，按照一定规则，利用

hash

算法+加密算法生成一个唯一标签

sign

。验签的话，就是把请求参数按照相同的规则处理，再用相同的

hash

算法，和对应的密钥解密处理，以对比这个签名是否一致。

再举个例子，有些人是这么实现的，将所有非空参数（包含一个包

AccessKey

，唯一的开发者标识）按照升序，然后再拼接个

SecretKey

（这个仅作本地加密使用，不参与网络传输，它只是用作签名里面的），得到一个

stringSignTemp

的值，最后用MD5运算，得到

sign

。

服务端收到报文后，会校验，只有拥有合法的身份

AccessKey

和签名

Sign

正确，才放行。这样就解决了身份验证和参数篡改问题，如果请求参数被劫持，由于劫持者获取不到

SecretKey

（仅作本地加密使用，不参与网络传输），他就无法伪造合法的请求啦。

2.2 有了https等加密数据，为什么还需要加签验签

有些人可能有疑问，加签验签主要是防止数据在传输过程中被篡改，那如果都用了

https

下协议加密数据了，为什么还会被篡改呢？为什么还需要加签验签呢？

数据在传输过程中被加密了，理论上，即使被抓包，数据也不会被篡改。但是https不是绝对安全的哦。还有一个点：

https

加密的部分只是在外网，然后有很多服务是内网相互跳转的，加签也可以在这里保证不被中间人篡改，所以一般转账类安全性要求高的接口开发，都需要加签验签。

三、token授权认证机制

日常开发中，我们的网站或者APP，都是需要用户登录的。那么如果是非登录接口，是如何确保安全，如何确认用户身份的呢？可以使用token授权机制。

3.1 token的授权认证方案

token的授权认证方案：用户在客户端输入用户名和密码，点击登录后，服务器会校验密码成功，会给客户端返回一个唯一值

token

，并将

token

以键值对的形式存放在缓存（一般是Redis）中。后续客户端对需要授权模块的所有操作都要带上这个

token

，服务器端接收到请求后，先进行

token

验证，如果

token

存在，才表明是合法请求。

token登录授权流程图如下：

3.2 如何保证token的安全？token被劫持呢？

我们如何保证token的安全呢？

比如说，我如果拿到

token

，是不是就可以调用服务器端的任何接口？可以从这几个方面出发考虑：

• token设置合理的有效期
• 使用https协议
• token可以再次加密
• 如果访问的是敏感信息，单纯加token是不够的，通常会再配置白名单

说到 token，可能会想起 jwt，即（JSON Web Token），其实它也是token的一种。

四、时间戳timestamp超时机制

数据是很容易抓包的，假设我们用了

https

和加签，即使中间人抓到了数据报文，它也看不到真实数据。但是有些不法者，他根本不关心真实的数据，而是直接拿到抓取的数据包，进行恶意请求（比如DOS攻击），以搞垮你的系统。

我们可以引入时间戳超时机制，来保证接口安全。就是：用户每次请求都带上当前时间的时间戳

timestamp

，服务端接收到

timestamp

后，解密，验签通过后，与服务器当前时间进行比对，如果时间差大于一定时间 (比如3分钟)，则认为该请求无效。

五、timestamp+nonce方案防止重放攻击

时间戳超时机制也是有漏洞的，如果是在时间差内，黑客进行的重放攻击，那就不好使了。可以使用

timestamp+nonce

方案。

nonce

指唯一的随机字符串，用来标识每个被签名的请求。我们可以将每次请求的

nonce

参数存储到一个“set集合”中，或者可以json格式存储到数据库或缓存中。每次处理HTTP请求时，首先判断该请求的

nonce

参数是否在该“集合”中，如果存在则认为是非法请求。

然而对服务器来说，永久保存

nonce

的代价是非常大的。可以结合

timestamp

来优化。因为

timstamp

参数对于超过

3min

的请求，都认为非法请求，所以我们只需要存储

3min

的

nonce

参数的“集合”即可。

六、限流机制

如果用户本来就是就是真实用户，他恶意频繁调用接口，想搞垮你的系统呢？这种情况就需要接入限流了。

常用的限流算法有令牌桶和漏桶算法。

可以使用

Guava

的

RateLimiter

单机版限流，也可以使用

Redis

分布式限流，还可以使用阿里开源组件

sentinel

限流。比如说，一分钟可以接受多少次请求。

七、 黑名单机制

如果发现了真实用户恶意请求,你可以搞个黑名单机制，把该用户拉黑。一般情况，会有些竞争对手，或者不坏好意的用户，想搞你的系统的。所以，为了保证安全，一般我们的业务系统，需要有个黑名单机制。对于黑名单发起的请求，直接返回错误码好了。

八、白名单机制

有了黑名单机制，也可以搞个白名单机制啦。以前我做过的api调用平台，如果有外面的api要接入我们的系统时，是需要提前申请网络白名单的。那时候运维会申请个IP网络白名单，只有白名单里面的请求，才可以调用我的api平台。

九、数据脱敏掩码

对于密码，或者手机号、身份证这些敏感信息，一般都需要脱敏掩码再展示的，如果是密码，还需要加密再保存到数据库。

对于手机号、身份证信息这些，日常开发中，在日志排查时，看到的都应该是掩码的。目的就是尽量不泄漏这些用户信息，虽然能看日志的只是开发和运维，但是还是需要防一下，做掩码处理。

对于密码保存到数据库，我们肯定不能直接明文保存。最简单的也需要

MD5

处理一下再保存，

Spring Security

中的

BCryptPasswordEncoder

也可以，它的底层是采用

SHA-256 +随机盐+密钥

对密码进行加密，而

SHA和MD

系列是一样的，都是

hash

摘要类的算法。

十、数据参数一些合法性校验

接口数据的安全性保证，还需要我们的系统，有个数据合法性校验，简单来说就是参数校验，比如身份证长度，手机号长度，是否是数字等等。