短信接口攻击事件(一)紧张的遭遇战险胜

作者:13
GitHub:https://github.com/ZHENFENG13
版权声明:本文为原创文章,未经允许不得转载。

事件简述

这是一件发生在前段时间的事情,当时的情况是这样的:一个新的功能模块上线之后,出现短信接口被恶意访问调用的情况,请求数量很大,而且通过查看短信服务商控制台也发现,短信发送量在飙升,看着统计曲线的增长,紧张的气氛也渐渐变得更浓,很明显,事情并不是遇到一个bug那么简单,因为牵涉到服务费用,需要立即解决。

当然,接口被恶意访问的这个问题已经解决,因此写了这篇文章,可以做一下简单的记录,并且静下心来分析一下其中的问题了,看完这个案例,大家也可以一起讨论讨论。

问题分析

日志增长

这是当时的短信接口日志数量曲线,某一个时间点突然增长了起来并且没有降下去的意思,通过日志分析发现,攻击者用的不同IP、不同号码进行恶意调用,请求量较大,赶紧将事件做了记录并通知了相关人员,和同事做了沟通后,大家也都提出了自己的意见:有人说赶紧修改前端功能,发一版新的APP,有人说修改后端代码,紧急补救一下,也有人说要不要先关停一下服务......在网上技术论坛搜了一下相关问题,好像碰到这种事情的也不少,基本思路都是加验证码,做好安全验证,被攻击了无可奈何之类的云云。

简单对各个方案做了整理:

  • 修改url(APP已经上线,暂时无法修改)。
  • 添加验证码验证(APP已经上线,暂时无法通过这种方式来解决)。
  • 停掉短信服务(不现实,其他功能模块也需要调用短信服务,不考虑实施)。
  • 短信服务商自带防攻击,等一段时间,让攻击者自己停止攻击(虽然短信服务商自带防攻击,但是依然会出现大量的垃圾请求,而且服务商只是针对次数和时间做了限制,一段时间后依然会发送短信,因此,危害和损失还是不小的,问题依然急需处理掉,装鸵鸟是解决不了问题的)

解决方案

在用户交互界面拦截请求已经不现实了,因为移动端短时间内是无法立刻升级的,而等待攻击停止的方案也不可取,选择逃避和等待是解决不了问题的,因此最终的决定就是修改后端接口逻辑和代码。找到最关键的问题,虽然存在网络攻击,但是真正需要立刻解决的是短信服务接口的调用问题,当务之急是修改短信发送接口,尽快止损。

通过讨论和简单的分析,最终是决定先修改后端逻辑紧急打一个线上补丁,移动端也做同步修改,等待发版。

黑名单模式拦截

由于接口一直被调用,需要紧急处理,减少短信服务费用的损失,因此一开始的出发点放在了手机号码上,针对手机号码做验证,采用黑名单的模式,对于此接口中出现的号码,在一定次数的请求后就立刻加入到黑名单列表中,再次请求时,如果是黑名单中的号码,直接返回错误码,不做任何其他处理,也不会调用短信发送接口,这种方式可能会误伤到真实用户,但是情况比较特殊,因此就选择了这个应急方案,紧急修改了后端代码,对部分代码逻辑做了修改,添加手机号码的黑名单功能。在短信发送模块中,对号码进行验证,如果一段时间内多次请求同一个号码的话,将号码存入数据库视为黑名单中的号码,不会发送短信。
黑名单模式

拦截了近700个手机号码,这些号码中应该很多是空号吧:
短信黑名单

请求验证拦截

上面的方法虽然起到了一定的作用,但是依然无法很好的解决掉问题,为什么这么说呢?因为即使利用了黑名单模式,在进入到黑名单列表之前,依然会发送短信,试想一下每分钟1000次的恶意请求,即使拉黑了其中的一部分号码,还是会有一部分漏网之鱼会被当做正常数据,然后请求短信服务商接口发送短信,这也是一个不小的体量,黑名单模式可以处理一些问题,但是只能起到微小的作用,还需要进一步修改后端逻辑。

回到大家都提到的用验证码做安全验证,前端虽然无法立即更新添加验证码界面和处理逻辑,但是验证码的设计就是识别正常请求和非法请求,因此找到一个方法能够识别请求是否非法即可,并不一定非要添加验证码功能。本模块在设计接口之初,就做了数据传输规定,移动端向后端发送请求时,必须在请求头中放入一些参数,这些参数本来是做分析用的,但是在这里起到了很大的作用,因此可以在请求对象request上做文章,攻击请求只是发送请求到url,攻击者也只知道url并不知道请求参数设计,因此针对这点做验证,应该可以拦截掉所有的恶意请求了,甚至请求都不会到达黑名单验证环节就已经被处理掉了。

再次修改后端代码,由请求信息request对象入手,从请求对象request中提取数据做校检,甄别是否为正常请求,如果是正常请求,数据中的参数不会为空且参数值是可控的,而恶意虚假请求中则不含有这些参数,因此直接返回错误码不作处理即可,这个补丁打上之后,短信服务费用的损失就不会再增加了。
验证参数
非法请求不做处理,甚至都已经不需要黑名单拦截了。

短信发送量图片
当时的短信发送量统计,在做了验证之后,直接降了下去。

结语

不管是前端验证码,或者这次采取的验证请求方式,都是一种验证方式,用来甄别是否为移动端APP发送过来的正常请求,如果不是,就不做处理,通过日志和黑名单数据可以得出结论,短信发送的问题已经解决。

这个事件也说明,安全验证不能掉以轻心,也不能心存侥幸心理,一旦被心存恶意之人找到漏洞,还是挺难过的。前端验证没有完全考虑到,后端验证拦截也做的不到位,因此出现了这种情况,需要检讨和反思,而且处理方式也不是特别得当,一开始的黑名单模式并没有完全杜绝掉短信发送的问题,又去做了后面的补救,当时确实比较紧张,因此想到能用的方法就赶紧用在了修改上面。

为何说惊险和紧张,试想一下:周末刚刚在家里修整了两天,周一的早晨,打完卡坐在工位上悠闲的喝着茶,悠悠的打开浏览器查看系统日志,忽然发现这个访问量有点大呀,隐隐觉着不对,认真的查了一下发现,接口被攻击了,而且是短信发送的接口,看着一条条的短信因为攻击而发送出去,那一条条的短信,是白花花的银子啊,能不紧张吗!什么感觉?吃着火锅唱着歌,突然就被麻匪给劫了,跟葛大爷一样,就是那种感觉。

至于说险胜,是因为虽然暂时解决了短信发送的问题,不会再进一步的造成金钱的损失,却存在另外一个问题:大量的恶意请求

首发于我的个人博客,地址在这里

posted @ 2017-06-12 08:37 涵s 阅读(...) 评论(...) 编辑 收藏