首页 > 编程知识 正文

银行卡是被怎么盗刷的,截取短信验证码盗刷了怎么办

时间:2023-05-03 08:05:54 阅读:139296 作者:3162

短信验证码打印出来后怎么办? 事件简介2问题分析3紧急解决方案1黑名单模式拦截2请求验证拦截3紧急解决方案总结4最终解决方案第一步:获取防火墙帐户密钥第二步:下载防火墙服务器第三步:前后查看防火墙数据

事件概要

这是前几天的事。 当时的情况是,新的功能模块上线后,出现了消息接口被恶意访问和调用的情况,要求数量增多。 此外,在消息提供者控制台中,消息发送量急剧增加,而看到统计曲线的增加,紧张感也随之增加。 很明显,没有遇到bug那么简单。 涉及服务费用,需要立即解决。

当然,接口被恶意访问的问题已经解决。 因此,写了这篇文章,做个简单的记录,用可爱的唇膏分析一下那个问题吧。 你可以看这个案例,大家一起讨论。

二问题分析

这是当时消息接口日志数量的曲线,在某个时刻突然增加,没有下降的意义。 通过日志分析发现,攻击者使用的不同IP、不同号码进行恶意调用,请求量大。 赶紧把事件记录下来并通知了相关人员。 和同事沟通后,大家也提出了自己的意见。 被告知要立即修改前端功能,发送新APP,修改后端代码。 也有人说要么紧急修复,要么停止服务……但在网络技术论坛上搜索相关问题后,似乎遇到这样的事情也不少。 基本的想法是打上验证码,进行安全的验证,被攻击了怎么办等等,众说纷纭。

简单地整理了各方案:

修改URL (APP已在线,暂时无法修改)。 添加验证码进行验证(APP已经在线,暂时无法通过此方法解决)。 停止短信服务(这是不切实际的,其他功能模块也必须调用短信服务,并且不考虑实现)。 短信提供程序自带攻击防护,稍等片刻,让攻击者自己停止攻击。 (短信提供商自带防攻击功能,但仍然会出现大量垃圾请求。 另外,服务提供商只是对次数和时间设置了限制,过一会儿也会发送短信。 因此,危害和损失不少,问题仍然亟待解决。 加入鸵鸟不能解决问题) )三种紧急解决方案,用户通过界面拦截请求已经不现实。 由于移动端无法在短时间内立即升级,也不喜欢等待攻击停止,所以选择逃避或等待并不能解决问题。 因此,最终的决定是修改后端接口的逻辑和代码。 要找出最重要的问题,有网络攻击,但真正需要立即解决的是消息服务接口的调用问题,当务之急是尽快修改邮件发送接口,赔钱。

通过讨论和简单分析,最终决定修改后端逻辑紧急打在线补丁,移动端也进行同步修改,等待发布。

1黑名单模式监听由于接口被调用,需要紧急处理,为了减少短信服务费的损失,最初的出发点放在手机号码上。 对手机号码进行验证,采用黑名单模式,对出现在该接口的号码,在一定次数的请求后立即添加到黑名单中,再次请求时,如果是黑名单号码,就会返回错误代码,不做其他处理也不会调用短信发送接口。 这可能会误伤实际用户,但情况特殊,所以选择了该应急方案,紧急修改了后端代码,修改了部分代码逻辑,增加了手机号码黑名单功能。 短信发送模块验证号码,如果在一定时间内多次请求同一号码,将号码保存到数据库将被视为黑名单号码,不会发送短信。

截获了近700个手机号码。 这些号码大多是空号码吧:

2虽然通过验证截获上述方法起到了一定的作用,但仍然不能很好地解决问题。 为什么会这样呢? 因为即使使用了黑名单模式,也会在进入黑名单之前发送邮件。 想想一分钟1000次恶意请求。 即使黑客了其中的一些号码,一些泄露的鱼也会被当作正常数据处理,要求消息提供者接口发送邮件也不是很大的量。 黑名单模式可以处理一些问题,但只起到很小的作用。 后端逻辑需要修改。

回到大家提到的使用验证码进行安全验证,虽然前端无法立即更新添加验证码的接口和处理逻辑,但验证码的设计是为了识别普通请求和非法请求,所以我们希望找到一种方法来识别请求是否正确本模块在设计接口之初,就设置了移动端向后端发送请求时,必须在请求报头中加入参数的数据传输规定。 这些参数本来是分析用的,但在这里起着很大的作用,所以可以在请求对象的request上写文章,攻击请求只被发送到url,攻击者也只知道url而不知道请求参数的设计,对此进行验证

要再次修改后端代码,请从请求信息request对象开始,从请求方request提取并检查数据,以确定请求是否正常。 如果是正常的请求,数据中的参数为空,参数值是可控的,但是恶意虚假请求中不包含这些参数,所以必须按原样返回错误代码进行处理。 应用此补丁后,短信服务费用损失不会增加。

3应急预案的汇总,无论是前端验证码,还是此次进行的认证请求方式,都是为了分辨是否是移动端APP发送的正常请求的认证方式,否则不做处理,根据日志和黑名单数据,发送邮件的问题

该事件表明,安全验证不能疏忽,也不能有侥幸心理。 如果被恶毒的人发现漏洞,还是很悲伤。 出现这种情况是因为没有充分考虑前端验证,也没有充分进行后端验证侦听。 需要讨论和反省,而且处理方法也特别不合适。 最初的昵称

单模式并没有完全杜绝掉短信发送的问题,又去做了后面的补救,当时确实比较紧张,因此想到能用的方法就赶紧用在了修改上面。

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

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

四 最终解决方案

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

新昕科技在交易反欺诈核心上, 通过AI快速学习机制,结合国际领先的设备指纹技术,首次推出无需图形验证码机制的企业短信防火墙,三步完成下载对接。

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

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

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

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

第三步:前后端接入

前端接入

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天的验证情况、风控拦截情况以及验证事件触发的风控策略情况。
进入防火墙控制台,在左侧导航栏选择【风险大盘】,进入风险大盘页面。

版权声明:该文观点仅代表作者本人。处理文章:请发送邮件至 三1五14八八95#扣扣.com 举报,一经查实,本站将立刻删除。