API测试之:接口重放攻击

原创
2020/05/10 21:15
阅读数 724


API重放攻击(Replay Attacks)又称重播攻击、回放攻击。他的原理就是把之前窃听到的数据原封不动的重新发送给接收方,来达到欺骗系统的目的,主要用于身份认证过程,重放攻击是计算机世界黑客常用的攻击方式之一。

HTTPS并不能防止这种攻击,虽然传输的数据是经过加密的,窃听者无法得到数据的准确定义,但是可以从请求的接收方地址分析出这些数据的作用。比如用户登录请求时攻击者虽然无法窃听密码,但是却可以截取加密后的口令然后将其重放,从而利用这种方式进行有效的攻击。
重放攻击会导致什么后果
1.本来只存100万的,由于这个漏洞,我变成了世界首富
2.本来只取了10块钱,由于这个漏洞,我的银行卡余额变成了0
3.本来只充值了10个金币,由于这个漏洞,我成了游戏里的一哥
4.本来只买了一个娃娃,由于这个漏洞,现在给我送来了一屋子的娃娃
....................
总结:问题很严重,老板很生气

运维因删库跑路,测试因重放入狱,搞得我满头大汗,立马去看一了下彪哥的《API测试之:接口重放攻击》,真香啊~~~

知己知彼,百战不殆,我们先了解一下接口防重放有哪些策略(不一定全面)

1.防重放几种策略

1.基于timestamp的方案
 每次HTTP请求,都需要加上timestamp参数,然后把timestamp和其他参数一起进行数字签名。因为一次正常的HTTP请求,从发出到达服务器一般都不会超过60s,所以服务器收到HTTP请求之后,首先判断时间戳参数与当前时间相比较,是否超过了60s,如果超过了则认为是非法的请求。
但这种方式的漏洞也是显而易见的,如果在60s之后进行重放攻击,那就没办法了,所以这种方式不能保证请求仅一次有效。

2.基于nonce的方案
nonce的意思是仅一次有效的随机字符串,所以该参数一般与时间戳有关,实际使用时可以加上客户端的ip地址,mac地址等信息做个哈希之后,作为nonce参数。
我们将每次请求的nonce参数存储到redis缓存中。每次处理HTTP请求时,首先判断该请求的nonce参数是否在该“集合”中,如果存在则认为是非法请求。

这种方式也有很大的问题,那就是存储nonce参数的“集合”会越来越大,验证nonce是否存在“集合”中的耗时会越来越长。我们不能让nonce“集合”无限大,所以需要定期清理该“集合”,但是一旦该“集合”被清理,我们就无法验证被清理了的nonce参数了。也就是说,假设该“集合”平均1天清理一次的话,我们抓取到的该url,虽然当时无法进行重放攻击,但是我们还是可以每隔一天进行一次重放攻击的。而且存储24小时内,所有请求的“nonce”参数,也是一笔不小的开销。

3.基于timestamp和nonce的方案
nonce的一次性可以解决timestamp参数60s的问题,timestamp可以解决nonce参数“集合”越来越大的问题。

4.唯一索引机制
用一张表来存储锁的记录,线程一插入一条Lock记录数据,成功,相当于获取锁,线程二再尝试插入一条Lock记录数据,由于有唯一索引的限制,插入会失败,线程一处理完业务,删除此条记录,相当于释放锁

5.分布式锁
分布式锁策略采用的是同一个业务ID的不同线程对锁的争用情况来达到防重的目的

6.缓存计数器
缓存计数器采用的策略类似于分布式锁的实现,缓存计数器把同一个业务ID每次请求的次数放在缓存(如redis)中,线程一对业务ID进行加1后发现等于1,处理业务。线程二对业务ID进行加1后发现大于1,说明有操作在进行返回。线程一处理完业务,删除key,即释放锁

2.重放测试场景

1.金融行业,如:支付、存款、取款、扣费、充值等
2.电商行业,如:支付、提交订单、领取优惠券、库存扣减等
3.其它和金钱、物品、验证码等相关场景

3.重放测试分类

我把重放测试分为两类:
第一类:前端界面重放测试
前端重放测试主要是控制按钮点击或界面刷新,比如点击提交按钮后,按钮应该同时变为禁用状态,这样可以防止用户多次点击按钮,达到初步防重放的效果;刷新主要是在数据提交成功后,再次刷新界面时会不会再次成功提交数据。前端防重放只能防止小白,要防老手还得靠接口层的防重放,那是不是说前端界面就不用防重放了?答案肯定是否定的,前端防重放不但能提升用户的体验,还能减少不必要的请求,从而提升了效率

第二类:API接口重放测试
API接口重放主要可通过抓包工具进行,一般的抓包工具都提供了回放和请求编辑功能,这样就可以把抓到的接口再次请求,从而实现重放攻击测试,看看现在想要实现重放攻击多简单。但重放测试肯定不是简单回放一下请求,更深层次的测试,应该是在修改请求部分数据后,接口是否还能正常处理,所以在设计测试用例时一定要了解程序的实现方案,这样才能有效、针对性的设计出高效的测试用例

4.重放测试要点

1.界面控件多次点击
2.刷新界面请求重放
3.修改参数再次请求
4.不断回放请求
5.并发请求


如何确定接口是否存在重放问题?如果接口经过重放调用后,多次生成有效的业务数据,可判定为接口存在重放问题。在接口测试时,是不是所有的重放问题我们都必须要修复了,还是要结合业务,有些业务比如和钱相关的,那必须得改,其它问题结合成本取舍,比如有些前端做控制即可,毕竟做重放的判断也是要消耗性能的。

本文章仅代表个人观点,如有纰漏喜欢私信或留言


如果你认可这篇文章,请点击在看

本文分享自微信公众号 - 彪哥的测试之路(gh_c1b79633c733)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部