公司短信平台上的2万块钱,瞬间就被黑光了
我是风筝,公众号「古时的风筝」,一个兼具深度与广度的程序员鼓励师,一个本打算写诗却写起了代码的田园码农! 文章会收录在 JavaNewBee ,还要更多文章合集。
前两天的中午像往常一样热,太阳不知疲倦的在天空燃烧,热跑了云彩和鸟儿,马上就要点燃空气和我的脑神经。为我和电脑降温的,是我简陋的书桌上的小电扇,没有它的话,键盘太热,我可能就要写不下去代码了。
正在此时,旁边的手机嗡嗡的震了两声,对于手机从来不敢开铃声的人来说,这个震动的声音实在太熟悉了,不用说,应该是广告短信,或者有人加我微信好友了。因为短信我基本上从来不看,微信消息不会有提示,只有加好友才有,由于最近有不少朋友看到我写的文章,所以每天加我好友的还是不少的,我都是找空闲时间统一处理。所以,我还是继续写我的代码,没有理会。
过了两分钟左右,嗡嗡~~又震了两声,不慌,继续写代码。然后嗡嗡 ~~ 又震了两声,接着又震了两声,我心想,难道又是哪个大号转了我文章了(心里略带几分得意),淡定,继续写代码。
这时候已经持续了 6、7次,我刚要拿手机看一下,突然有事儿,赶紧开门出去了,过了20分钟回来之后,发现手机还在震。我赶紧拿起来一看,未读短信数量变多了(这是写文章的时候截的图,真实数量比这个还要多一点,被我点了)。
我去怎么这么多短信了,我记得很清楚,本来才 820 多条(是在要对有强迫症的朋友表示歉意,这图可能让你们看上去很不爽),原谅我不怎么看短信,一直堆积了 800 多条。怎么半个小时的时间多了好几十条,我打开一看,都是某不知名公司的登录验证码消息,就像下面这样。
【XX科技】您正在短信登录,验证码689287,请在15分钟内提交验证码,切勿将验证码泄露于他人。
瞬间让我想到一个词:短信轰炸机。what,有人轰炸我,我得罪什么人了吗,于是大脑飞速运转。
难道是前几天问我问题我没及时回答,然后骂我,被我删掉的那个兄弟吧?
难道是最近那个毫不客气、素不相识,上来就让我帮他抓数据,我让他滚的那个总监吧?
又或者是多次举报我文章非原创的某大佬吧?
值得吗,不至于吗,这么劳神伤财费力的,不至于吧。就在我思考的时间内,手机平静了,不响了,事实证明我可能想多了,可能就是某短信轰炸机轰炸的时候定位错了目标,然后及时发现了,或者其他什么原因。
熟悉的场景
这个场景勾起了我的某些回忆,与此同时,我对XX科技
表示深切的同情。几年前,我所在的创业公司就被短信轰炸机利用,一晚上,短信平台上的 2 万块钱化为乌有。
短信轰炸机
手机短信轰炸机是批量、循环给手机无限发送各种网站的注册验证码短信的方法。一般一分钟可以收到超过一百条短信,可用于测试手机的短信接收速度。可以是在电脑运行或是手机运行。
比如有人想整你,花点钱买个短信轰炸或者电话轰炸(学名呼死你)的服务,你的手机瞬间变成一个高频振动器或者循环铃声播放器,轻则让你手机发烫,重则直接没电关机。
现在的短信平台很多,比如腾讯、阿里、华为什么的一大堆,而且都有防盗刷等功能,当时,不知道老板从哪个渠道找到的一个短信平台,具体名字已经不记得了,毕竟已经好几年了。当时,那个平台好像是充 2 万,送 5000,所以老板直接充了两万,按照几分钱一条短信计算,以当时公司业务体量来看,用到公司倒闭可能都用不完。
那时候,经过几个月的艰苦奋战,开发的产品顺利上线,但是没有推广,正在进行最后的线上测试,只是公司内部人测试,还有认识的一些朋友用用,顺道帮忙测试一下,眼看着就要开始大范围推广了。
某晚夜黑风高,老板突然打电话过来,说他收到了短信平台费用预警通知,显示余额所剩不多,让我赶紧登录看一下是什么情况。当我进入页面的那一刻,我惊呆了,已用 4 万多条,剩余几千条了。赶紧给客服打电话询问情况,其实到这一刻的时候,我们还没意识到是系统安全漏洞被利用了,客服解释说这个账号确实是一直在发短信,短信内容是验证码相关的,并且现在还在持续发,询问是否要先把服务停掉。
什么,还在持续的发,那赶紧先停了再说,于是让客服操作先把服务停了。
当时我也是初入互联网,并不知江湖如此险恶,团队也是草台班子,也都没想到会出现这种问题。当我冷静下来开始思考并且到搜索引擎搜索相关问题的时候,我找到了短信轰炸机的这个概念,短信轰炸机最喜欢利用具有安全漏洞的开放平台的短信发送接口了,比如注册、登录接口,而我们的网站确实由于没做验证码发送的防护措施,导致漏洞产生,从而被利用了,说到底,还是当时能力不到位。
到现在为止我也不知道当时我们这个还没推广的小产品是怎么被盯上,然后被利用的。有说可能是短信平台方有内鬼,把客户信息卖给第三方平台,或者就是自产自销,短信快点儿用完,就可以赶紧续费了呀。
还有说是短信轰炸平台会黑掉这些正常的短信平台,然后找到使用方,进而利用。
还有说,他们就是全网扫这种 register、login 等类似的 url,扫通了就收集起来,进一步处理,并发现其中可以被利用的。
但具体是哪种,我也不知道,反正就是你不做好防护,就得被利用。
事故现场和防护处理
这其实就是安全漏洞了,只不过比较低级,低级到什么程度了呢?就是你在注册页面输入手机号之后,点击「发送验证码」按钮,只会判断手机号是否合法和是否已经注册,否则就直接发验证码,这叫无知无畏。这就相当于是开门迎客的状态,不需要权限,没有调用频次限制,也没有什么 token 之类的做校验。
当时停掉短信服务之后,我马上去看了后台日志,发现有很多不同的 IP 在不断的发来请求,丧心病狂的是,虽然短信服务已经停了,但是请求还在不断涌来。看来这就是一套完整的自动化流程,用 IP 池动态代理,模拟发送请求,我们的短信接口只不过就是其中一个微不足道的免费资源而已。
停掉服务
当时已经很晚了,快要凌晨了,但是大脑被刺激的很是清醒。首先想的就是别管怎么样,先让服务正常可用吧。但是请求还在一直过来,于是,我先把 Nginx 服务关闭了,既然你这么智能,接口你访问不到,是不是就会停了。停了 5 分钟之后,我刚一重启,马上日志又被填满,事实证明不是它不智能,是我弱智了。它才不管你,它就是一台没有感情的自动请求机器。
更换接口地址
行吧,我认怂可以吧,服务我又不能停,你这台没有感情的机器我也控制不了,那我先改了接口地址。于是我把注册、登录的接口地址先给换了,这样一来,总能把短信服务先剥离开,先减轻点服务器压力吧。但还是不敢把短信服务打开,万一它又发现我们的新接口了呢。
这时已经很晚了,还好产品还没有推广,没什么人用,就先睡了,等着第二天处理。
加图形验证码
第二天早早去公司,第一件事儿,就是看看那台没感情的机器是不是放过我们了,结果一看日志,心突然有点儿凉,我休息了一晚,它却没休息。
有同事说,要不换 IP 吧?
大哥,人家请求的是域名,倒是可以换个二级域名,之前是 api.xxxx.com 作为后端服务 domain 的,于是有同事开始鼓捣换二级域名。
我这边开始加其他规则,首先想到的就是加验证,在发送验证码之前加个图形验证,当时找到了「极验」提供的行为验证的方式。就是大家经常看到的下面这种方式,在发送验证码之前先让用户完成行为校验,基本上可以把机器人阻挡在外,而且集成很简单。
但是,咨询了一下费用,当时就被劝退了,当时是年费 5 万,不知道现在多少钱了。
图形验证码也不错,关键是不用花钱啊,于是找了开源代码,做了图形验证码。当时为了更加安全,让机器更难破解,当时做了 6 位字母、数字组合,并且干扰因素加的很足。事实证明不仅能放防机器,还能防人,很多同事做测试的时候表示经常很难辨认出来。于是改成了 4 位,并且降低了干扰因素。
有了这次教训,当我看到 12306 一步步升级验证码难度的时候,我能体会到 12306 的无奈和内心的彷徨。
限制访问频次
加了图形验证码是第一步,还不行,万一被绕过了,毕竟自动识别验证码也只是增加了门槛,如果真有人想搞你,还是拦不住的。
限制单个手机号的验证码请求频次,5分钟内只允许发送三次,一小时内超过 9 次就限制24小时不允许发送。
除了限制手机号的频次外,还限制单个 IP 的请求频次,规则是一样的。
设置黑名单
但是对方使用的是动态 IP 池,可能不会 5 分钟内连续请求。通过日志分析,发现这段时间内共有几百个 IP在发请求过来,于是把这段时间内单 IP 请求超过 10 次的全部加入黑名单。
并且4小时单 IP 请求超过 8 次的都加入黑名单。当然这些规则都是通过观察日志得到了,当然最终的科学依据是「拍脑袋」。
之后有请求过来,先看 IP 是否在黑名单中,如果在,就直接拒绝。
其他方式
除了以上措施外,还有其他的一些防护方式。
比如在用户进入前端页面(登录或注册页)的时候生成一个或者请求一个 Token,然后请求的时候对 Token 做校验,你可以写一些比较复杂的算法逻辑在里面。当然这也只是增加了门槛而已,如果被掌握了流程,还是一样会被利用。
旧的域名接口也一直保留着,倒要看看它会请求多久,过了差不多 8、9 天吧,请求才消失。
最后
安全问题也是互联网开发中很重要的方面,但是经常被开发人员忽视。细思极恐,如果是在产品刚推广的时候出现问题,那对用户的伤害真的是极大的。
有一些初创公司就是因为某些安全漏洞,直接导致公司关门大吉。大厂更是面临风险,很多实力雄厚的羊毛党就是利用漏洞来薅羊毛的,比如前段时间某大商城由于优惠券漏洞被薅了几千万。
只要有利可图,就有被利用的风险,安全问题,还需谨慎对待。
壮士且慢,先给点个赞吧,总是被白嫖,身体吃不消!
我是风筝,公众号「古时的风筝」。一个兼具深度与广度的程序员鼓励师,一个本打算写诗却写起了代码的田园码农!你可选择现在就关注我,或者看看历史文章再关注也不迟。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Python 3.10 的首个 PEP 诞生,内置类型 zip() 迎来新特性
> 译者前言:相信凡是用过 zip() 内置函数的人,都会赞同它很有用,但是,它的最大问题是可能会产生出非预期的结果。PEP-618 提出给它增加一个参数,可以有效地解决大家的痛点。 > > 这是 Python 3.10 版本正式采纳的第一个 PEP,「Python猫」一直有跟进社区最新动态的习惯,所以翻译了出来给大家尝鲜,强烈推荐一读。(PS:严格来说,zip() 是一个内置类(built-in type),而不是一个内置函数(built-in function),但我们一般都称它为一个内置函数。) PEP原文 : https://www.python.org/dev/peps/pep-0618/ PEP标题: Add Optional Length-Checking To zip PEP作者: Brandt Bucher 创建日期: 2020-05-01 合入版本: 3.10 译者 :豌豆花下猫 @Python猫公众号 PEP翻译计划 :https://github.com/chinesehuazhou/peps-cn 摘要 本 PEP 建议给内置的 zip 添加...
- 下一篇
深入了解kafka系列-消费者
前言 与生产者对应的是消费者,应用程序可以通过KafkaConsumer来订阅主题,并从订阅的主题中拉取消息。不过在使用KafkaConsumer消费消息之前需要先了解消费者和消费组的概念,否则无法理解如何使用KafkaConsumer。 <!--more--> Consumer 消费者(Consumer)负责订阅Kafka中的主题(Topic),并且从订阅的主题上拉取消息。与其他一些消息中间件不同的是:在Kafka的消费理念中还有一层消费组(Consumer Group)的概念,每个消费者都有一个对应的消费组。 当消息发布到主题后,只会被投递给订阅它的每个消费组中的一个消费者。如图所示,某个主题中共有4个分区(Partition):P0、P1、P2、P3。有两个消费组A和B都订阅了这个主题,消费组A中有4个消费者(C0、C1、C2和C3),消费组B中有2个消费者(C4和C5)。按照Kafka默认的规则,最后的分配结果是消费组A中的每一个消费者分配到1个分区,消费组B中的每一个消费者分配到2个分区,两个消费组之间互不影响。每个消费者只能消费所分配到的分区中的消息。换言之,每...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
-
Docker使用Oracle官方镜像安装(12C,18C,19C)
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8编译安装MySQL8.0.19
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
推荐阅读
最新文章
- SpringBoot2整合Redis,开启缓存,提高访问速度
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Hadoop3单机部署,实现最简伪集群
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- MySQL8.0.19开启GTID主从同步CentOS8
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16