前言

在日常的授权测试中，很大一部分只有一个登录界面，在这个登录界面其实可以测试的东西有很多，比如用户名枚举，弱密码，验证码，找回密码等等一系列问题。现在的网站为了更好的用户体验，免去大家登录网站都要注册的问题，通常都采用了发送短信验证码的方式来登录，一方面是便捷，另一方面也算是采用的动态密码，安全性比较高，那随之而来的验证码的安全性问题也就显现出来了。

一 短信轰炸漏洞

短信轰炸问题其实是最容易想到的，当然对于短信的轰炸问题，还要分几类情况看待

1.1 无任何限制的短信轰炸

这种应该是在短信轰炸中最简单粗暴的一种方式吧，没有任何限制只需要通过burpsuite去重放数据包即可，然后就可以达到消耗目标网站的短信数量以及对手机号码拥有者造成困扰

1.2 有验证码的短信轰炸

这个相对于无任何限制的短信轰炸是做了限制的，加上了验证码。如果验证码可以重放的话那还是可以归类到无任何限制的短信轰炸中。如果验证码不能重放并且也不能通过手段提前预知，我最常采用的方法便是python的selenium模块配合验证码识别工具去模拟浏览器请求登录，这种方式不用考虑复杂的交互情况，完全交给浏览器去实现，准确度取决于你验证码识别工具的准确度。网上有很多识图工具，比如各大厂商的OCR等等，或者是github上各位大佬的基于机器学习的验证码识别工具等等

importrequestsimporttimeimporthashlibfromseleniumimportwebdriverfromPILimportImagefrombs4importBeautifulSoupheaders={"User-Agent":"Mozilla/5.0 (Windows NT 10.0; WOW64; rv:56.0) Gecko/20100101 Firefox/56.0","Accept":"*/*","Accept-Language":"zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3","X-Forwarded-For":"137.0.0.2","Content-Type":"application/json;charset=utf-8"}proxies={"http":"http://127.0.0.1:8080","https":"https://127.0.0.1:8080"}defyanzhengma():url='http://127.0.0.1:7779'files=open("E:/img/t1.png",'rb')r=requests.post(url,proxies=proxies,data=files)returnr.textdefsendPhone(brower,ph):brower.get('https://xxx.xxx.xxx')phone=brower.find_element_by_xpath("//*[@id=\"mobile\"]")phone.send_keys(ph)path='E://img//t.png'imgpath='E:/img/t1.png'brower.get_screenshot_as_file(path)im=Image.open(path)box=(1157,320,1274,380)region=im.crop(box)region.save(imgpath)submit=brower.find_element_by_xpath("//*[@id=\"sendSms\"]")image=brower.find_element_by_xpath("//*[@id=\"verifyCode\"]")yzm=yanzhengma()image.send_keys(yzm)submit.click()time.sleep(5)defmain():brower=webdriver.Chrome()foriinrange(0,10):sendPhone(brower,"11111111111")if__name__=='__main__':main()

先通过屏幕截屏获取整个图片，然后再去截取验证码，最后通过验证码识别器识别出验证码后发送到浏览器触发短信轰炸漏洞，该漏洞的危害性主要取决于验证码识别的难易程度以及对发送短信次数的限制。现在基本主流的网站在手机验证码的时候必须要进行一步验证，最主要的是验证码验证，当然现在还有滑块验证之类的。有兴趣的可以去尝试通过模拟浏览器登录破解滑块验证码。

1.3 特殊字符的填充

这种问题应该算是对限制手机发送短信的一种绕过方式，他的逻辑应该是这样的，用户输入手机号——>后端判断该手机号是否在30秒或者60秒内请求过——>如果没有，判断发送过来的手机号是够是11位的纯数字，如果不是，去掉非数字字符——>和数据库中的手机号比对，是够存在于数据库中，如果存在那么向该手机发送验证码。

看到这个逻辑你想到了啥，如果我们一开始输入的是11111111111这个号码，下次你空格+11111111111岂不是就同样给11111111111发送验证码，在下次加两个空格或者别的字符

