首页
学习
活动
专区
工具
TVP
发布

认识“短信炸弹”

随着短信认证功能在我们公司的Web应用中用到的越来越多,随之而来对于短信请求要做的安全防护也越来越重要。

“短信炸弹”缺陷就是最典型的针对短信功能的一种攻击,为了让大家对这种攻击有一个正确的认识,并了解相关的防护手段,我们做了本期的专题讲解。

举个栗子:

下面截图今年上半年公司某系统中曾暴露出的短信炸弹漏洞

第一章:认识“短信炸弹攻击”

概念:短信炸弹攻击,就是攻击者通过向服务器不断发送请求,请求向某个手机号码或某些手机号码发送短信验证码,导致服务器向单个手机号码或多个手机号码短时间内发送大量短信的攻击行为。

危害就是这样:

原因说明:如果前端页面上没有对用户请求进行有效保护,服务器端又缺少必要的校验和安全限制,那么就很容易遭受到短信炸弹攻击。

风险说明:风险较大,较难防御

第二章:防御手段

为了便于理解,我们从最基础的防护手段层层说起:

方案0:既然攻击者要在短时间内发送大量短信,那么就在发送短信的页面上,限制用户点击了发送短信按钮之后,1分钟内无法再次点击。

方案评估:图样图森破,没有攻击者会用点击按钮的方式进行攻击!这样的防护手段基本上就是掩耳盗铃,攻击者可以通过一万种方式绕过此防护方案。

方案1:为了防止攻击者对单个手机号码发起攻击,可以限制一个手机号码一分钟只能发送1次短信。一天只能发送10次短信。

方案评估:有改进,已经考虑到服务端的安全限制,但是还存在问题:这个安全限制并不能限制攻击者通过不断修改手机号码的方式消耗短信资源。

方案2:在方案1的基础上,限制攻击者IP,限制每个IP在一分钟内只能发送一次请求。

方案评估:有改进,但意义不大,因为攻击者可以使用脚本自动修改请求数据包中的源IP。

方案3:在方案1的基础上,限制同一个session ID的请求包,在一分钟之内只接受一次请求。

方案评估:有较大改进,能够拦截简单的攻击工具了。但是还存在问题:攻击者可以循环模拟“获取session ID->发送攻击包"的过程。或者利用DDoS,或者控制肉鸡向服务器发起攻击。

方案4:服务器端再生成SessionID的时候,判断客户端的IP,或要求用户身份验证,对于同一个IP/用户的客户端在一段时间内始终返回相同的session ID。

方案评估:现在仅凭一个客户端已经无法发起疯狂的短信炸弹攻击了,但是还存在问题:攻击者可以使用DDoS攻击,利用肉鸡发起攻击

方案5:在方案4 的基础上,在页面加入图形验证码。

方案评估:验证码是目前比较有效的图灵验证方法,可以有效阻止计算机自动发送的请求数据,从而防止“短信炸弹”攻击。

备注:这种方案也是目前防止短信炸弹通用的、最有效的方案。大家可以看一下各个网站发送短信的页面,基本上都有图形验证码。

如下:

金融类需要发送短信的注册页面:

非金融类需要发送短信的页面

相信大家已经对短信炸弹如何防范有了正确的认识,那么问题来了?公司目前系统中发送短信的页面是不是已经做到了这样的安全防护呢?希望所有的小伙伴都认真思考一下。

当然,我们在推行安全控制的时候,一定会有盲目跪舔客户的业务部门人员说:“输入验证码再获取短信验证码不符合客户操作习惯”之类的鬼话。

首先希望我们的需求人员要坚定立场,不接受这种需求!

再其次,如果确实大领导拍板,想要不输入验证码就获取短信,也不是不可操作的,但是要加入额外的安全控制措施。

再举个例子:

平安保险微信报案页面,第一次请求短信是不带验证码的:

再次尝试获取短信,必须输入验证码:

这里是怎么实现的呢?相信我们开发的小伙伴应该都清楚,我就不做详细解释了。

另外说明:以后这就是我们对发送短信请求页面的安全测试标准,请大家了解。

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20171220G00XEC00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券