一 事件简述
这是一件发生在前段时间的事情,当时的情况是这样的:一个新的功能模块上线之后,出现短信接口被恶意访问调用的情况,请求数量很大,而且通过查看短信服务商控制台也发现,短信发送量在飙升,看着统计曲线的增长,紧张的气氛也渐渐变得更浓,很明显,事情并不是遇到一个bug那么简单,因为牵涉到服务费用,需要立即解决。
当然,接口被恶意访问的这个问题已经解决,因此写了这篇文章,可以做一下简单的记录,并且静下心来分析一下其中的问题了,看完这个案例,大家也可以一起讨论讨论。
二 问题分析
在这里插入图片描述
这是当时的短信接口日志数量曲线,某一个时间点突然增长了起来并且没有降下去的意思,通过日志分析发现,攻击者用的不同IP、不同号码进行恶意调用,请求量较大,赶紧将事件做了记录并通知了相关人员,和同事做了沟通后,大家也都提出了自己的意见:有人说赶紧修改前端功能,发一版新的APP,有人说修改后端代码,紧急补救一下,也有人说要不要先关停一下服务......在网上技术论坛搜了一下相关问题,好像碰到这种事情的也不少,基本思路都是加验证码,做好安全验证,被攻击了无可奈何之类的云云。
简单对各个方案做了整理:
修改url(APP已经上线,暂时无法修改)。
添加验证码验证(APP已经上线,暂时无法通过这种方式来解决)。
停掉短信服务(不现实,其他功能模块也需要调用短信服务,不考虑实施)。
短信服务商自带防攻击,等一段时间,让攻击者自己停止攻击(虽然短信服务商自带防攻击,但是依然会出现大量的垃圾请求,而且服务商只是针对次数和时间做了限制,一段时间后依然会发送短信,因此,危害和损失还是不小的,问题依然急需处理掉,装鸵鸟是解决不了问题的)
三 应急解决方案
在用户交互界面拦截请求已经不现实了,因为移动端短时间内是无法立刻升级的,而等待攻击停止的方案也不可取,选择逃避和等待是解决不了问题的,因此最终的决定就是修改后端接口逻辑和代码。找到最关键的问题,虽然存在网络攻击,但是真正需要立刻解决的是短信服务接口的调用问题,当务之急是修改短信发送接口,尽快止损。
通过讨论和简单的分析,最终是决定先修改后端逻辑紧急打一个线上补丁,移动端也做同步修改,等待发版。
1 黑名单模式拦截
由于接口一直被调用,需要紧急处理,减少短信服务费用的损失,因此一开始的出发点放在了手机号码上,针对手机号码做验证,采用黑名单的模式,对于此接口中出现的号码,在一定次数的请求后就立刻加入到黑名单列表中&#