前言大家好，我是捡蜗牛的小男孩。在我们日常的开发中，如何保证接口数据的安全呢？个人认为接口数据安全的保障过程主要体现在这几个方面：一是数据传输过程中的安全，二是数据到达服务器时如何识别数据，最后一点是安全的数据存储。今天和大家聊聊保障接口数据安全的10个解决方案。1.数据加密，防止消息以明文形式传输。我们都知道，数据在网络传输过程中很容易被抓取。如果使用http协议，由于是明文传输，用户的数据很容易被他人获取。所以数据需要加密。1.1如何加密数据？一个常见的实现是加密关键字段。比如你有一个登录界面，你可以对密码进行加密。一般使用什么加密算法？简单点可以使用对称加密算法（如AES）加解密，或者哈希算法处理（如MD5）。什么是对称加密：加密和解密使用相同密钥的加密算法。非对称加密：非对称加密算法需要两个密钥（公钥和私钥）。公钥和私钥成对存在。如果数据是用公钥加密的，只有对应的私钥才能解密。更安全的方法是使用非对称加密算法（如RSA或SM2），用公钥加密，用私钥解密。如果要对所有字段进行加密，一般推荐使用https协议。https其实就是在http和tcp之间加了一层加密层SSL。1.2小伙伴们还记得https的原理吗？面试经常被问到，如下：客户端发起Https请求，连接到服务器的443端口。服务器必须有一套数字证书（证书的内容包括公钥、证书颁发机构、有效期等）。服务器向客户端发送自己的数字证书（公钥在证书中，私钥由服务器持有）。客户端收到数字证书后，会验证证书的有效性。如果证书通过验证，将生成随机对称密钥并使用证书的公钥加密。客户端将用公钥加密的密钥发送给服务器。服务器收到客户端发送的密文密钥后，使用自己之前预留的私钥进行非对称解密。解密后得到客户端的密钥，然后用客户端密钥对返回的数据进行对称加密。姜子传输的数据都是密文。服务器将加密后的密文返回给客户端。客户端收到后，用自己的密钥对称解密，得到服务端返回的数据。对于日常业务，如果要对数据传输进行加密，可以使用https。如果你有更高的安全要求，比如登录、注册等，如果需要传输密码，可以使用RSA等非对称加密算法对密码进行加密。如果您的业务对安全性要求高，可以模拟https的过程，对报文重新加解密。2.数据签名验证数据包签名验证是保证数据传输安全的常用方法。可以保证数据在传输过程中不被篡改。在我之前搭建的企业转账系统中，我使用了签名验证。2.1什么是签名验证？数据签名：使用Hash算法（如MD5，或SHA-256）将原始请求参数生成消息摘要，然后用私钥加密摘要，得到消息对应的数字签名sign（此过程是加号）。一般来说，请求者会将数字签名和消息的原始文本发送给接收者。签名验证：接收方收到原始消息和数字签名（sign）后，使用相同的Hash算法（比如都使用MD5）从消息中生成摘要A。另外，用对方提供的公钥解密数字签名得到摘要B，比较A和B是否相同，就可以知道消息是否被篡改。其实签名，按照我的理解，就是使用哈希算法+加密算法，按照一定的规则生成一个唯一的标签签名。对于签名验证，请求参数按照相同的规则进行处理，然后使用相同的哈希算法解密对应的密钥，比较签名是否一致。再举个例子，有小伙伴是这样实现的，将所有非空参数（包括一个packageAccessKey，唯一开发者ID）按升序排列，然后串接一个SecretKey（这个只用于本地加密，不不参与网络传输，只用在签名中），得到一个stringSignTemp值，最后用MD5计算得到sign。服务器收到消息后，会进行验证，只有拥有合法身份AccessKey且签名Sign正确，才会放行。这样就解决了身份验证和参数篡改的问题。如果请求参数被劫持，由于劫持者无法获得SecretKey（仅用于本地加密，不参与网络传输），因此无法伪造合法请求。2.2用https等方式加密的数据，为什么还要加签名和验证？？为什么还需要签名？数据在传输过程中被加密。理论上，即使抓包，数据也不会被篡改。但是https也不是绝对安全的。可以看看这篇文章：惨了，原来HTTPS没用了。还有一点：https的加密部分只是在外网，在内网有很多互相跳转的服务。在这里也可以进行签名，保证不会被中间人篡改。所以一般转账对安全性要求高的接口的开发需要Signatureverification3.在日常开发token授权认证机制的时候，我们的网站或者APP是需要用户登录的。所以如果是非登录接口，如何保证安全，如何确认用户身份？可以使用令牌授权机制。3.1token授权认证方案token授权认证方案：用户在客户端输入用户名和密码，点击登录，服务器验证密码是否成功，会返回一个唯一值token给客户端，token将以键值对的形式存储在缓存中（通常是Redis）。后续客户端必须为所有需要授权模块的操作携带此令牌。服务器收到请求后，首先进行token验证。如果token存在，说明这是一个合法的请求。token登录授权流程图如下：用户输入用户名和密码，发起登录请求，服务器验证密码，验证通过则生成一个全局唯一的token。在redis中存储token，key为token，value为userId或用户信息，并设置过期时间。当token返回给客户端发起其他业务请求时，后台服务会统一拦截接口请求，验证token的合法性，并从中获取用户信息，用于后续的业务逻辑。如果令牌不存在，则请求无效。3.2如何保证token的安全？令牌被劫持怎么办？我们如何确保令牌安全？比如我拿到了token，是不是可以调用server端的任意接口？可以从这几个方面考虑：给token设置一个合理的有效期使用https协议token可以重新加密如果访问的是敏感信息，简单的加token是不行的，一般会重新配置白名单说到tokens，有的朋友可能会想到jwt，即（JSONWebToken），其实就是一种token。感兴趣的朋友可以去了解一下。4.Timestamp时间戳超时机制数据很容易抓包，假设我们使用https和签名，即使中间人抓到了数据包，也看不到真正的数据。但有些不法分子根本不关心真实的数据，而是直接获取抓取到的数据包，进行恶意请求（如DOS攻击）来搞垮你的系统。我们可以引入时间戳超时机制来保证接口安全。即：用户的每次请求都带上当前时间的时间戳。服务器收到时间戳后，对其进行解密。验证通过后，与服务器当前时间进行比较。如果时间差大于某个时间（比如3分钟），则认为该请求无效。5、timestamp+nonce方案防止重放攻击。时间戳超时机制也存在漏洞。如果黑客在这个时间差内进行重放攻击，是行不通的。可以使用时间戳+随机数方案。nonce是指用于标识每个已签名请求的唯一随机字符串。我们可以将每个请求的nonce参数存储在一个“setcollection”中，或者以json格式存储在数据库或缓存中。每次处理HTTP请求时，首先判断请求的nonce参数是否在“集合”中，如果存在则认为是非法请求。但是对于服务器来说，永久保存nonce的代价是非常高的。可以结合时间戳进行优化。因为超过3分钟的请求，timstamp参数被认为是非法请求，所以我们只需要存储3分钟的nonce参数的“集合”。6、限流机制如果用户是真实用户，恶意频繁调用接口，想要破坏你的系统？在这种情况下，需要访问限流。可以使用Guava的RateLimiter单机版进行限流，也可以使用Redis分布式限流，也可以使用阿里的开源组件Sentinel进行限流。比如一分钟可以接受多少个请求。7.黑名单机制如果发现真实用户的恶意请求，可以设置黑名单机制来屏蔽该用户。一般来说，会有一些竞争对手，或者是好心的用户，想要搞乱你的系统。所以，为了保证安全，一般我们的业务系统都需要有黑名单机制。对于黑名单发起的请求，直接返回错误码。8.白名单机制有了黑名单机制，还可以设置白名单机制。在我之前负责的企业转账系统中，如果有外部商户要接入我们的系统，需要提前申请网络白名单。届时运维会申请IP网络白名单，只有白名单中的请求才能访问我们的中转系统。9、数据脱敏掩码对于密码、手机号、身份证等敏感信息，一般需要脱敏掩码后才能显示。如果是密码，需要加密后保存到数据库中。对于手机号和身份证信息，在日常开发中，查看日志时，看到的都应该屏蔽掉。目的是尽量不泄露这些用户信息。虽然只有开发和运维才能看到日志，但还是要做好防护和屏蔽。对于保存到数据库的密码，我们一定不能直接明文保存。最简单的也是需要MD5处理后保存。也可以使用SpringSecurity中的BCryptPasswordEncoder。它的底层采用SHA-256+随机盐+密钥对密码进行加密，SHA和MD系列是一样的，都是针对Digest类的hash算法。10、检查部分数据参数的有效性。接口数据的安全保障也需要我们的系统有一个数据的合法性校验，简单的说就是参数校验，比如身份证的长度，手机号码的长度，是否是号码等等在。小结本文介绍10种保障接口数据安全的解决方案。
