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

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

事件简述

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

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

问题分析

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

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

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

解决方案

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

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

黑名单模式拦截

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

拦截了近700个手机号码，这些号码中应该很多是空号吧：

请求验证拦截

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

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

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

非法请求不做处理，甚至都已经不需要黑名单拦截了。

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

结语

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

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

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

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

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