短信接口被恶意盗刷(验证码短信被盗刷)怎么办?

发布时间:2024-08-24 18:01

短信验证码被刷怎么办?

  • 一 事件简述
  • 二 问题分析
  • 三 应急解决方案
    • 1 黑名单模式拦截
    • 2 请求验证拦截
    • 3 应急方案总结
  • 四 最终解决方案
    • 第一步:获取防火墙帐号密钥
    • 第二步:下载防火墙服务器
    • 第三步:前后端接入
    • 查看防火墙数据

一 事件简述

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

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

二 问题分析

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

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

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

三 应急解决方案

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

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

1 黑名单模式拦截

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

拦截了近700个手机号码,这些号码中应该很多是空号吧:
短信接口被恶意盗刷(验证码短信被盗刷)怎么办?_第3张图片

2 请求验证拦截

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

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

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

3 应急方案总结

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

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

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

短信接口被恶意盗刷(验证码短信被盗刷)怎么办?_第5张图片

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

四 最终解决方案

使用短信防火墙。 从以下几个方面概括一下:

新昕科技在交易反欺诈核心上, 通过AI快速学习机制,结合国际领先的设备指纹技术,首次推出无需图形验证码机制的企业短信防火墙,三步完成下载对接。
短信接口被恶意盗刷(验证码短信被盗刷)怎么办?_第6张图片

第一步:获取防火墙帐号密钥

进入 防火墙控制台,在左侧导航栏选择【网站管理】,进入网站管理页面,单击【发到邮箱】接收密钥。
在这里插入图片描述

第二步:下载防火墙服务器

前往新昕科技官网,在顶部导航栏选择【解决方案】>【下载中心】,进入下载中心页面,找到短信防火墙服务器安装包,点击【下载链接】即可下载。

第三步:前后端接入

前端接入

   Java 在页面合适的位置(标签内)加入以下代码引入JS文件:         
<script type="text/javascript" src="/NxtJsServlet"></script>

PHP 在页面合适的位置(标签内)加入以下代码引入JS文件:

   <script id="finger" type="text/javascript" src="/nxt_inc/nxt_front.php"></script>

后端接入

Java

修改配置(和业务系统同系统不需要修改):

newxtc.ini (存放位置:"/WEB-INF/classes/newxtc.ini")
修改参数(fireWareUrl)–> fireWareUrl=http://localhost:7502

短信下发

public RetMsg smsSend(HttpServletRequest request, HttpServletResponse response, String clientMobile) {
    RetMsg retMsg = new RetMsg(-1, "系统异常");
    FwClient fwClient = new FwClientImpl();
    try {
        // 1 调用【短信防火墙】短信发送请求
        HashMap < String, Object > paramMap = fwClient.getSendReq(request, clientMobile);
        String jsonReq = fwClient.execReq(paramMap);
        String smsSendRet = fwClient.getRetVaule(jsonReq, "riskResult");
        if("REJECT".equals(smsSendRet)) {
            retMsg.setRet(3);
            retMsg.setMsg("请求过于频繁");
        }
        else {
            // 业务 TODO
            // 业务调用短信接口 TODO
            // 调用短信接口 结束
            if(smsRetMsg != null && smsRetMsg.getRet() == 0) {
                // 2 调用【短信防火墙】成功结果
                fwClient.execSucc(paramMap);
                logger.debug("send succ");
                retMsg.setRet(0);
                retMsg.setMsg("发送验证码成功");
            }
            else {
                // 2 调用【短信防火墙】失败结果
                SmsVerifyCache.getInstance().remove(clientMobile);
                fwClient.execFail(paramMap);
                retMsg.setRet(-1);
                retMsg.setMsg("发送验证码失败");
            }
        }
    }
    catch(Exception e) {
        for(StackTraceElement elment: e.getStackTrace()) {
            logger.error(elment.toString());
        }
    }
    return retMsg;
}

短信验证

public RetMsg smsVerify(HttpServletRequest request, HttpServletResponse response, String clientMobile, String smsVerifyCode) {
    FwClient fwClient = new FwClientImpl();
    RetMsg retMsg = new RetMsg(-1, "系统异常");
    if(smsVerifyCode == null || smsVerifyCode.isEmpty()) {
        retMsg.setRet(1);
        retMsg.setMsg("输入验证码为空");
    }
    else {
        // 1 调用【短信防火墙】验证请求
        HashMap < String, Object > paramMap = fwClient.getVerifyReq(request, clientMobile); // 请求防火墙
        String jsonReq = fwClient.execReq(paramMap);
        // 报文处理
        String smsSendRet = fwClient.getRetVaule(jsonReq, "riskResult");
        if("REJECT".equals(smsSendRet)) {
            retMsg.setRet(3);
            retMsg.setMsg("请求过于频繁");
        }
        // 业务 TODO
        if(cacheSmsVerify != null && cacheSmsVerify.getVerifyCode() != null && !cacheSmsVerify.getVerifyCode().isEmpty()) {
            if(cacheSmsVerify.getVerifyCode().equals(smsVerifyCode)) {
                retMsg.setRet(0);
                retMsg.setMsg("验证成功");
            }
            else {
                retMsg.setRet(1);
                retMsg.setMsg("验证码错误");
            }
        }
        else {
            retMsg.setRet(-9);
            retMsg.setMsg("验证码超时");
        }
        if(retMsg.getRet() == 0) {
            // 2 调用【短信防火墙】成功结果
            fwClient.execSucc(paramMap);
        }
        else {
            // 2 调用【短信防火墙】失败结果
            fwClient.execFail(paramMap);
        }
    }
    return retMsg;
}

查看防火墙数据

通过风控数据看板,可查看1-30天的验证情况、风控拦截情况以及验证事件触发的风控策略情况。
进入防火墙控制台,在左侧导航栏选择【风险大盘】,进入风险大盘页面。
在这里插入图片描述

ItVuer - 免责声明 - 关于我们 - 联系我们

本网站信息来源于互联网,如有侵权请联系:561261067@qq.com

桂ICP备16001015号