## **如何保证接口的安全性：** 【**APP、前后端分离项目都采用API接口形式与服务器进行数据通信，传输的数据被偷窥、被抓包、被伪造时都有发生**】 #### **一般的解决方案如下：** 1、Token授权认证，防止未授权用户获取数据； 2、时间戳超时机制； 3、URL签名，防止请求参数被篡改； 4、防重放，防止接口被第二次请求，防采集； 5、采用HTTPS通信协议，防止数据明文传输； #### **大概解释以上五点**： #### 一：**Token授权认证**： Token的设计方案是用户在**客户端**使用**用户名和密码登录后**，服务器会给客户端返回一个Token，并将Token以键值对的形式存放在缓存（一般是Redis）中，后续**客户端对需要授权模块的所有操作都**要带上这个Token，服务器端接收到**请求后进行Token验证，如果Token存在，说明是授权的请求**。 **Token生成的设计要求：** 1、应用内一定要唯一，否则会出现授权混乱，A用户看到了B用户的数据； 2、每次生成的Token一定要不一样，防止被记录，授权永久有效； 3、一般Token对应的是Redis的key，value存放的是这个用户相关缓存信息，比如：用户的id； 4、要设置Token的过期时间，过期后需要客户端重新登录，获取新的Token，如果Token有效期设置较短，会反复需要用户登录，体验比较差，我们一般采用Token过期后，客户端静默登录的方式。还有一种是单独出一个刷新Token的接口，但是一定要注意刷新机制和安全问题； **生成Token方式**：**Token=md5(用户ID+登录的时间戳+服务器端秘钥)这种方式来获得Token**，因为用户ID是应用内唯一的，登录的时间戳保证每次登录的时候都不一样，服务器端秘钥是配置在服务器端参与加密的字符串（即：盐），目的是提高Token加密的破解难度； #### 二、**时间戳超时机制：** 客户端每次请求接口都带上当前时间的**时间戳timestamp**，服务端接收到timestamp后跟当前时间进行比对，如果时间差大于一定时间（比如：1分钟），则认为该请求失效。 **时间戳超时机制**：是防御DOS攻击的有效手段。 例：http://url/getInfo?id=1&timetamp=1559396263 #### 三、**URL签名：** 写过支付宝或微信支付对接的肯定对URL签名不陌生，我们只需要将原本发送给server端的明文参数做一下签名，然后在server端用相同的算法再做一次签名，对比两次签名就可以确保对应明文的参数有没有被中间人篡改过。 **前提**：我们需要分配给客户端一个私钥用于URL签名加密。 **一般的签名算法如下：** 1、首先对通信的参数按**key进行字母**排序放入数组中； 2、对排序完的**数组键值对用&进行连接**，形成用于加密的参数字符串； 3、在加密的参数字符串前面或者后面加上私钥，然后用md5进行加密，得到sign，然后随着请求接口一起传给服务器。 例如： http://url/getInfo?id=1&timetamp=1559396263&sign=e10adc3949ba59abbe56e057f20f883e 服务器端接收到请求后，用同样的算法获得服务器的sign，对比客户端的sign是否一致，如果一致请求有效； **注意**：对于客户端的私钥一定要妥善处理好，不能被非法者拿到。 #### **四、防重放：** ①：客户端第一次访问时，将签名**sign存放到服务器的Redis中**，超时时间设定为跟时间戳的超时时间一致，二者时间一致可以保证无论在timestamp限定时间内还是外 URL都只能访问一次。 ②：如果发现缓存服务器中已经存在了本次签名，则拒绝服务。 ③：如果在缓存中的签名失效的情况下，有人使用同一个URL再次访问，则会被时间戳超时机制拦截，这就是为什么要求sign的超时时间要设定为跟时间戳的超时时间一致。拒绝重复调用机制确保URL被别人截获了也无法使用（如抓取数据）。 **以上方案流程如下：** 1、客户端通过用户名密码登录服务器并获取Token； 2、客户端生成时间戳timestamp，并将timestamp作为其中一个参数； 3、客户端将所有的参数，包括Token和timestamp按照自己的签名算法进行排序加密得到签名sign 4、将token、timestamp和sign作为请求时必须携带的参数加在每个请求的URL后边 例： http://url/request?token=h40adc3949bafjhbbe56e027f20f583a&timetamp=1559396263&sign=e10adc3949ba59abbe56e057f20f883e 5、服务端对：**token、timestamp和sign进行验证，只有在token有效、timestamp未超时、缓存服务器中不存在sign三种情况同时满足，本次请求才有效**； #### **五、采用HTTPS通信协议：** 1、众所周知HTTP协议是以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了客户端和服务器之间的传输报文，就可以直接读懂其中的信息，因此HTTP协议不适合传输一些敏感信息，比如信用卡号、密码等。 **为了解决HTTP协议的这一缺陷，需要使用另一种协议**：安全套接字层超文本传输协议HTTPS，为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL协议，SSL依靠证书来验证服务器的身份，并为客户端和服务器之间的通信加密。当然HTTPS也不是绝对安全的。 2、 针对安全性要求一般的app，可采用通过校验域名，证书有效性、证书关键信息及证书链的方式； <br> #### 总结：所有的安全措施都用上的话有时候难免太过复杂，在实际项目中需要根据自身情况作出取舍，比如可以只使用签名机制就可以保证信息不会被篡改，或者定向提供服务的时候只用Token机制就可以了，如何取舍，全看项目实际情况和对接口安全性的要求。