陈子文
2021-04-06 05:38:55
E-mail :
API接口安全设计篇
1
8
最近在写个返利小程序，前端用uniapp，因为从测试的时候全是用emlog写的。所以整个前后端通信全部以EMLOG为核心写的通信API接口，因为不是API框架，所以会有很多安全方面的考虑，因为所有的前后端通信全靠api接口实现，有可能出现各种API恶意调用或者抓包劫持，所以api接口的安全不容忽视，特别是涉及到会员操作的相关接口，一个不注意就会造成很严重的后果。
实际开发中api安全设计主要考虑一下几点：
（一）Token授权机制：用户登录后由服务端生成Token给客户端，后续客户端的所有请求都必须带上Token，服务端进行Token检验，如果检验不通过则认为请求无效。Token是客户端访问服务端的凭证
（二）时间戳超时机制：为了防止接口被恶意调用，如果没有时间戳机制接口会可能会被刷爆。所以在客户端每次请求服务端的时候都带上请求时的时间戳timestamp，服务端拿到该时间戳再对比当前时间，如果时差大于一定时间如设置为30秒，如果时间超过30秒则认定请求失效。
（三）签名机制：有时候接口可能会被恶意劫持，假设用户进行提现操作，客户端发起提现请求，如果服务端没有相关判断，该请求如果被劫持后将用户UID改成自己的UID将会变成自己的提现请求。所以签名机制必不可少，签名机制可有效防范请求参数被篡改。
具体操作将请求的参数以及上面的Token和timestamp依次排序(可适当加上前后端约定好的密文)，将所有参数按照前后端约定好的顺序排序后进行MD5加密，此时加密后的数据就是本次请求的签名Sign，服务端收到该请求后再把所有的请求参数按照事先约定好的方式再进行MD5加密，加密后的密文与请求的签名Sign比对，如果比对成功则认定请求合法，否则表明请求已被篡改，直接返回错误标识。签名机制是防范传输数据不被篡改的有效手段
（四）禁止请求被重放(二次请求)：假设用户在提现时发送提现请求，已经提现成功。现在有人非法获取该请求路径重新请求则会造成重复提现，所以某些情况下需要禁止二次请求，这里我们用到redis缓存服务器实现该流程。具体操作如下：
在上面的签名机制上，客户端发送提现请求到服务端时加上一个唯一的请求标识UniqueUID，通常可以直接将用户UID和设备UID加上时间戳一起发送，以保证该参数不会重复。服务端收到该请求后根据情况将UniqueUID存入redis缓存，在存入redis之前先进行判断，如果redis缓存中UniqueUID存在，则说明该请求是二次请求，直接返回错误提示。如果UniqueUID不存在，则说明该请求为第一次请求，可直接进行下一步操作，操作完之后将UniqueUID存入redis缓存，这样二次请求的时候就会遇到上面的redis缓存中UniqueUID存在，直接返回错误提示。
整个流程如下：
1、客户端通过用户名密码登录服务器并获取Token
2、客户端生成时间戳timestamp，并将timestamp作为其中一个参数
3、客户端将所有的参数，包括Token和timestamp按照自己的算法进行排序加密得到签名sign
4、将token、timestamp和sign作为请求时必须携带的参数加在每个请求的URL后边（http://url/request?token=123×tamp=123&sign=123123123）
5、服务端写一个过滤器对Token、timestamp和Sign进行验证，只有在token有效、timestamp未超时、缓存服务器中不存在UniqueUID三种情况同时满足，本次请求才有效
上一篇:讯睿CMS框架学习笔记
回复 ( 1 )
