我遇到了短信轰炸

Posted by fsoooo Blog on April 10, 2018

手机突然收到短信,提示阿里控制台短信服务当天短信阈值已经达到上限,无法发送短信。我的第一反应是,用户注册量激增?3秒钟之后,脑子冷静了一下,那是不可能的,最大可能性就是短信接口被搞了!

短信接口类的攻击方式无外乎,拿到url地址,模拟提交数据,使用不正当手段进行接口调用,已达到大量盗刷短信的效果。

这种攻击方式也叫作短信轰炸。

短信轰炸一般基于 WEB 方式(基于客户端方式的原理与之类似),由两个模块组成,包括:一个前端 Web 网页,提供输入被攻击者手机号码的表单;一个后台攻击页面(如 PHP),利用从各个网站上找到的动态短信 URL 和 前端输入的被攻击者手机号码,发送 HTTP 请求,每次请求给用户发送一个动态短信。

- 被攻击者大量接收非自身请求的短信,造成无法正常使用移动运营商业务。 - 短信接口被刷通常指的就网站的动态短信发送接口被此类短信轰炸工具收集,作为其中一个发送途径。

具体工作原理如下:

(1)恶意攻击者在前端页面中输入被攻击者的手机号; (2)短信轰炸工具的后台服务器,将该手机号与互联网收集的可不需要经过认证即可发送动态短信的 URL 进行组合,形成可发送动态短信的 URL 请求; (3)通过后台请求页面,伪造用户的请求发给不同的业务服务器; (4)业务服务器收到该请求后,发送动态短信到被攻击用户的手机上。

短信轰炸的防护方案

鉴于短信轰炸的发起一般都是服务器行为,应该采用如下综合手段进行防御

(一)增加图形验证

恶意攻击者采用自动化工具,调用“动态短信获取”接口进行动态短信发送,原因主要是攻击者可以自动对接口进行大量调用。 采用图片验证码可有效防止工具自动化调用,即当用户进行“获取动态短信” 操作前,弹出图片验证码,要求用户输入验证码后,服务器端再发送动态短信到用户手机上,该方法可有效解决短信轰炸问题。

安全的图形验证码必须满足如下防护要求

- 生成过程安全:图片验证码必须在服务器端进行产生与校验; - 使用过程安全:单次有效,且以用户的验证请求为准; - 验证码自身安全:不易被识别工具识别,能有效防止暴力破解。

luosimao目前提供的免费图形验证码方案:https://luosimao.com/service/captcha

image.png

(二)单IP请求次数限制

使用了图片验证码后,能防止攻击者有效进行“动态短信”功能的自动化调用; 但若攻击者忽略图片验证码验证错误的情况,大量执行请求会给服务器带来额外负担,影响业务使用。建议在服务器端限制单个 IP 在单位时间内的请求次数,一旦用户请求次数(包括失败请求次数)超出设定的阈值,则暂停对该 IP 一段时间的请求;若情节特别严重,可以将 IP 加入黑名单,禁止该 IP 的访问请 求。该措施能限制一个 IP 地址的大量请求,避免攻击者通过同一个 IP 对大量用户进行攻击,增加了攻击难度,保障了业务的正常开展。

(三)限制发送时长

建议采用限制重复发送动态短信的间隔时长, 即当单个用户请求发送一次动态短信之后,服务器端限制只有在一定时长之后(此处一般为60秒),才能进行第二次动态短信请求。该功能可进一步保障用户体验,并避免包含手工攻击恶 意发送垃圾验证短信。

短信轰炸防护场景策略

以下方式是在以上基础上进行改良之后,在不同场景之下进行不同的策略:

(一)后端增加IP黑名单,这个可以在第一时间内进行IP封禁,起到暂时防护作用;

使用场景:当发现短信接口被盗刷之后,要是产品线过多,第一时间内并不能针对每个产品先进行改良,最简单的办法,先在后端加一个IP封禁库,看到对方请求接口IP之后,直接先封了再说,这个是你的短信接口第一次遇见盗刷的最快速的解决办法,虽然对方可能有代理,可能会随时改变IP,但是一般的如果不是有针对性的搞你的话,这个办法还是可以的,但是这个不是最终解决办法,只是为你争取改进时间而已;

(二)前后端进行加密算法双向验证,推荐一种加密方式,base64(rsa(数据格式自己约定)),加密算法不可泄露;

使用场景:在网上找了各种各样的防范机制之后,发现都不是很尽人意,给对方并不会带来很大成本上的提高。而做这些防范措施的目的就是最大程度上给对方提高使用成本,如果对方盗刷你的接口的成本比他得到的利益要高,那么对方自然而然就不会搞你了。

(三)一定时间范围对内同一个手机号验证码发送次数限制(一天内一个平台一个手机号最多发送3次),这样即便是对方抓包,模拟发送同一个加密后的token,也可以最大程度上减少短信消耗量;

使用场景:这个是在第二种方式的基础上进行严格判断,当对方抓包之后,模拟提交同一个数据,这个后端就需要对同一个数据进行处理,同一个手机号或者时间进行判断。