安全|API接口安全性设计(防篡改和重复调用)

作者: admin 分类: PHP 发布时间: 2020-03-27 11:14

API接口的安全性主要是为了保证数据不会被篡改和重复调用,实现方案主要围绕Token、时间戳和Sign三个机制展开设计。

1. Token授权机制
用户使用用户名密码登录后服务器给客户端返回一个Token(必须要保证唯一,可以结合UUID和本地设备标示),并将Token-UserId以键值对的形式存放在缓存服务器中(我们是使用Redis),并要设置失效时间。服务端接收到请求后进行Token验证,如果Token不存在,说明请求无效。Token是客户端访问服务端的凭证。

# uuid 是手机设备的唯一标示
String token = UUID.randomUUID().toString() + "_" + uuid;

2. 时间戳超时机制
用户每次请求都带上当前时间的时间戳timestamp,服务端接收到timestamp后跟当前时间进行比对,如果时间差大于一定时间(比如30秒),则认为该请求失效。时间戳超时机制是防御重复调用和爬取数据的有效手段。
当然这里需要注意的地方是保证客户端和服务端的“当前时间”是一致的,我们采取的对齐方式是客户端第一次连接服务端时请求一个接口获取服务端的当前时间A1,再和客户端的当前时间B1做一个差异化计算(A1-B1=AB),得出差异值AB,客户端再后面的请求中都是传B1+AB给到服务端。

// timeStamp是客户端从Header传过来的值
Long timeStamp = RequestHeaderContext.getInstance().getTimeStamp();
boolean checkTime = checkTime(timeStamp, 30 * 1000);
if (!checkTime) {
    return responseErrorAPISecurity(response);
}
 
// checkTime方法
public static boolean checkTime(Long time, Integer variable){
    Long currentTimeMillis = System.currentTimeMillis();
    Long addTime = currentTimeMillis + variable;
    Long subTime = currentTimeMillis - variable;
    if (addTime > time && time > subTime){
        return true;
    }
    return false;
}

3. API签名机制
将“请求的API参数”+“时间戳”+“盐”进行MD5算法加密,加密后的数据就是本次请求的签名signature,服务端接收到请求后以同样的算法得到签名,并跟当前的签名进行比对,如果不一样,说明参数被更改过,直接返回错误标识。签名机制保证了数据不会被篡改。

// 请求的API参数,如果是再body,则MD5;如果是param,则原字符串
StringBuffer urlSign = new StringBuffer();
 
if ("POST".equals(request.getMethod()) || "PUT".equals(request.getMethod())) {
    String bodyStr = RequestReaderUtil.ReadAsChars(request);
    String bodySign = "";
    if (!StringUtils.isEmpty(bodyStr)){
        bodySign = DigestUtils.md5DigestAsHex((bodyStr).getBytes());
    }
    urlSign = new StringBuffer(bodySign);
} else if ("GET".equals(request.getMethod()) || "DELETE".equals(request.getMethod())) {
    String params = request.getQueryString();
    if (params == null){
        params = "";
    }
    urlSign = new StringBuffer(params);
}
// “请求的API参数”+“时间戳”+“盐”进行MD5算法加密
String sign = DigestUtils.md5DigestAsHex(urlSign.append(timeStamp).append(salt).toString().getBytes());
 
// signature是客户端从Header传过来的值
if (signature.equals(sign)) {
    return true;
} else {
    return false;
}

4. 注意事项
1
、因为用户登录的Token是和设备唯一标示绑定的,所以一个用户有可能会有多个有效的Token,那么当用户在修改登录密码时需要把所有的Token删除,我的做法是在Redis保存了一个value是List(值是该用户所有的有效的Token)的Key,当修改密码时会把该Key下的所有Token干掉。
2、客户端每次请求,在Header里面有timeStamp的值,签名中也是用这个timeStamp组合签名的,要确保这两个值是一致的。因为我们在实际开发中,发现客户端的同事在加密时通过函数获取了当前时间A,在请求时也通过函数获取了当前时间B,有时候这两个当前时间会差几毫秒,导致签名校验失败。

/**
  * 登录后由服务端生成并返回
  */
private String token;
 
/**
  * 安全校验字段(接口参数+时间戳+加盐:取MD5生成)
  */
private String signature;
 
 /**
  * 设备唯一标识
  */
private String udid;
 
/**
  * 时间戳,13位,比如:1532942172000
  */
private Long timeStamp;

5. 安全保障总结
在以上机制下,
如果有人劫持了请求,并对请求中的参数进行了修改,签名就无法通过;
如果有人使用已经劫持的URL进行DOS攻击和爬取数据,那么他也只能最多使用30s;
如果签名算法都泄露了怎么办?可能性很小,因为这里的“盐”值只有我们的CTO知道。

作者:小怪聊职场
链接:https://www.jianshu.com/p/10fedb2e8f3f
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

API接口的防重放

我们在设计API接口时,最怕的莫过于同一个接口给用户截获重放提交,那什么是重放提交:对同一个请求发送多次到后台,对系统产生异常影响。

应对的策略有:

1使用时间戳timestamp。

2使用nonce,什么是nonce呢? nonce = MD5(timestampe+rand(0,1000))

3使用timestamp+nonce

通常是使用第三种的方法去处理。

服务端

1第一次接受请求,对请求的timestamp进行规定时间如60s检验,如果符合那就进行下一步操作。

