标签：过多 号码 间隔 接收 cookie 目的 用户 解决问题 限时
最近的测试过程中，遇到了很多厂商的验证码业务都存在短信炸弹的情况，可以出现在注册、登录、重置密码的某个步骤中，输入手机号之后抓取获取验证码的数据包进行重放，从而达到在短时间内对同一个手机号进行短信轰炸的目的。还有一种情况是对于服务端对某一个手机进行攻击会做限制，但是可以对不同号码进行多次的攻击（即针对某一个号码段的号码进行“群发”短信）。
从自己遇到的一些防御手段来介绍吧。。。。
在输入手机号之后同时要加上验证码，两个参数同时发送到服务端，服务端首先对验证码进行识别，当验证码判断正确之后再对该手机发送验证码。
这一种防御方式依旧存在漏洞。攻击者可以使用验证码识别插件编写脚本进行识别，同时提交到服务器进行短信轰炸。这一类只是提高了攻击门槛，但是不能从根本上解决问题。
用token作为唯一性识别验证，后台写一个算法将token注入到前端，然后前端可以通过相应的规则获取到token，用户在提交手机号的同时，请求头同时会带上该token。其中就有包含用户当前唯一身份标识的信息。服务器每次发送验证码的时候就将该用户的发送次数加1，当达到5次或者某个上限时就不在发送短信。这一种情况在实际情况中挺常见的，但是设计也要做到仔细不然就会有很大的问题。
首先是判断逻辑。在几次测试过程中，我也遇到过类似的情况。直接重放数据包，只能发送1个短信就会提示已发送过了。但是如果删除cookie就可以无限次数重放了。这是因为后台在判断cookie时没有考虑完全，忽略了当cookie 为空的情况。正确的情况应该是首先判断cookie 参数是否存在，不存在就返回到前一个界面或者提示会话已过期。当cookie参数存在的时候再判断该用户已发送过多少次，如果超出限制就提示错误，不再发送。
对单个手机号进行日接收次数的限制，可以防止单个手机号无限制刷短信，同时设置时间间隔可以有效。短信接收次数可以根据平台特点进行限制，一般日接受验证码次数为10次左右；同一号码发送时间间隔通常为60秒或者更长，前后台应保持一致，避免出现只前端做倒计时限制，后台未做限制这种低级错误。
对单IP最大发送量进行限制，可以一定程度防止单一IP下对多个手机号进行炸弹攻击的问题。最大发送量限制是防止恶意攻击者同IP下不同手机号进行刷短信验证码行为。根据平台实际情况设计一个短信最大发送量的上限，超过上限则不发送短信。但是这种情况攻击者可以使用代理工具绕过限制。
标签：过多 号码 间隔 接收 cookie 目的 用户 解决问题 限时
原文地址：https://www.cnblogs.com/a-little-bai/p/9595219.html
