逻辑漏洞挖掘之验证码漏洞总结
前言
在日常的授权测试中，很大一部分只有一个登录界面，在这个登录界面其实可以测试的东西有很多，比如用户名枚举，弱密码，验证码，找回密码等等一系列问题。现在的网站为了更好的用户体验，免去大家登录网站都要注册的问题，通常都采用了发送短信验证码的方式来登录，一方面是便捷，另一方面也算是采用的动态密码，安全性比较高，那随之而来的验证码的安全性问题也就显现出来了，便收集了一些相关案例和分享，才有了这篇文章。本文非常适合刚入门或者准备学习的安全人员，文中如有错误的地方，还望各位大佬在评论区指正。
验证码客户端绕过
在注册、登录、找回密码等，你点击发送验证码，然后随便输入验证码，然后更改返回包中的相关值即可实现验证码绕过，但经过这些年的洗礼，这种漏洞已经很少了，至少大厂应该大部分是不存在这种漏洞的只需要把状态码改为0或者将返回包false修改为true即可实现绕过。
验证码回显
burp代理开启 记录下所有数据包 并对其中可疑参数记录标记
输入手机号 获取验证码 这时已然收到了真实的验证码
但是为了获取更多的隐藏参数以及尽可能的走全业务逻辑，这里随便输了一个123456 故意让其报错
果然返回验证码错误，但是同时数据包中也返回了正确的验证码
验证码长度修改
我们需要此系统用户的手机号，我当时想到了三个办法：
- 通过github等搜集用户泄露的手机号；
- 强行爆破；
- 猜测系统中有测试用的手机号，如13333333333、13888888888等等。
幸运的是，此处通过手机号13333333333成功发送短信验证码，说明系统中存在此手机号。查看我们发送短信验证码的数据包，其中有个参数length引起了我的注意，length的值为6，猜测是短信验证码的长度，将length改为1，再次发送。
根据上一步推测，短信验证码长度是由length参数控制的，接下来我们可以通过依次尝试输入0-9来猜测短信验证码，当我们输入0的时候成功进入重置密码页面，输入新密码成功修改。
短信轰炸漏洞
短信轰炸问题其实是最容易想到的，当然对于短信的轰炸问题，还要分几类情况看待
无任何限制的短信轰炸
这种应该是在短信轰炸中最简单粗暴的一种方式吧，没有任何限制只需要通过burpsuite去重放数据包即可，然后就可以达到消耗目标网站的短信数量以及对手机号码拥有者造成困扰
特殊字符的填充
这种问题应该算是对限制手机发送短信的一种绕过方式，他的逻辑应该是这样的，用户输入手机号——>后端判断该手机号是否在30秒或者60秒内请求过——>如果没有，判断发送过来的手机号是够是11位的纯数字，如果不是，去掉非数字字符——>和数据库中的手机号比对，是否存在于数据库中，如果存在那么向该手机发送验证码。
看到这个逻辑你想到了啥，如果我们一开始输入的是11111111111这个号码，下次你空格+11111111111岂不是就同样给11111111111发送验证码，在下次加两个空格或者别的字符
常见填充：
+86、空格、#、等。
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”的目的。
图片验证码可置为空
如果你前端不传递验证码的话后端即不验证验证码，删除验证码即可触发短信炸弹漏洞，其实还有删除cookie等操作。不光出现在短信轰炸处，比如找回密码处等同样存在这样的问题
形如
1 | https://xxx.xxx.xxx/login.php?action=send&mobile=11111111111&send_code=undefined |
手机号双写绕过
比如一般参数是这样的：mobile=XXXXXX或phone=xxxxx，在请求包中通过连接符
1 | mobile=XXXXXX,xxxxxx或mobile=XXXXXX&mobile=XXXXXX |
验证码可以枚举
这也是个老生长谈的问题，主要是因为验证码是4位或者5位的数字验证码，并且验证码的过期时间很长造成的。尤其是4位数字验证码，只要枚举一万次即可枚举出正确的验证码，对于burpsuite来说，在没有限制的情况下请求1万次的时间应该在10分钟以内
手机号码可以篡改
篡改接收验证码的手机号，如果验证码没有和手机做绑定就可以进行一系列高危操作，比如登录账号，任意更改密码呀。举个例子，在找回密码处在给手机发送验证码时，会在请求包中出现手机号码，可以篡改手机号码，但是系统默认还是在找回密码第一步中输入的用户名，这样就可以劫持验证码，达到重置密码的效果。
有的确定可以通过更改手机号来获取验证码，但是无法通过校验，同样可以探测是否存在任意手机号触发短信轰炸的漏洞。
自定义验证码内容
举一个抖音海外版的例子，其他漏洞相关内容可以参照(https://www.freebuf.com/vuls/224963.html)
在TikTok的主要网站有一项功能可以让用户向自己发送SMS短信以下载该应用程序，DOWNLOAD_URL参数是会出现在SMS短信中的下载链接，所以只要篡改该参数即可实现篡改下载链接来进行钓鱼诈骗等相关活动
看一下手机接收到的信息
总结
短信验证码的安全性随着手机登录的普及变得越来越重要，对于短息验证码问题，列举几个通用的解决方法:
不要把验证方式置于前端，手机号和短信验证码在服务器进行唯一性绑定验证。
在服务端限制短信验证码发送周期，设置时效性，限制发送次数。
封禁的应该是恶意请求的手机号而不是IP地址，对一天内每一个手机号获得的验证码次数进行限制。
手机验证码生成6位或者以上的数字+字母组合的验证码，并且保证用后即失效
禁止用户自定义短信内容
微信
支付宝