1.4 短信发送间隔太短

有的网站设定的短信发送间隔是30秒，时间间隔太短，可以找一批手机号，控制请求间隔，保证每个手机号两个发送间隔大于30秒即可，同样可以造成短信轰炸漏洞

1.5 ip限制绕过

该漏洞的主要原因是限制的是IP并不是手机号，简单粗暴的方式增加代理池再去爆破，但这样成本太高，那这个漏洞的危害性就比较小了。那么如果服务端对于IP的校验可以在前端进行伪造绕过IP限制那这个危害相对来说就比较大了。

这里推荐一个IP伪造的burpsuite插件 https://github.com/TheKingOfDuck/BurpFakeIP/

http协议中的IP伪造不同于TCP/IP协议，在实现正常的TCP/IP 双方通信情况下，是无法伪造来源 IP 的，也就是说，在 TCP/IP 协议中，可以伪造数据包来源IP，但这会让发送出去的数据包有去无回，无法实现正常的通信。

HTTP 是一个应用层协议，基于请求/响应模型。客户端（往往是浏览器）请求与服务器端响应一一对应。服务器的响应格式也是类似的由响应头信息和响应正文构成。如果服务器通过request中的 x-forwarded-for 和 client-ip 等来获取客户端的ip，那么客户端可以伪造 Client-Ip, X-Forward-For等内容欺骗程序，达到"伪造IP"的目的。

1.6 图片验证码可置为空

如果你前端不传递验证码的话后端即不验证验证码，删除验证码即可触发短信炸弹漏洞，其实还有删除cookie等操作。不光出现在短信轰炸处，比如找回密码处等同样存在这样的问题

形如 https://xxx.xxx.xxx/login.php?action=send&mobile=11111111111&send_code=undefined

二 验证码可以枚举

这也是个老生长谈的问题，主要是因为验证码是4位或者5位的数字验证码，并且验证码的过期时间很长造成的。尤其是4位数字验证码，只要枚举一万次即可枚举出正确的验证码，对于burpsuite来说，在没有限制的情况下请求1万次的

时间应该在10分钟以内

三 手机号码可以篡改

篡改接收验证码的手机号，如果验证码没有和手机绑定就可以进行一系列高危操作，比如登录账号，任意更改密码呀。举个例子，在找回密码处在给手机发送验证码时，会在请求包中出现手机号码，可以篡改手机号码，但是系统默认还是在找回密码第一步中输入的用户名，这样就可以劫持验证码，达到重置密码的效果。

有的确定可以通过更改手机号来获取验证码，但是无法通过校验，同样可以探测是否存在任意手机号触发短信轰炸的漏洞

四 自定义验证码内容

举一个抖音海外版的例子，其他漏洞相关内容可以参照(https://www.freebuf.com/vuls/224963.html)

在TikTok的主要网站有一项功能可以让用户向自己发送SMS短信以下载该应用程序，DOWNLOAD_URL参数是会出现在SMS短信中的下载链接，所以只要篡改该参数即可实现篡改下载链接来进行钓鱼诈骗等相关活动

看一下手机接收到的信息

五 验证码客户端绕过

这种也很常见，你点击发送验证码，然后随便输入验证码，然后更改返回包中的相关值即可实现验证码绕过，但经过这些年的洗礼，这种漏洞已经很少了，至少大厂应该大部分是不存在这种漏洞的

只需要把状态码改为0即可实现绕过

总结

短信验证码的安全性随着手机登录的普及变得越来越重要，对于短息验证码问题，列举几个通用的解决方法:

不要把验证方式置于前端，手机号和短信验证码在服务器进行唯一性绑定验证。

在服务端限制短信验证码发送周期，设置时效性，限制发送次数。

封禁的应该是恶意请求的手机号而不是IP地址，对一天内每一个手机号获得的验证码次数进行限制。

手机验证码生成6位或者以上的数字+字母组合的验证码，并且保证用后即失效

禁止用户自定义短信内容