2对nonce的处理,针对nonce访问redis判断是否存在,如果不存在,表示第一次访问,并在redis中插入nonce和设置过期时间如60;如果存在表示重复提交。

也需要考虑请求参数被篡改,使用sign签名对上面的参数进行一个校验。

————————————————

版权声明:本文为CSDN博主「JINGBIN_CHEN」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。

原文链接:https://blog.csdn.net/qq_30553773/article/details/82954901

API接口之安全篇

APP、前后端分离项目都采用API接口形式与服务器进行数据通信,传输的数据被偷窥、被抓包、被伪造时有发生,那么如何设计一套比较安全的API接口方案呢?

一般的解决方案如下:

1、Token授权认证,防止未授权用户获取数据;

2、时间戳超时机制;

3、URL签名,防止请求参数被篡改;

4、防重放,防止接口被第二次请求,防采集;

5、采用HTTPS通信协议,防止数据明文传输;

一、Token授权认证

HTTP协议是无状态的,一次请求结束,连接断开,下次服务器再收到请求,它就不知道这个请求是哪个用户发过来的,但是对我们有权限访问限制的模块而言,它是需要有状态管理的,以便服务端能够准确的知道HTTP请求是哪个用户发起的,从而判断他是否有权限继续这个请求。

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的接口,但是一定要注意刷新机制和安全问题;

根据上面的设计方案要求,我们很容易得到Token=md5(用户ID+登录的时间戳+服务器端秘钥)这种方式来获得Token,因为用户ID是应用内唯一的,登录的时间戳保证每次登录的时候都不一样,服务器端秘钥是配置在服务器端参与加密的字符串(即:盐),目的是提高Token加密的破解难度,注意一定不要泄漏;

二、时间戳超时机制

客户端每次请求接口都带上当前时间的时间戳timestamp,服务端接收到timestamp后跟当前时间进行比对,如果时间差大于一定时间(比如:1分钟),则认为该请求失效。时间戳超时机制是防御DOS攻击的有效手段。

例:http://url/getInfo?id=1&timetamp=1559396263

三、URL签名

写过支付宝或微信支付对接的同学肯定对URL签名不陌生,我们只需要将原本发送给server端的明文参数做一下签名,然后在server端用相同的算法再做一次签名,对比两次签名就可以确保对应明文的参数有没有被中间人篡改过。

首先我们需要分配给客户端一个私钥用于URL签名加密,一般的签名算法如下:

1、首先对通信的参数按key进行字母排序放入数组中(一般请求的接口地址也要参与排序和签名,那么需要额外添加url=http://url/getInfo这个参数);

2、对排序完的数组键值对用&进行连接,形成用于加密的参数字符串;

3、在加密的参数字符串前面或者后面加上私钥,然后用md5进行加密,得到sign,然后随着请求接口一起传给服务器。

例如:

http://url/getInfo?id=1&timetamp=1559396263&sign=e10adc3949ba59abbe56e057f20f883e

服务器端接收到请求后,用同样的算法获得服务器的sign,对比客户端的sign是否一致,如果一致请求有效;

注意:对于客户端的私钥一定要妥善处理好,不能被非法者拿到,如果针对于H5的项目,H5保存私钥是个问题,目前没有更好的方法,也是一致困扰我的问题,如果大家有更好的方法可以留言一起探讨。

四、防重放

客户端第一次访问时,将签名sign存放到服务器的Redis中,超时时间设定为跟时间戳的超时时间一致,二者时间一致可以保证无论在timestamp限定时间内还是外 URL都只能访问一次,如果被非法者截获,使用同一个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通信协议

众所周知HTTP协议是以明文方式发送内容,不提供任何方式的数据加密,如果攻击者截取了客户端和服务器之间的传输报文,就可以直接读懂其中的信息,因此HTTP协议不适合传输一些敏感信息,比如信用卡号、密码等。

为了解决HTTP协议的这一缺陷,需要使用另一种协议:安全套接字层超文本传输协议HTTPS,为了数据传输的安全,HTTPS在HTTP的基础上加入了SSL协议,SSL依靠证书来验证服务器的身份,并为客户端和服务器之间的通信加密。

HTTPS也不是绝对安全的,如下图所示为中间人劫持攻击,中间人可以获取到客户端与服务器之间所有的通信内容。

640.jpg

中间人截取客户端发送给服务器的请求,然后伪装成客户端与服务器进行通信;将服务器返回给客户端的内容发送给客户端,伪装成服务器与客户端进行通信。 
通过这样的手段,便可以获取客户端和服务器之间通信的所有内容。 
使用中间人攻击手段,必须要让客户端信任中间人的证书,如果客户端不信任,则这种攻击手段也无法发挥作用。

 

 

2 针对安全性要求一般的app,可采用通过校验域名,证书有效性、证书关键信息及证书链的方式;

总结:所有的安全措施都用上的话有时候难免太过复杂,在实际项目中需要根据自身情况作出取舍,比如可以只使用签名机制就可以保证信息不会被篡改,或者定向提供服务的时候只用Token机制就可以了,如何取舍,全看项目实际情况和对接口安全性的要求。

来源:https://www.cnblogs.com/xingxia/p/API_secrute.html

如果觉得我的文章对您有用,请随意赞赏。您的支持将鼓励我继续创作!

发表评论

标签云