作为与当前业务相关的技术人员,对待外部复杂的用户需要有一个牢靠的安全防护机制才能保障业务稳定、持续的运行,一方面为了自己的私心,可以舒服的工作和生活,睡安稳觉;另一方面,给公司降低资损,投入要跟产出成正比;最关键一点,还是希望业务更加强壮的持续运行,拼命的赚 money。
年末了,新零售、电商、信贷行业的业务系统也比较多,活动遇到的技术问题可能也比较多,今天给大家分享一下 如何防护短信接口或相关业务 API 接口被刷的一些防护经验?我希望和大家一起交流能够互相学习取长补短。
现在有很多 web 站点业务都用了短信验证码作为账号注册、登录、找回密码、投票验证等等业务场景的必备件,用短信验证码的目的是什么?为什么要用?这个我想技术人员要深思一下,这个问题不在此累赘。
如何用好它?
在我遇到的客户中,有很多都是短信接口被刷,有的一天损失几十万的短信配额,资损达到几万 /天,有的技术人员压根就不知道自己的业务被刷了,有的是知道,但是不知道怎么解决? 我先总结几条防护方案: 1.手机号码有效性的逻辑检测 2.前端需要随机校验 3.增加友好的图形验证码 4.同号码短信发送频率限制 5.不同号码请求数量限制 6.梳理清楚业务,适当的对场景流程限定 7.启用 https 协议,全球都在用,还在等什么? 8.单 IP 请求限定,看起来很 low,但是有时候效果很好
以上策略配合着用效果还是不错,现在没有根治的办法,只能缓解 如果大家还有好的点子,我们一起讨论交流一下。
1
linxl 2018-01-09 10:15:06 +08:00
短信不是充钱的嘛, 没钱就没法发短信了. 这是啥短信接口可以一致发送?
|
3
liiiiv00 2018-01-09 11:15:45 +08:00
遇到过两次短信接口被恶意攻击,其实基本无外乎楼主说的。不过第八条单 ip 限定最好不要,有些学校一栋楼一个出口 ip,有的小的地方运营商也是,一个小区就几个出口 ip 公用。感觉增加图形验证码+同号码发送频率限制就基本解决了,反正我那两次是 ok 的。然后还加了一个同号码同业务的每天发送次数限制,打算如果还是不行就配置上,不过最后也没用上
|
4
ORZRRR 2018-01-09 11:21:44 +08:00 1
一大推废话不知道要干嘛,特别是 4、7,
|
5
tadtung 2018-01-09 12:09:03 +08:00 via Android 1
你这写了这么多,,这些东西难道不是大家都清楚的?
|
6
lianxiaoyi 2018-01-09 12:32:24 +08:00
#5 我也同意这种观点,打码平台已能破解市面上 90%的验证码了。什么答题的啊,滑动的啊,这种验证码都弱爆了,增加验证码只是也增加它攻击成本,像我更多的是分析你的请求,以及页面点击坐标,屏幕分辨率,点击时间,早就从动作开始分析了。。。。。。。。
|
7
jiangzhuo 2018-01-09 12:37:44 +08:00
换成上行验证码,让用户自己也付钱,这时候就看谁有钱了,你要刷我五万块的你也得花个四五万——短信接口提供商恐成最大赢家
|
8
yylucifer 2018-01-09 12:51:29 +08:00
ip 加特征识别,高端大气又用户友好。
|
9
tomczhen 2018-01-09 12:52:57 +08:00
被刷有两种情况,一种是被当作攻击器的接口了,一种是可以获得足够的利益覆盖成本。防御方面有两个取舍,一个是防御成本,第二个是用户体验。
被当成攻击器的接口应该是没办法完全杜绝的,好在攻击器收益低,因此通过验证码、IP 现在、目标手机号发送频率这些都能提高使用者成本,只要有存在调用成本比你低的接口,那么被利用的几率就会小很多。 但是获取额外收益这种就不太好处理了,只要利益足够就一定有人会做。 首先业务逻辑不能出什么漏洞这是必须的。然后就是通过分析用户操作、行为进行判断,或者购买一些商业数据库对号码进行屏蔽,不过这些手段需要的付出的技术成本是高于通过验证码、IP 限制方式的,需要有一定的技术能力和投入。 还有就是从运营角度解决了,虽然“点击就送”这种模式简单粗暴,获取用户速度快,但是送得太容易会被人盯上,业务逻辑上考虑必须有应对的方法,如果只是想做好看的数据干脆自己买验证码接收服务就行了,何必再额外给人撸一层? 随着浏览器挖矿的可行,现在还有一种方式是让用户通过挖矿带来收益覆盖掉短信成本,这样单次计算压力是可以接受的,但是批量运作就无法接受了,如果可用的话,也算是不错的方法。 |
10
qichengzx 2018-01-09 13:19:20 +08:00
正好在负责公司的对内服务的短信业务功能。
说说自己的一点经验。 1.号码有效性检测是必不可少,甚至可以说不需要说的限制。 2.对单一手机号的频率验证,如 10 分钟内只能发送一条,1 天只能发送 10 条。 3.结合 2,根据业务类型,对频率的限制,如果是营销短信,一般情况是群发,可以忽略其中每个手机号(一段时间内)的频率。 4.短信运营商(阿里,腾讯等)一般也会有多重限制,分钟级,小时级,天级的限制。 5.特定的业务,只允许特定时间段发送短信。 如 3 楼所说,验证 IP 容易误伤。特别是如果是某种线下活动,用户聚集在一个地方同时请求短信,IP 很可能只有几个,甚至只有 1 个。 另外,频率校验还需要考虑并发的情况。 最后,私心的打个广告,前几天刚刚完成的腾讯云 Go 语言 SDK,还有不足,请多多指教。 (qcloudsms Go SDK)[https://github.com/qichengzx/qcloudsms_go] |
11
Annual 2018-01-09 13:32:10 +08:00
马云厂的的验证码对接应该可以吧。
|
12
qsnow6 2018-01-09 13:33:52 +08:00
限制一下频率,日发上限 10 条就可以终结了
|
13
colincat 2018-01-09 13:38:31 +08:00
@lianxiaoyi 是可以破解,但是难度也在那呢,可以屏蔽一些弱鸡的黑产
|
14
Annual 2018-01-09 13:41:53 +08:00
或者,不一定使用短信去验证用户,可以用其他方式啊,例如微信扫一扫授权一下。刷单这样风险就会好很多。还省去验证码费用
|
15
dangyuluo 2018-01-09 13:53:42 +08:00
可以换一下思路,如果目标用户群体和微信的目标群体大体一致的话,可以考虑改成微信通知。批量注册微信可难多了。
|
16
yimaneilicj 2018-01-09 13:54:34 +08:00
前几天用的阿里云的短信服务,自带限流····
|
17
opengps 2018-01-09 17:18:07 +08:00
@yylucifer 天朝的网络结构不敢轻易用限制 ip 的方式,公网到户独享一个(短期也算独享)的概率太小,大多数都是一堆人公用一个 ip 池,所以限制 ip 误杀范围很大
|
18
iyangyuan 2018-01-09 17:26:38 +08:00
终极解决方案:不提供短信接口
|
20
opengps 2018-01-10 00:12:12 +08:00 via Android
对了,补一个案例,帮楼主思考用,刚好是今天发生的,我一个同学中招,先是接到一个电话,骂他,骂她老婆,实际上仅仅是有人贷款填写了他的手机号,电话之后收到短信轰炸,几分钟 100 条,各种网站的注册验证码,还有部分密码找回短信
|
21
yongjing 2018-01-10 08:29:59 +08:00
目前在用 token 验证 和 图片验证码验证两种方式 (刷短信的多为短信服务商干的)
|
22
michael2016 OP @tadtung 你可以发表观点,但是无法替代所有的人去草率的用个人角度去评价一个事情是否合适还是不合适,right ?
|
23
michael2016 OP @ORZRRR 当你遇到 CC attack 就会理解真正的含义
|
24
michael2016 OP @qsnow6 粗暴有效果,但是如果你是电商业务,日活量用户上百千万,订单金额在几个亿的话,你这种方式会被老板送进监狱里的
|
25
michael2016 OP @Annual 这样会比较好,仅限于前端,但是有很多 web 端的场景是提供 API 的,业务场景复杂,不具有很强的通用性。
|
26
michael2016 OP @yimaneilicj 还是存在资源浪费,我们要做的就是让成本资源的效益最大化
|
27
michael2016 OP @dangyuluo 个别场景可以这样,但是对于 web 首页登录、注册等场景可能不太适合
|
28
michael2016 OP @yongjing (刷短信的多为短信服务商干的) ,慎言慎行,小心被请喝茶。
|
29
michael2016 OP @iyangyuan 有的场景提供短信登录是为了提升用户体验和安全性,兼容并蓄,不可一棒子打死。
|
30
michael2016 OP 没钱自己对抗,缺点是容易掉头发还解决不了问题,有钱就用阿里云防爬蛮好,省心省力,缺点就是费钱。
|