验证码缺失/绕过
0x01 等保测评项
GBT 22239-2019《信息安全技术 网络安全等级保护基本要求》中，8.1.4.4安全计算环境—入侵防范项中要求包括：a）应遵循最小安装的原则，仅安装需要的组件和应用程序；b）应关闭不需要的系统服务、默认共享和高危端口；c）应通过设定终端接入方式或网络地址范围对通过网络进行管理的管理终端进行限制；d）应提供数据有效性检验功能，保证通过人机接口输入或通过通信接口输入的内容符合系统设定要求；e）应能发现可能存在的已知漏洞，并在经过充分测试评估后，及时修补漏洞；f）应能够检测到对重要节点进行入侵的行为，并在发生严重入侵事件时提供报警。 验证码缺失/绕过对应访问控制项中要求e），所以安全控制点为入侵防范e。
GBT 28448-2019《信息安全技术 网络安全等级保护测评要求》中，测评单元（L3-CES1-21） 该测评单元包括以下要求: a）测评指标：应能发现可能存在的已知漏洞，并在经过充分测试评估后，及时修补漏洞。；b）测评对象：终端和服务器等设备中的操作系统（包括宿主机和虚拟主机操作系统）、网络设备（包括虚拟网络设备）、安全设备（包括虚拟安全设备）、移动终端、移动终端管理系统、移动终端管理客户端、感知节点设备、网关节点设备、控制设备、业务应用系统、数据库管理系统、中间件和系统管理软件等。c）测评实施包括以下内容：1）应通过漏洞扫描、渗透测试等方式核查是否不存在高危风险漏洞；2）应核查是否在经过充分测试评估后及时修补漏洞；d）单元判定：如果1）和2）均为肯定，则符合本测评单元指标要求，否则不符合或部分符合本测评单元指标要求 验证码缺失/绕过属于测评单元（L3-CES1-21）中测评实施的第1项，故定测评单元为L3-CES1-21.1。
0x02 测试内容
通过拦截调用验证码处相关数据包，如登录功能、密码找回、留言提交等处，测试验证码是否有效，是否可以进行绕过或重复利用。
0x03 漏洞原理
验证码是什么 验证码是一种区分用户是计算机还是人的公共自动程序。这个问题可以由计算机生成并评判，但是必须只有人类才能解答。由于计算机无法解答验证码的问题，所以回答出问题的用户就可以被认为是人类。
验证码有中文字、纯数字、英文字母、点击字符串、图片图形、数学运算等等。
验证码的作用
• 进行人机校验；
• 验证使用者身份，判断当前账户使用者是否是账户的拥有者；
• 防止恶意的IP频繁访问；
• 防止恶意操作导致用户本身受损失；
• 防止暴力破解；
• 防止恶意灌水；
• 防止刷票；
验证码分类 常见的验证码有：短信验证码、语音验证码、图文验证码、数字验证码等等。形式多样核心内容一致，根据形式的不同就有了分门别类的应用。具体可看之前写的文章《渗透遇见验证码，跑路？or 拿下它？》。
根据作用可分为以下两种：
• 区分用户是计算机还是人的公共全自动程序，比如Google登录时的验证码、12306图片识别的点击式验证码等。
• 识别身份的验证码，用于识别用户是否为账号的所有者，比如短信验证码、邮箱验证码、电话验证码等。
验证码绕过
验证码大致可通过以下两种思路进行绕过
1. 识别法：脚本+深度学习、神经网络的知识；
2. 逻辑绕过，开发人员写验证码校验代码时产生逻辑错误。
无验证码
应用登录功能未设置验证码校验机制，且无登录失败次数过多锁定策略，这种情况下可直接尝试进行暴力破解。
验证码为空值
有验证码机制，但是在请求包中将验证码参数删除，服务器端就不进行验证码校验，会直接校验账户、密码；或者虽然页面中显示有验证码机制，但在不填写验证码直接输入用户名、密码的情况下，可直接登录，存在爆破风险。
万能验证码
0000、1111、8888、000000、123456等，一般多出现于设备、硬件设备。
验证码藏于Cookie中
一般情况下系统会将验证码的值用Session存储起来，再通过对比用户提交的验证码和Session中的验证，就可以知道用户输入的是否正确. 但由于Session 会占用服务器资源，有些程序员会将验证码的值加密后存储在Cookie中。针对这种情况，攻击者可以通过抓取登录数据包，分析包中的Cookie字段，查看其中有没有相匹配的验证码或者是经过简单加密后的验证码。
验证码隐藏于源码中
记住验证码，打开网站源码，用Ctrl+F搜索，如果搜索到刚才输入的验证码，就说明验证码被隐藏于源码中，接下来就可以使用工具提取源码中的验证码并将其放入每次的请求包中，对用户名、密码进行破解。
前端校验验证码
前端对验证码进行校验，相当于没有设置验证码，可通过抓包查看是否有验证码传参，或禁用JS进行绕过。
验证码未进行校验
代码虽设置有验证码模块，但未对验证码进行校验，随机输入就可验证成功；
验证码可控
某些系统获取验证码的方式为通过参数的方式去加载，比如http://www.123.com/yanzhengma.php?code=**** 等，攻击者就可以尝试将参数code的值改为undefined，即设为控制；也可以通过便便携脚本的方式获取验证码并传入验证流程。
验证码重复使用
应用程序设置了验证码校验机制，但是验证码可重复使用，没有过期限制，相当于无验证机制。一般是在某一段时间内，无论登录失败多少次，只要不刷新页面或者不刷新验证码，就可以无限次的使用同一个验证码来对一个或多个用户帐号进行暴力猜解。换句话说，攻击者可以在同一个会话下，在获得第一个验证码后，后面不再主动触发验证码生成页面，并且一直使用第一个验证码就可循环进行后面的表单操作，从而绕过了验证码的校验作用，对登录进行暴力猜解。
验证码有规律
验证码有生成规则而非随机验证码，比如某些系统会设置验证码为时间戳的后6位。
验证码包含于返回包中
由于开发在写代码时不严谨导致通过抓包可在返回包中查看以明文或者简单加密的验证码，这种情况相当于验证码直接返回，攻击者可利用此漏洞进行任意账户注册、任意用户密码重置、修改绑定信息等。
验证码可识别
若验证码过于简单，就可以使用工具对图案进行识别，比如验证码识别工具Pkav HTTP Fuzzer。
验证码输出至HTML页面
应用程序登录功能、找回密码等处设置了短信/邮件验证码校验机制，但验证机制存在问题，发送的验证码直接输出到客户端HTML页面。
0x04 代码示例
Pikachu漏洞练习平台验证码绕过（on server） 源码\vul\burteforce\bf_server.php文件中，在用户名、密码和验证码均不为空的情况下判断输入验证码是否与生成后保存在session中的验证码相同，但比较完后并没有删除该session，导致下一个数据包输入该验证码也会判断正确，出现验证码重复使用漏洞。
0x05 测试案例
测试案例1
验证码有条件不刷新 某些时候会有这种情况：用户在登录失败后，系统会打开一个新的页面或者出现弹窗，提示用户登录失败，点击“确定”后返回登录界面，验证码也会刷新。但是这种情况下，只要我们不关闭新窗口、弹窗，直接使用BurpSuite截取登录请求包，先发送至Repeater模块，多“Go”几次，看看会不会返回“验证码错误”的提示信息，如果依旧返回“密码错误”则说明验证码不进行刷新。再将数据包发送到Intruder模块，把密码设为变量再进行MD5编码，就可直接爆破了。
不点击【确定】
多Go几次，判断验证码是否会刷新。
将密码编码，爆破。
从返回包中可以看到仍旧提示“密码错误”，验证码是不失效的。正常使用的时候，直接上弱口令字典跑就是，跟平常的爆破操作一样。（为写文章随变写了几个弱口令进行测试截图）
测试案例2
验证码识别 抓包查看此系统未采用前端校验验证码，多次刷新验证码发现验证码易识别，决定采用识别工具进行识别爆破。
右键复制验证码地址
使用Pkav工具进行验证码识别。
确认可以正常识别验证码后，对账号、密码进行爆破。
0x06 风险分析
• 在资金提现、转账、充值、修改银行卡、修改密码等的重要操作，验证码可以启到防账户盗用、篡改账户、的作用；
• 如果网站有提交表单的功能，并且需要由站点管理员审核才可通过，恶意用户会产生大量的垃圾表单，影响网站访问速度，加大工作量，且合法用户的请求有可能会因此被拒绝服务；
• 恶意用户可利用程序发送短信/邮件的功能，发送大量垃圾邮件/短信，造成短信/邮件轰炸，影响用户体验及站点短信服务过度消费；
• 通常在网站的用户注册、密码找回、登录等页面处使用验证码，但当这些验证码具有一定的规律性并且没有做好对应的防护措施时会导致攻击者通过爆破等方式猜解/绕过验证码机制，可导致任意用户注册、批量注册无用账户、重置任意用户密码、获取系统权限等危害。
• 系统易遭受DDOS攻击；
• 机器人自动批量注册；
• 对特定的注册用户用特定程序爆破方式进行不断的登录、“灌水”、“刷单”、短信/电子邮件轰炸等；
0x07 加固建议
1. 不要把验证方式置于前端，手机号和短信验证码在服务端进行唯一性绑定验证；
2. 在服务端限制短信验证码发送周期，设置时效性，限制发送次数；
3. 封禁的应该是恶意请求的手机号而不是IP地址，对一天内每一个手机号获得的验证码次数进行限制；
4. 手机验证码生成6位或者以上的数字+字母组合的验证码，并且保证用后即失效；
5. 禁止用户自定义短信内容；
6. 在服务器进行有效验证，手机号和验证码在服务器进行唯一性绑定验证等。
往期推荐
E
N
D