怎么保证接口数据的传输安全？

目录

一、前言

二、解决方法

1、对请求做身份认证（数据签名）

2、对敏感数据进行加密（数据加密）

3、session、token机制

4、HTTPS（数字证书机制）

5、其它

---

一、前言

当我们的系统越做越大时，代码的的松耦合以及性能问题很重要，但我觉得，数据的传输感觉更重要。安全问题是系统的心脏！！！值得我们去重视以及防患于未然。

现代软件开发中，前后端分离的项目逐渐成为主流。前后端分离的项目离不开后端对外提供接口，而请求这些接口的数据时，安全性应当保证。

二、解决方法

1、对请求做身份认证（数据签名）

如果不对请求进行签名认证，那么可以简单的通过fiddler等工具轻易抓包拿到数据，并进行篡改，提交，大规模批量调用，则会使系统产生大量垃圾数据，系统资源被大量消耗，甚至无法正常使用（另说，当然可以通过GateWay进行限流），因而我们需要对请求进行签名认证。

比如 http://www.xxx.com/getInfo?id=1，获取id为1的信息，如果不签名那么通过id=2,就可以获取2的内容等等。怎样签名呢？通常使用sign，比如原链接请求的时候加一个sign参数，sign=md5(id=1)，服务器接受到请求，验证sign是否等于md5(id=1)，如果等于说明正常请求。这会有个弊端，假如规则被发现，那么就会被伪造，所以适当复杂一些，还是能够提高安全性的。

如何防止数据篡改？

这里通过签名参数中包含原有请求的所有参数，改动任意参数，sign值都会不同，因此无法篡改。

如何防止重放攻击？

由于签名算法中还有imei(设备唯一Id)、timestamp参数，且签名算法为不可逆算法（如md5或sha1），因而对于正常的每个请求sign值不会重复。此时服务端可以存储5分钟的sign值，来做重放攻击时的验证过滤，超过5分钟的请求则直接被timestamp校验过滤。

2、对敏感数据进行加密（数据加密）

数据加密一直是保密数据的重要部分，常见的加密算法有可逆加密算法和不可逆加密算法，可逆加密算法又分为对称加密算法和非对称加密算法。

比如用户名密码，我们需要加密，这样即使被抓包监听，他们也不知道原始数据是什么（如果简单的md5，是可以暴力破解），所以加密方法越复杂越安全，根据需要，常见的是 md5(不可逆)，aes（可逆），自由组合吧,你还可以自己定义一些特殊字符啊，没有做不到只有想不到， 举例：username = aes(username), pwd = MD5(pwd + username)。

这时候在截获数据时，得到的将是一串密文，显然，即使要破解，也需要相当时间。
但这样，有一个明显问题，就是接口吞吐量下降，明显，加密情况下，由于需要解密数据，接口的响应速度会下降。
对于一些重要数据，我们这样牺牲系统性能换取来的安全是可以接受的。

3、session、token机制

session（cookie）和 token 机制的出现是为了校验用户状态的。

比如不法分子知道了我们的后台接口，恶意伪造大量数据攻击，即使这些数据不正确，而服务器每次都需要校验这些数据的正确性，显然带来大量性能消耗。

我们当然可以进行一些优化操作，如对于同一个IP，短时间大量请求则封掉该IP一段时间，但这不是太合理的。

设想，如果用户登陆后，保存状态，只有登陆的用户可以访问这些接口，每次请求到来，均先校验用户登陆状态，对于session，如果没有sessionid或者sessionid错误或者过期则直接返回登陆界面。对于token，与session同理，没有token或者token错误或者过期的直接返回登陆页面。

这样，我们开始校验token或者session，就可以拒绝大量伪造请求。

4、HTTPS（数字证书机制）

上面，无论数据加密还是签名，我们发现最重要的就是加密方法和加密密钥。

对于两台服务器交互，可能不用太担心，但是如果是webapp或者原生app，不法分子反编译前端代码后，就有可能拿到加密方法和加密key，怎么办呢？

这就属于HTTPS要解决的事情：

在加密算法中，有一种叫做非对称加密的算法，有公钥和私钥组成，他有个特点：公钥加密的数据，只有私钥能解密；私钥加密的数据，只有公钥能解密。

HTTPS 就是需要让客户端与服务器端安全地协商出一个对称加密算法。剩下的就是通信时双方使用这个对称加密算法进行加密解密。

①客户端启动，发送请求到服务端，服务端通过非对称加密算法（如RSA）生成公钥pubkey1和私钥prikey1。

②服务端将公钥pubkey1发给客户端，客户端用自己的非对称加密算法也生成一套公钥pubkey2和私钥prikey2，并将公钥pubkey2通过pubkey1加密后返回服务端。

③服务端用私钥prikey1解密后拿到pubkey2，并将确定好的未来交互的对称加密算法和密钥通过pubkey2加密，返回客户端。

④客户端用私钥pubkey2解密数据，拿到服务器给定的加密算法和密钥，双方开始用其数据通信。

这样仍有一个问题，如何证明公钥pubkey1加密的这串数字是客户端来的，即证明他就是他。。。

这就是HTTPS的数字证书，相当于网络中心的部分，证明他就是他。数字证书就是来干这个的。

5、其它

如对于两台稳定的服务器交互，直接进行IP校验或许比token，session机制更好更方便。及一些其他的操作，如同一IP短时间大量错误报文，可以将其暂时拉入黑名单。等等。