1. 验证码绕过的核心逻辑与攻防视角验证码全称“全自动区分计算机和人类的公开图灵测试”它的设计初衷是构建一道人机边界。在Web渗透测试中验证码绕过是一个绕不开的经典课题。它考验的不仅是攻击者的技术栈深度更是对目标系统业务逻辑、安全机制设计缺陷的洞察力。很多开发者和初级安全工程师会认为只要部署了验证码就能高枕无忧地防御自动化攻击这其实是一个巨大的误区。验证码本身并非铜墙铁壁它更像是一把锁而渗透测试者的工作就是找出这把锁的钥匙或者干脆证明这扇门压根没锁。从攻防对抗的视角来看验证码绕过技术主要沿着两条主线演进一是针对验证码生成与校验逻辑的缺陷进行利用二是利用技术手段模拟或绕过“人类交互”这一核心环节。前者属于逻辑漏洞的范畴比如验证码在客户端生成、验证码可重复使用、验证码与Session绑定不严等后者则更偏向于技术对抗例如利用OCR识别、机器学习模型破解图形验证码或者通过自动化工具操控浏览器、模拟鼠标轨迹来欺骗行为验证码。理解这两条主线是系统掌握验证码绕过技术的前提。在实际的渗透测试项目中验证码绕过往往是突破登录、注册、密码找回、短信轰炸防护等关键业务接口的“临门一脚”。它很少作为一个独立目标存在而是作为后续漏洞利用如撞库、批量注册、敏感信息枚举的铺垫。因此掌握验证码绕过意味着你具备了撕开目标系统第一道自动化防御防线的能力其战术价值不言而喻。2. 验证码的常见类型与安全假设剖析在尝试绕过之前我们必须先了解对手。现代Web应用中的验证码形态多样其安全假设也各不相同。2.1 传统图形验证码扭曲文本、数字计算这是最古老的形态通常由扭曲、粘连、带有干扰线和背景噪点的字母数字组合图片构成。安全假设计算机程序OCR难以准确识别经过扭曲和干扰的字符而人类可以。常见缺陷复杂度恒定且过低字符集小如仅数字、字符数固定如4位、扭曲和干扰算法简单且一成不变。这使得训练一个专用的OCR模型或使用现成的OCR引擎如Tesseract配合图像预处理成功率很高。验证码答案存在于前端最致命的低级错误。验证码的正确答案以明文或简单编码如Base64的形式隐藏在HTML源码、Cookie或前端JavaScript变量中。攻击者无需识别直接提取即可。验证码与用户会话Session未强绑定服务器端生成验证码后没有将其与当前用户的会话ID严格关联并校验。导致攻击者可以使用自己获取的一个有效验证码为其他任意用户的请求“背书”。验证码无使用次数或时效限制同一个验证码可以无限次使用或者在很长一段时间内如10分钟有效。攻击者识别一次即可在有效期内进行无限次重放攻击。2.2 行为验证码滑动拼图、点选文字、智能验证如极验、腾讯云验证码等通过要求用户完成一个简单的交互行为来验证。安全假设自动化脚本难以模拟人类在完成拖动、点选等操作时的连续轨迹、加速度曲线、随机停顿等生物特征。常见缺陷轨迹验证可被模拟虽然检测鼠标轨迹但很多实现仅做简单校验如拖动速度是否均匀。通过研究人类行为轨迹特征使用Selenium、Playwright等自动化工具记录并回放或使用算法生成符合正态分布的移动轨迹可以成功模拟。后端验证逻辑绕过这是最高效的绕过方式。通过抓包分析发现完成验证后前端仅向后台提交一个由前端生成的“验证通过令牌”Token。如果这个Token的生成算法被逆向或者服务器仅校验Token是否存在及格式而不校验其与本次验证会话的关联性和唯一性那么攻击者就可以直接伪造或重放有效的Token。验证参数可预测例如滑动拼图缺口位置所需的滑动距离可能由前端某个参数如图片宽度、缺口位置坐标简单计算得出而这个参数可能未加密或可被轻易推算。2.3 短信/邮箱验证码常用于注册、登录、敏感操作确认。它本身不是“图灵测试”但其“一次性”和“时效性”是核心安全属性。安全假设验证码通过安全通道短信/邮件发送到用户绑定的私有设备且一次性有效、短时失效。常见缺陷验证码位数少、纯数字、无频率限制这是导致“短信轰炸”和“验证码爆破”的根源。攻击者可以编写脚本遍历所有可能的验证码组合如6位数字共100万种可能在验证码失效前进行暴力枚举。如果接口没有请求频率限制攻击速度会非常快。验证码全局有效而非绑定会话服务器校验验证码时只检查提交的验证码是否在系统当前生成的“有效验证码池”中而没有检查这个验证码是否是发给当前这个会话/手机号/邮箱的。导致攻击者可以收集或预测一个有效的通用验证码有时系统存在默认或测试用的万能验证码如“000000”用于攻击任何账户。验证码在响应中泄露非常低级的错误。在发送验证码的API接口响应中直接将验证码明文返回。或者在验证过程的调试信息、错误日志中泄露。注意在渗透测试中针对短信/邮箱验证码的测试必须格外谨慎严格遵守授权范围。无限制的爆破或轰炸测试可能对目标业务造成实际影响产生费用、骚扰用户甚至可能触犯法律。务必在测试前与客户明确规则或在隔离的测试环境中进行。3. 手工测试与逻辑漏洞挖掘实战自动化工具很强大但手工测试往往是发现逻辑漏洞的钥匙。以下是我在实战中总结的一套手工测试流程和关注点。3.1 信息收集与前端代码审计首先打开浏览器的开发者工具F12。网络Network标签页清空记录触发一次验证码获取和提交。仔细观察所有相关的HTTP请求。获取验证码的请求URL是什么是GET还是POST请求参数有哪些响应体是什么响应头里有没有隐藏信息特别注意响应体里是否直接包含了验证码的答案明文或编码。提交验证码的请求提交了哪些参数除了输入的验证码是否还有captcha_id、token、session_key等其他标识这些参数从哪里来通常来自获取验证码时的响应。元素Elements标签页查看验证码图片的img标签。它的src属性是什么是直接指向一个生成图片的PHP/ASPX文件还是一个带有参数的动态链接尝试单独访问这个src链接看是否能直接下载到验证码图片并且多次刷新该链接观察验证码是否变化。源代码Sources与控制台Console搜索与验证码相关的关键词如captcha、code、verify、token。查看前端JavaScript文件中是否硬编码了验证码逻辑或者将验证码答案存储在某个变量里。实操心得我曾遇到一个案例验证码图片的URL是/captcha.php?codeabc123。参数code的值abc123就是本次验证码的答案。服务器生成图片时将abc123渲染成图片但校验时却用客户端提交的code参数值与abc123比较。这意味着攻击者根本不需要识别图片直接从URL里就能拿到答案。这种漏洞的发现完全依赖于对请求URL的细心观察。3.2 会话与状态管理测试验证码必须与一次特定的会话绑定。测试其绑定是否牢固。跨会话使用在浏览器A中打开页面获取验证码X。不要提交。新开一个无痕浏览器浏览器B访问同一页面获取验证码Y。回到浏览器A提交验证码Y来自B的。如果成功说明验证码是全局池未与会话绑定。重复使用重放攻击获取一个验证码正确提交一次使该次验证成功。然后使用同一个验证码和相同的会话再次提交。如果第二次也成功说明验证码在使用后没有被标记为“已使用”可以重放。多用户共用用户A获取验证码1234。用户B在另一个会话中提交验证码1234假设通过某种途径知道了这个码。如果B也验证成功说明验证码在生成后与特定用户身份没有强关联。排查技巧这类测试的关键在于控制变量。使用Burp Suite的Repeater模块会非常方便。你可以捕获一个包含验证码的请求然后在Repeater中修改会话Cookie、验证码参数等反复发送观察响应差异。务必记录每次请求的Cookie、Captcha-Code、Token等所有可能的状态标识。3.3 验证码自身缺陷测试复杂度分析如果验证码是4位纯数字其熵值极低仅10^410000种可能。即使有时效限制如60秒如果接口没有速率限制理论上可以进行暴力破解。万能验证码在测试环境或者某些开发粗心的生产系统中可能存在用于测试的万能验证码。尝试诸如0000、8888、test、admin、bypass等常见测试码。空值绕过提交表单时将验证码参数置空captcha或者直接删除这个参数看服务器是否因为逻辑不严谨而跳过检查。大小写与去空格对于字母验证码服务器校验时是否做了大小写统一处理如果没做输入正确但大小写错误的验证码会失败。反之如果做了tolowercase()处理那么攻击者识别时也只需识别小写字母降低了难度。同样检查服务器是否会去除用户输入的首尾空格。4. 自动化识别与模拟技术解析当逻辑漏洞不存在或难以发现时我们就需要与技术硬碰硬实现自动化识别或模拟。4.1 图形验证码的自动化识别流程一个完整的自动化识别流程通常包括下载图片、预处理、识别、提交。图片获取使用脚本Python的requests库模拟请求获取验证码图片。这里的关键是维持会话。你需要使用requests.Session()对象确保获取验证码和提交验证码使用的是同一个会话从而携带相同的Cookies。import requests session requests.Session() # 首先可能需要访问首页获取初始Cookie session.get(https://target.com/login) # 获取验证码图片 captcha_resp session.get(https://target.com/captcha.jpg) with open(captcha.png, wb) as f: f.write(captcha_resp.content)图片预处理原始验证码图片往往噪声多直接识别率低。预处理目的是增强字符特征抑制背景干扰。常用操作使用OpenCV或PIL二值化将彩色图转为黑白明确前景字符和背景。关键是选择一个合适的阈值。去噪去除孤立的像素点椒盐噪声和细小的干扰线。可以使用中值滤波、腐蚀膨胀等形态学操作。字符分割如果字符粘连不严重可以通过投影法垂直投影找列间隙或连通域分析将单个字符切割出来有利于提高识别精度。识别引擎Tesseract OCR开源神器。但对付扭曲验证码效果一般需要配合良好的预处理和自定义训练。命令简单pytesseract.image_to_string(processed_image, config--psm 7)。--psm 7表示将图像视为单行文本。深度学习模型针对特定目标网站收集数百至数千张验证码图片手动打标签训练一个卷积神经网络CNN。这是最强大但成本最高的方法。可以使用TensorFlow或PyTorch框架。对于固定样式的验证码准确率可达95%以上。第三方打码平台如联众、云打码等。将图片发送到平台API付费返回识别结果。优点是省事识别率高背后是人工或高级AI适合商业化的渗透测试或批量作业但会产生费用且依赖外部服务。注意事项预处理没有银弹。你需要针对目标验证码的特点调整预处理流程。例如干扰线是彩色的可以考虑先转换到HSV色彩空间根据颜色过滤掉干扰线如果背景是密集的噪点可能需要使用更激进的高斯模糊后再二值化。这个过程需要反复试验和调整参数。4.2 行为验证码的自动化模拟以最常见的滑动验证码为例。轨迹分析首先你需要手动完成几次滑动并用工具记录下鼠标的移动轨迹。分析轨迹特点通常不是匀速直线而是“先快后慢”在接近缺口时有一个细微的调整甚至小回弹。轨迹数据是一系列(x, y, timestamp)坐标。轨迹生成与模拟你不能直接回放录制的轨迹因为每次缺口位置都不同。你需要计算需要滑动的总距离。距离计算通过对比有缺口图和无缺口图通常无缺口图作为背景图隐藏在页面元素中使用图像模板匹配算法如OpenCV的matchTemplate找出缺口位置从而计算出滑动距离。轨迹生成根据总距离生成一条符合人类特征的移动轨迹。一个简单的模拟算法是将移动过程分为加速、匀速、减速三个阶段用匀变速运动公式生成位移曲线再叠加一个小的随机抖动。代码上可以通过Selenium的ActionChains来模拟。from selenium.webdriver import ActionChains import time, random def generate_track(distance): 生成滑动轨迹 track [] current 0 mid distance * 4 / 5 # 减速点 t 0.2 # 时间间隔 v 0 while current distance: if current mid: a 2 random.random() # 加速段加速度 else: a -3 - random.random() # 减速段加速度 v0 v v v0 a * t move v0 * t 0.5 * a * t * t current move track.append(round(move)) # 微调确保总距离准确 track.append(distance - sum(track)) return track # 使用Selenium操作 slider driver.find_element_by_css_selector(.slider) # 滑块元素 ActionChains(driver).click_and_hold(slider).perform() for x in generate_track(calculated_distance): ActionChains(driver).move_by_offset(xoffsetx, yoffset0).perform() time.sleep(random.uniform(0.001, 0.005)) # 随机间隔更像人类 ActionChains(driver).release().perform()绕过Token校验这是更高级的绕过。使用抓包工具如Burp Suite、Charles拦截整个验证过程。重点关注滑动验证成功后前端向哪个接口提交了哪些参数。通常会有一个validate接口提交一个token和challenge等参数。你的目标是重放攻击记录一次成功验证的token尝试在另一个会话中直接提交这个token。如果成功说明token未绑定会话或时效过长。参数分析研究token的生成规律。它可能是一个Base64编码的JSON字符串解密后包含时间戳、滑动距离、轨迹哈希等。如果算法简单且密钥硬编码在前端就有可能被逆向并伪造。5. 工具链集成与实战工作流单点技术需要整合到流畅的渗透测试工作流中才能发挥最大效力。我通常将验证码绕过分为“侦察”、“测试”、“集成”三个阶段。5.1 侦察阶段手工与半自动化信息收集此阶段目标是快速判断验证码的强度类型和潜在弱点。浏览器插件辅助使用EditThisCookie等插件快速查看和修改Cookie配合开发者工具快速测试会话绑定问题。Burp Suite 主动扫描与插件Active Scan对登录接口进行主动扫描有时能发现“验证码可重复使用”这类逻辑漏洞。插件生态Captcha Killer插件可以集成打码平台API在Burp中实现自动识别并替换验证码参数极大提升Intruder爆破的效率。Autorize插件可用于测试权限问题但有时也能间接发现验证码校验绕过。编写快速探测脚本针对目标写一个简单的Python脚本自动完成“获取验证码-保存图片-尝试空/万能码提交”的流程并输出结果。这个脚本不追求高识别率只求快速发现低级漏洞。5.2 测试阶段针对性工具开发与调试当侦察发现需要技术对抗时进入本阶段。搭建识别环境安装Tesseract OCR并配置环境变量。安装Python的pytesseract、opencv-python、Pillow库。针对目标验证码编写预处理和识别函数。构建模拟浏览器环境使用Selenium或Playwright驱动Chrome/Firefox。Playwright在抗检测方面通常更强因为它可以更真实地模拟浏览器指纹。重点配置好headlessFalse模式用于调试观察自动化操作是否被检测到。调试与优化这是最耗时的一步。你需要不断调整预处理参数、识别后的后处理规则如纠正常见误识别或者优化模拟轨迹的算法。记录每次尝试的成功率直到达到一个可接受的稳定水平例如70%。5.3 集成阶段融入自动化攻击框架将调试成功的绕过模块集成到整体的攻击流程中。例如你要进行批量撞库攻击。流程设计脚本启动 - 访问登录页 - 获取验证码 - 识别/绕过验证码 - 携带识别结果和账号密码发起登录请求 - 分析响应判断成功与否 - 循环。会话管理必须确保整个流程在一个持久化的会话中进行。所有请求要使用同一个requests.Session()或浏览器实例。错误处理与重试验证码识别不可能100%成功。代码中必须加入健壮的错误处理和重试机制。例如识别失败或登录返回“验证码错误”时自动清空会话重新开始“获取-识别-提交”流程。速率控制即使绕过验证码也要模拟人类操作频率添加随机延迟time.sleep(random.uniform(1, 3))避免触发基于请求频率的二次风控。常见问题实录问题使用Selenium时被网站检测到WebDriver属性。解决使用undetected-chromedriver库或者通过ChromeOptions添加excludeSwitches和addArguments参数来隐藏WebDriver特征。from selenium.webdriver import ChromeOptions options ChromeOptions() options.add_argument(--disable-blink-featuresAutomationControlled) options.add_experimental_option(excludeSwitches, [enable-automation]) options.add_experimental_option(useAutomationExtension, False)问题验证码识别率始终很低。解决放弃通用OCR转向收集数据训练专用模型。即使只收集200张图片训练一个小型CNN模型其效果也远胜于调参后的Tesseract。可以使用在线标注工具快速标注用keras或fastai快速搭建和训练模型。问题滑动验证码的缺口距离计算不准。解决模板匹配对噪声和变形敏感。尝试更鲁棒的图像识别方法如使用SIFT或ORB特征匹配或者直接使用深度学习目标检测模型如YOLO来定位缺口。另一种思路是如果缺口位置是固定的几种可能例如基于前端图片宽度百分比计算可以枚举尝试。6. 防御视角与安全开发建议作为渗透测试者我们挖掘漏洞的最终目的是为了帮助修复。从防御者角度看一个健壮的验证码系统应具备以下特征后端生成后端校验验证码的答案必须仅在服务器端内存中生成和存储绝对不能在网络传输或前端代码中泄露。强会话绑定生成的验证码必须与当前用户的会话IDSession ID进行强关联。校验时必须核对提交的验证码是否与当前会话中存储的一致。一次性与短时效验证码一旦被成功验证应立即从服务器端失效。同时即使未被使用也应在生成后60-120秒内过期。增加熵值与干扰使用足够长度的混合字符大小写字母数字应用随机且复杂的扭曲、粘连、干扰线算法。避免使用固定的字体和背景。行为验证码的多维度风控不仅校验最终结果Token还要在后台分析整个交互过程鼠标移动轨迹的加速度、角速度是否符合人类特征整个验证耗时是否在合理范围内本次验证会话的上下文IP、User-Agent、浏览器指纹是否异常安全的短信/邮箱验证码位数与复杂度至少6位推荐数字字母。频率限制对同一手机号/邮箱在单位时间内如1分钟发送次数进行严格限制如1次。对同一IP的发送请求也做频率限制。验证失败锁定连续输入错误超过一定次数如5次应临时锁定该账号或该会话的验证功能一段时间。业务关联发送和校验时必须验证手机号/邮箱与当前要操作的业务登录、注册是否匹配。监控与告警对验证码相关的接口获取、校验建立监控。异常频率的请求、极高的错误率、来自同一源的批量验证成功都应及时触发安全告警。验证码绕过是一场持续的道高一尺魔高一丈的对抗。作为安全从业者我们既要掌握“魔”的利刃用以揭示风险更要理解“道”的坚盾用以构建更安全的体系。真正的安全不在于设置一道无法逾越的墙而在于建立一套能够持续感知风险、快速响应攻击的动态防御体系。验证码只是这个体系中的一个环节它的有效性永远取决于其背后逻辑的严谨性以及对“人机边界”这一核心问题的深刻理解。