如何保证数据传输安全
如何保证数据传输安全？可以采用：1、数据加密；2、数据签名；3、session/token机制；4、Https；5、时间戳超时机制；6、timestamp+nonce；7、限流；8、黑名单；9、白名单；10、数据脱敏掩码；11、参数校验。
1、数据加密
数据加密一直是保密数据的重要部分，常见的加密算法有可逆加密算法和不可逆加密算法，可逆加密算法又分为对称加密算法和非对称加密算法。
比如一个系统的登陆操作，客户输入用户名登陆，如果不进行任何保障措施，用户名和密码明文传输，被不法分子截获数据后，显然是不安全的。如果我们这时对密码进行不可逆加密，如md5，对用户名进行可逆加密，如des这时候在截获数据时，得到的将是一串密文，显然，即使要破解，也需要相当时间。但这样，有一个明显问题，就是接口吞吐量下降，明显，加密情况下，由于需要解密数据，接口的响应速度会下降。
可能，对于一些非重要数据，我们这样牺牲系统性能换取来的安全可能有些过了。
2、数据签名
数据签名，相当于对传输的数据，进行一些不可逆加密算法后，如md5，生成一段签名字符串sign。
比如上述列子中，登陆操作中如果还要传输IP，地点等等数据，这些数据明显没那么重要，这时可以对全部传输数据进行签名，生成sign，将其传入后端，后端用同样算法及密钥计算比较sign，如果一致认为数据正确，直接拿到IP，地点等数据(不用解密，相对于解密各个信息，理论上所有信息计算签名要节省时间)，不一致则认为被修改过，返回错误信息。
3、session/token机制
session(cookie)和token机制的出现是为了校验用户状态的。
比如不法分子知道了我们的后台接口，恶意伪造大量数据攻击，即使这些数据不正确，而服务器每次都需要校验这些数据的正确性，显然带来大量性能消耗。我们当然可以进行一些优化操作，如对于同一个IP，短时间大量请求则封掉该IP一段时间，但这不是太合理的。
设想如用户登陆后，保存状态，只有登陆的用户可以访问这些接口，每次请求到来，均先校验用户登陆状态，对于session，如果没有sessionid或者sessionid错误或者过期则直接返回登陆界面。对干token，与session同理，没有token或者token错误或者过期的直接返回登陆页面。这样，我们开始校验token或者session，就可以拒绝大量伪造请求。
4、Https
上面，无论数据加密还是签名，我们发现最重要的就是加密方法和加密密钥。
对于两台服务器交互，可能不用太担心，但是如果是webapp或者原生app，不法分子反编译前端代码后，就有可能拿到加密方法和加密key，怎么办呢?在加密算法中，有一种叫做非对称加密的算法，有公钥和私钥组成，他有个特点:公钥加密的数据，只有私钥能解密:私钥加密的数据，只有公钥能解密。 https(数字证书机制)就是需要让客户端与服务器端安全地协商出一个对称加密算法。剩下的就是通信时双方使用这个对称加密算法进行加密解密。具体步骤如下：
- 客户端启动，发送请求到服务端，服务端通过非对称加密算法(如RSA)生成公钥pubkey1和私钥prikey1。
- 服务端将公钥pubkey1发给客户端，客户端用自己的非对称加密算法也生成一套公钥pubkey2和私钥prikey2，并将公钥pubkey2通过pubkey1加密后返回服务端。
- 服务端用私钥prikev1解密后拿到pubkey2，并将确定好的未来交互的对称加密算法和密钥通过pubkey2加密，返回客户端。
- 客户端用私钥pubkey2解密数据，拿到服务器给定的加密算法和密钥，双方开始用其数据通信。
这样仍有一个问题，如何证明公钥pubkey1加密的这串数字是客户端来的，即证明他就是他。这就是https的数字证书，相当于网络中心的部分，证明他就是他。数字证书就是来干这个的。
5、时间戳超时机制
数据是很容易抓包的，假设我们用了https和加签，即使中间人抓到了数据报文，它也看不到真实数据。但是有些不法者，他根本不关心真实的数据，而是直接拿到抓取的数据包，进行恶意请求（比如DOS攻击），以搞垮你的系统。
我们可以引入时间戳超时机制，来保证接口安全。就是：用户每次请求都带上当前时间的时间戳timestamp，服务端接收到timestamp后，解密，验签通过后，与服务器当前时间进行比对，如果时间差大于一定时间 (比如3分钟)，则认为该请求无效。
6、timestamp+nonce方案
时间戳超时机制也是有漏洞的，如果是在时间差内，黑客进行的重放攻击，那就不好使了。可以使用timestamp+nonce方案防止重放攻击。
nonce指少数的随机字符串，用来标识每个被签名的请求。我们可以将每次请求的nonce参数存储到一个“set集合”中，或者可以json格式存储到数据库或缓存中。每次处理HTTP请求时，首先判断该请求的nonce参数是否在该“集合”中，如果存在则认为是非法请求。
然而对服务器来说，永久保存nonce的代价是非常大的。可以结合timestamp来优化。因为timstamp参数对于超过3min的请求，都认为非法请求，所以我们只需要存储3min的nonce参数的“集合”即可。
7、限流
如果用户本来就是就是真实用户，他恶意频繁调用接口，想搞垮你的系统呢？这种情况就需要接入限流了。
常用的限流算法有令牌桶和漏桶算法。大家可以看下我的这篇文章，面试必备：4种经典限流算法讲解
可以使用Guava的RateLimiter单机版限流，也可以使用Redis分布式限流，还可以使用阿里开源组件sentinel限流。比如说，一分钟可以接受多少次请求。
8、黑名单
如果发现了真实用户恶意请求,你可以搞个黑名单机制，把该用户拉黑。一般情况，会有些竞争对手，或者不坏好意的用户，想搞你的系统的。所以，为了保证安全，一般我们的业务系统，需要有个黑名单机制。对于黑名单发起的请求，直接返回错误码好了。
9、白名单
有了黑名单机制，也可以搞个白名单机制啦。以前我负责的企业转账系统，如果有外面的商户要接入我们的系统时，是需要提前申请网络白名单的。那时候运维会申请个IP网络白名单，只有白名单里面的请求，才可以访问我们的转账系统。
10、数据脱敏掩码
对于密码，或者手机号、身份证这些敏感信息，一般都需要脱敏掩码再展示的，如果是密码，还需要加密再保存到数据库。
对于手机号、身份证信息这些，日常开发中，在日志排查时，看到的都应该是掩码的。目的就是尽量不泄漏这些用户信息，虽然能看日志的只是开发和运维，但是还是需要防一下，做掩码处理。
对于密码保存到数据库，我们肯定不能直接明文保存。最简单的也需要MD5处理一下再保存，Spring Security中的 BCryptPasswordEncoder也可以，它的底层是采用SHA-256 +随机盐+密钥对密码进行加密，而SHA和MD系列是一样的，都是hash摘要类的算法。
11、参数校验
接口数据的安全性保证，还需要我们的系统，有个数据合法性校验，简单来说就是参数校验，比如身份证长度，手机号长度，是否是数字等等。
