一、 事件简述
这是一件发生在前段时间的事情，当时的情况是这样的：
一个新的功能模块上线之后，出现短信接口被恶意访问调用的情况，请求数量很大，而且通过查看短信服务商控制台也发现，短信发送量在飙升，看着统计曲线的增长，紧张的气氛也渐渐变得更浓，很明显，事情并不是遇到一个bug那么简单，因为牵涉到服务费用，需要立即解决。
当然，接口被恶意访问的这个问题已经解决，因此写了这篇文章，可以做一下简单的记录，并且静下心来分析一下其中的问题了，看完这个案例，大家也可以一起讨论讨论。
二、 问题分析
这是当时的短信接口日志数量曲线，某一个时间点突然增长了起来并且没有降下去的意思，通过日志分析发现，攻击者用的不同IP、不同号码进行恶意调用，请求量较大，赶紧将事件做了记录并通知了相关人员，和同事做了沟通后，大家也都提出了自己的意见：有人说赶紧修改前端功能，发一版新的APP，有人说修改后端代码，紧急补救一下，也有人说要不要先关停一下服务…在网上技术论坛搜了一下相关问题，好像碰到这种事情的也不少，基本思路都是加验证码，做好安全验证，被攻击了无可奈何之类的云云。
简单对各个方案做了整理：
修改url(APP已经上线，暂时无法修改)。
添加验证码验证(APP已经上线，暂时无法通过这种方式来解决)。
停掉短信服务(不现实，其他功能模块也需要调用短信服务，不考虑实施)。
短信服务商自带防攻击，等一段时间，让攻击者自己停止攻击(虽然短信服务商自带防攻击，但是依然会出现大量的垃圾请求，而且服务商只是针对次数和时间做了限制，一段时间后依然会发送短信，因此，危害和损失还是不小的，问题依然急需处理掉，装鸵鸟是解决不了问题的)
三、 应急解决方案
在用户交互界面拦截请求已经不现实了，因为移动端短时间内是无法立刻升级的，而等待攻击停止的方案也不可取，选择逃避和等待是解决不了问题的，因此最终的决定就是修改后端接口逻辑和代码。找到最关键的问题，虽然存在网络攻击，但是真正需要立刻解决的是短信服务接口的调用问题，当务之急是修改短信发送接口，尽快止损。
通过讨论和简单的分析，最终是决定先修改后端逻辑紧急打一个线上补丁，移动端也做同步修改，等待发版。
1 、黑名单模式拦截
由于接口一直被调用，需要紧急处理，减少短信服务费用的损失，因此一开始的出发点放在了手机号码上，针对手机号码做验证，采用黑名单的模式，对于此接口中出现的号码，在一定次数的请求后就立刻加入到黑名单列表中。
再次请求时，如果是黑名单中的号码，直接返回错误码，不做任何其他处理，也不会调用短信发送接口，这种方式可能会误伤到真实用户，但是情况比较特殊，因此就选择了这个应急方案，紧急修改了后端代码，对部分代码逻辑做了修改，添加手机号码的黑名单功能。
在短信发送模块中，对号码进行验证，如果一段时间内多次请求同一个号码的话，将号码存入数据库视为黑名单中的号码，不会发送短信。
拦截了近700个手机号码，这些号码中应该很多是空号吧：
2 、请求验证拦截
上面的方法虽然起到了一定的作用，但是依然无法很好的解决掉问题，为什么这么说呢？因为即使利用了黑名单模式，在进入到黑名单列表之前，依然会发送短信，试想一下每分钟1000次的恶意请求，即使拉黑了其中的一部分号码，还是会有一部分漏网之鱼会被当做正常数据，然后请求短信服务商接口发送短信，这也是一个不小的体量，黑名单模式可以处理一些问题，但是只能起到微小的作用，还需要进一步修改后端逻辑。
回到大家都提到的用验证码做安全验证，前端虽然无法立即更新添加验证码界面和处理逻辑，但是验证码的设计就是识别正常请求和非法请求，因此找到一个方法能够识别请求是否非法即可，并不一定非要添加验证码功能。
本模块在设计接口之初，就做了数据传输规定，移动端向后端发送请求时，必须在请求头中放入一些参数，这些参数本来是做分析用的，但是在这里起到了很大的作用，因此可以在请求对象request上做文章，攻击请求只是发送请求到url，攻击者也只知道url并不知道请求参数设计，因此针对这点做验证，应该可以拦截掉所有的恶意请求了，甚至请求都不会到达黑名单验证环节就已经被处理掉了。
再次修改后端代码，由请求信息request对象入手，从请求对象request中提取数据做校检，甄别是否为正常请求，如果是正常请求，数据中的参数不会为空且参数值是可控的，而恶意虚假请求中则不含有这些参数，因此直接返回错误码不作处理即可，这个补丁打上之后，短信服务费用的损失就不会再增加了。
3 、应急方案总结
不管是前端验证码，或者这次采取的验证请求方式，都是一种验证方式，用来甄别是否为移动端APP发送过来的正常请求，如果不是，就不做处理，通过日志和黑名单数据可以得出结论，短信发送的问题已经解决。
这个事件也说明，安全验证不能掉以轻心，也不能心存侥幸心理，一旦被心存恶意之人找到漏洞，还是挺难过的。前端验证没有完全考虑到，后端验证拦截也做的不到位，因此出现了这种情况，需要检讨和反思，而且处理方式也不是特别得当，一开始的黑名单模式并没有完全杜绝掉短信发送的问题，又去做了后面的补救，当时确实比较紧张，因此想到能用的方法就赶紧用在了修改上面。
为何说惊险和紧张，试想一下：周末刚刚在家里修整了两天，周一的早晨，打完卡坐在工位上悠闲的喝着茶，悠悠的打开浏览器查看系统日志，忽然发现这个访问量有点大呀，隐隐觉着不对，认真的查了一下发现，接口被攻击了，而且是短信发送的接口，看着一条条的短信因为攻击而发送出去，那一条条的短信，是白花花的银子啊，能不紧张吗！什么感觉？吃着火锅唱着歌，突然就被麻匪给劫了，跟葛大爷一样，就是那种感觉。
至于说险胜，是因为虽然暂时解决了短信发送的问题，不会再进一步的造成金钱的损失，却存在另外一个问题：大量的恶意请求。
四、 更完美的解决方案
为了在产品安全和优秀的用户体验之间寻找一个极佳的平衡。使用新昕科技[短信防火墙]。从以下几个方面概括一下：
为保障优秀的用户体验，摈弃了目前影响用户体验最为严重的图形验证码等人机校验程序，做到无感验证。从而达到完美的用户体验。
结合用户的手机号码 、IP地址 、设备指纹三个唯一身份标识设置不同维度的风控策略。将各个维度之间相互配合，达到一个最为合理的风控限制指标。
根据业务情况自动伸缩风控限制，在检测处受攻击时自动加大风控限制力度，在正常是再归回到正常风控标准。
考虑到存在新老客户的区别，特意增加老客户VIP通道，在受到攻击时，风控指标紧缩的情况下，保证老客户通道畅通无阻，从而降低误伤率。
通过以上策略可以有防止攻击者通过随意切换手机号及IP地址的方式可以刷取短信。同时加入模拟器检测，以及参数加密等风控策略，有效防止黑客攻击。
可通过风控防火墙控制台，实时观测风控结果，在受到攻击时达到第一时间预警的效果。
五、结语
这篇文章到这里就结束了，感谢大佬们驻足观看，大佬们点个关注、点个赞呗~
