preface
大家好呀，我是捡田螺的小男孩。
我们日常开发中，如何保证接口数据的安全性呢？个人觉得，接口数据安全的保证过程，主要体现在这几个方面：一个就是数据传输过程中的安全，还有就是数据到达服务端，如何识别数据，最后一点就是数据存储的安全性。今天跟大家聊聊保证接口数据安全的 10 个方案。
1. Data encryption prevents clear transmission of messages.
We all know that data can easily be caught during network transmission. If the http protocol is used, because it is transmitted in clear text, the user's data can be easily obtained by others. So the data needs to be encrypted.
1.1 How is data encrypted?
常见的实现方式，就是对关键字段加密。比如，你一个登录的接口，你可以对密码加密。一般用什么加密算法呢？简单点可以使用对称加密算法（如AES）来加解密，或者哈希算法处理（如MD5）。
什么是
对称加密：加密和解密使用相同密钥的加密算法。
** Asymmetric encryption **: The asymmetric encryption algorithm requires two keys (public key and private key). ** The public key and private key exist in pairs. If the public key is used to encrypt data, only the corresponding private key can be decrypted.
更安全的做法，就是用非对称加密算法（如RSA或者SM2），公钥加密，私钥解密。
如果你想对所有字段都加密的话，一般都推荐使用https 协议。https其实就是在http和tcp之间添加一层加密层SSL。
1.2 Dear friends, do you still remember the principle of https?
Interviews are also often asked, as follows:
- The client initiates a Https request and connects to port 443 of the server.
- The server must have a set of digital certificates (the certificate content includes public key, certificate authority, expiration date, etc.).
- The server sends its own digital certificate to the client (the public key is in the certificate and the private key is held by the server).
- After the client receives the digital certificate, it will verify the legitimacy of the certificate. If the certificate is verified, a random symmetric key is generated and encrypted with the certificate's public key.
- The client sends the public key encrypted key to the server.
- After the server receives the ciphertext key sent by the client, it uses the private key it previously reserved to asymmetrically decrypt it. After decryption, it obtains the client's key, and then uses the client key to symmetrically encrypt the returned data. The data transmitted by Maozi is all ciphertext.
- The server returns the encrypted ciphertext to the client.
- After receiving it, the client uses its own key to symmetrically decrypt it to get the data returned by the server.
日常业务呢，数据传输加密这块的话，用https就可以啦，如果安全性要求较高的，比如登录注册这些，需要传输密码的，密码就可以使用RSA等非对称加密算法，对密码加密。如果你的业务，安全性要求很高，你可以模拟 https 这个流程，对报文，再做一次加解密。
2. Data signature verification
Signature verification of data messages is a common means to ensure the security of data transmission. It can ensure that data will not be tampered with during the transmission process. The ** corporate transfer system ** that I built in the past used additional signature verification.
2.1 What is signature verification?
- 数据加签：用 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 With encrypted data such as https, why do I need to be signed and verified?
有些小伙伴可能有疑问，加签验签主要是防止数据在传输过程中被篡改，那如果都用了https下协议加密数据了，为什么还会被篡改呢？为什么还需要加签验签呢？
数据在传输过程中被加密了，理论上，即使被抓包，数据也不会被篡改。但是https 不是绝对安全的哦。可以看下这个文章：可怕，原来 HTTPS 也没用。还有一个点：
https加密的部分只是在外网，然后有很多服务是内网相互跳转的，加签也可以在这里保证不被中间人篡改，所以一般转账类安全性要求高的接口开发，都需要加签验签
3. token authorization and certification mechanism
In daily development, our website or APP requires ** user login **. So if it is a ** non-login interface **, how to ensure security and confirm the user's identity? You can use the token authorization mechanism.
3.1 token's authorization and certification scheme
token 的授权认证方案：用户在客户端输入用户名和密码，点击登录后，服务器会校验密码成功，会给客户端返回一个唯一值token，并将token以键值对的形式存放在缓存（一般是 Redis）中。后续客户端对需要授权模块的所有操作都要带上这个token，服务器端接收到请求后，先进行token验证，如果token存在，才表明是合法请求。
** The token login authorization flow chart is as follows: **
- The user enters a user name and password to initiate a login request
- The server verifies the password, and if the verification passes, a globally unique token is generated.
- 将
token存储在redis中，其中key是token，value是userId或者是用户信息，设置一个过期时间。 - 把这个
token返回给客户端 - 用户发起其他业务请求时，需要带上这个
token - 后台服务会统一拦截接口请求，进行
token有效性校验，并从中获取用户信息，供后续业务逻辑使用。如果token不存在，说明请求无效。
3.2 How to ensure the safety of tokens? What about token being kidnapped?
** How can we ensure the safety of tokens? **
比如说，我如果拿到token，是不是就可以调用服务器端的任何接口？可以从这几个方面出发考虑：
- Tokens set a reasonable validity period
- using the HTTPS protocol
- Tokens can be encrypted again
- If you are accessing sensitive information, simply adding a token is not enough, and a whitelist is usually configured.
Speaking of tokens, some friends may think of jwt, which means (JSON Web Token), which is actually a type of token. Interested friends can go and find out.
4. Timestamp timeout mechanism
数据是很容易抓包的，假设我们用了https和加签，即使中间人抓到了数据报文，它也看不到真实数据。但是有些不法者，他根本不关心真实的数据，而是直接拿到抓取的数据包，进行恶意请求（比如DOS 攻击），以搞垮你的系统。
我们可以引入时间戳超时机制，来保证接口安全。就是：用户每次请求都带上当前时间的时间戳timestamp，服务端接收到timestamp后，解密，验签通过后，与服务器当前时间进行比对，如果时间差大于一定时间 (比如 3 分钟)，则认为该请求无效。
5. Timestamp +nonce scheme prevents replay attacks
时间戳超时机制也是有漏洞的，如果是在时间差内，黑客进行的重放攻击，那就不好使了。可以使用timestamp+nonce方案。
nonce指唯一的随机字符串，用来标识每个被签名的请求。我们可以将每次请求的nonce参数存储到一个“set 集合”中，或者可以 json 格式存储到数据库或缓存中。每次处理 HTTP 请求时，首先判断该请求的nonce参数是否在该“集合”中，如果存在则认为是非法请求。
然而对服务器来说，永久保存nonce的代价是非常大的。可以结合timestamp来优化。因为timstamp参数对于超过3min的请求，都认为非法请求，所以我们只需要存储3min的nonce参数的“集合”即可。
6. current-limiting mechanism
What if the user is a real user and he maliciously calls the interface frequently and wants to destroy your system? This situation requires access to current restriction.
常用的限流算法有令牌桶和漏桶算法。大家可以看下我的这篇文章，面试必备：4 种经典限流算法讲解
可以使用Guava的RateLimiter单机版限流，也可以使用Redis分布式限流，还可以使用阿里开源组件sentinel限流。比如说，一分钟可以接受多少次请求。
7. blacklist mechanism
If you find a malicious request from a real user, you can create a blacklist mechanism to blacklist the user. Generally, there will be competitors or well-intentioned users who want to tamper with your system. Therefore, in order to ensure security, generally our business system needs to have a blacklist mechanism. For requests initiated by the blacklist, just return the error code directly.
8. White list mechanism
With a blacklist mechanism, a white list mechanism can also be established. In the corporate transfer system I was responsible for in the past, if an external merchant wanted to access our system, they needed to apply for an online whitelist in advance. At that time, operation and maintenance would apply for an IP network whitelist, and only requests in the whitelist could access our transfer system.
9. data masking
For passwords, or sensitive information such as mobile phone numbers and ID cards, they generally need to be desensitized and masked before being displayed. If it is a password, it also needs to be encrypted and stored in the database.
For mobile phone numbers and ID card information, during daily development, what you see during log checking should be masked. The purpose is to try not to leak this user information as much as possible. Although the only thing you can see is development and operation and maintenance, you still need to take precautions and mask it.
对于密码保存到数据库，我们肯定不能直接明文保存。最简单的也需要MD5处理一下再保存，Spring Security中的 BCryptPasswordEncoder也可以，它的底层是采用SHA-256 +随机盐+密钥对密码进行加密，而SHA和MD系列是一样的，都是hash摘要类的算法。
10. Some validity checks for data parameters.
The security of interface data also requires our system. There is a data validity verification. Simply put, it is ** parameter verification **, such as ID card length, mobile phone number length, whether it is a number, etc.
summary
This article introduces 10 solutions to ensure interface data security. Friends, if you have other plans, you can comment in the message area and exchange and learn together.