API重放***的防御策略分析

1       前言

1.1    背景

前端为手机APP应用，采用HTTPS+RESTful协议通过互联网与后端API服务器集群进行通信，接口认证基于OAuth2协议。

简单的架构图如下所示：

1.2    痛点

虽然API接口传输采用了HTTPS进行加密传输，但是一部分接口仍旧存在重放***（Replay Attack）的风险，下文分析了多种不同的防御重放***的方案。

2       基于APP端维护的Key进行认证

2.1    采用随机数进行签名认证

APP维护一个OAuth2 Server的用户名/密码，APP每次在进行注册/登录接口请求之前，先从API Server获取一个请求ID和一个随机数。然后APP使用这个随机数作为密钥，对APP的OAuth2用户名/密码进行HmacSHA256哈希计算，并用base64编码生成数字签名，然后再将用户注册/登录参数以及请求ID、数字签名一并传递到API Server，API Server根据这些信息来判断请求是否合法。

优点：没有使用时间戳，不需要用户手机和API Server的时钟同步；

缺点：API Server需要额外维护APP请求ID以及随机数，并且APP需要多调用一次获取请求ID和随机数的接口。

2.2    采用数字签名+时间戳进行认证

APP维护一个OAuth2 Server的用户名/密码，APP每次在进行注册/登录接口请求之前，使用APP的OAuth2密码对请求进行HmacSHA256哈希计算，并用base64编码生成数字签名，然后再将用户注册/登录参数以及数字签名、时间戳（用于判断请求是否过期，一般设置为15分钟过期）一并传递到API Server，API Server根据这些信息来判断请求是否合法。

优点：API Server不需要额外维护APP请求ID以及随机数；APP无需在注册/登录前多调用一次获取请求ID和随机数的接口；

缺点：需要保证用户手机和API Server的时钟同步；在请求时间未过期的时间内仍旧存在重放***的可能性。

2.3    APP先进行OAuth2认证，然后传递access_token

APP维护一个OAuth2 Server的用户名/密码，APP每次在进行注册/登录接口请求之前，先调用OAuth2 Server接口进行认证并获取access_token，然后再将用户注册/登录参数以及该access_token一并传递到API Server，API Server配置注册/登录接口需要进行OAuth2认证。

优点：实现简单，只需很小改动即可实现；

缺点：APP需要多进行一次OAuth2接口调用；如果APP的access_token泄漏，仍旧存在重放***的可能性（其它使用access_token进行认证的接口也同样存在这个问题）。

3       无需APP端维护Key的方式进行认证

3.1    时间戳方式

“时戳”──代表当前时刻的数。

基本思想──A接收一个消息当且仅当其包含一个对A而言足够接近当前时刻的时戳。

原理──重放的时戳将相对远离当前时刻。

时钟要求──通信各方的计算机时钟保持同步。

处理方式──设置大小适当的时间窗（间隔），越大越能包容网络传输延时，越小越能防重放***。

适用性──用于非连接性的对话。在连接情形下双方时钟若偶然出现不同步，则正确的信息可能会被误判为重放信息而丢弃，而错误的重放信息可能会当作最新信息而接收。

3.2    序列号递增方式

通信双方通过消息中的序列号来判断消息的新鲜性。

要求通信双方必须事先协商一个初始序列号，并协商递增方法。

 

针对APP的实现方式：每个APP生成一个唯一编码代表该APP，登录的时候将该编码以及协商的序列号一起发送到服务端，服务接收到消息之后进行检查，只有符合条件的请求才会被认为合法，其他请求被认为不合法。

关键点：APP编码生成算法只能由APP和服务端知晓；序列号递增方式也只能由APP和服务端知晓；可考虑初始序列号跟APP编码关联产生。

3.3    提问应答方式

“现时”──与当前事件有关的一次性随机数N（互不重复即可）。

基本做法──期望从B获得消息的A 事先发给B一个现时N，并要求B应答的消息中包含N或f(N)，f是A、B预先约定的简单函数。

原理──A通过B回复的N或f(N)与自己发出是否一致来判定本次消息是不是重放的。

时钟要求──无。

适用性──用于连接性的对话。

 

 

 

转载于:https://blog.51cto.com/yuanhuan/1441298