1. 项目概述从“靶场”到“实战”的思维跃迁很多刚入门安全测试的朋友都会从搭建各种漏洞靶场开始。Pikachu靶场以其友好的界面和清晰的漏洞分类成为了不少人的“新手村”。今天我想和你深入聊聊我在Pikachu靶场第一章节——验证码绕过练习中的一些收获。这不仅仅是完成一个“onclient”和“onserver”的练习更是一次从“照葫芦画瓢”到理解漏洞本质、建立防御思维的思维训练。验证码这个我们每天登录、注册时都会遇到的“小门槛”在安全测试者眼中却是一个充满可能性的攻击面。通过这次练习我深刻体会到绕过验证码的核心不在于记住几个工具或脚本而在于理解其背后的实现逻辑、信任边界在哪里被打破。无论是客户端onclient的“自欺欺人”还是服务端onserver的逻辑缺陷都指向了同一个问题开发者对验证码机制的安全假设过于乐观。接下来我将结合具体操作拆解这两种绕过方式的原理、实操步骤并分享一些在真实渗透测试场景中可能会遇到的变种和排查思路。2. 环境准备与靶场搭建要点在开始任何漏洞练习之前一个稳定、可控的测试环境是基石。对于Pikachu靶场虽然网上有各种一键部署的Docker镜像或安装包但我强烈建议你从源码开始手动搭建一次。这个过程本身就能让你理解其运行依赖和基本结构为后续的漏洞原理分析打下基础。2.1 本地化部署Pikachu靶场Pikachu靶场本质上是一个PHPMySQL的Web应用。最经典的部署方式是使用集成环境如PHPStudy、XAMPP或WAMP。以PHPStudy为例你需要确保其包含的PHP版本在5.4以上兼容Pikachu的要求并启用必要的扩展如mysqli。将下载的Pikachu源码包解压到PHPStudy的WWW目录下然后访问http://localhost/pikachu即可进入安装引导页面。这里有一个关键点数据库配置。Pikachu的安装程序通常会引导你创建数据库并导入初始数据。你必须确保填写的数据库连接信息主机、用户名、密码与你的MySQL服务完全匹配。我遇到过最常见的问题就是数据库连接失败八成是因为MySQL服务没启动或者用户名密码填错了。注意永远不要在公网服务器上直接部署未加任何访问控制的Pikachu或其他漏洞靶场。这些靶场本身包含漏洞暴露在公网等于给自己开了一个后门极易被恶意扫描和利用。练习环境务必放在本地虚拟机或内网中。2.2 验证码功能模块定位成功搭建后访问靶场首页。Pikachu的漏洞分类非常清晰。我们关注的“验证码绕过”位于“暴力破解”大类之下。具体路径是左侧导航栏 - 暴力破解 - 验证码绕过on client和 验证码绕过on server。这两个模块的界面几乎一模一样一个用户名输入框、一个密码输入框、一个验证码输入框以及一个动态生成的验证码图片。这种相似性恰恰是练习的精妙之处——攻击面看似相同但漏洞的根源和利用方式却天差地别。在开始测试前我习惯先用浏览器开发者工具F12分别查看两个页面的前端源码和网络请求做一个初步的“侦察”。你会发现“on client”页面的验证码校验逻辑可能直接写在了前端的JavaScript里而“on server”的页面则看起来“干净”很多这已经暗示了它们不同的防御或者说漏洞策略。3. “On Client”客户端验证码绕过信任的错觉“On Client”漏洞顾名思义其安全校验完全依赖于运行在用户浏览器中的客户端代码主要是JavaScript。这是一种非常初级且危险的设计因为它将安全的决定权交给了不可信的客户端。3.1 漏洞原理深度剖析为什么说客户端校验不可信因为用户拥有浏览器的完全控制权。开发者可能会写一段JavaScript函数在表单提交onsubmit时检查用户输入的验证码是否与页面生成的或隐藏在某个HTML元素中的验证码一致。如果一致则允许表单提交否则弹出警告并阻止提交。这个逻辑听起来没问题但问题在于这段校验代码和用于比对的“正确验证码”都暴露给了前端。攻击者可以轻易地通过浏览器开发者工具查看、修改甚至直接禁用这段JavaScript代码。更常见的是正确的验证码可能以明文形式藏在HTML的某个隐藏输入框input type“hidden”里或者作为图片的alt属性、甚至是某个变量的值。这种设计基于一个错误的假设“用户会老老实实地按照我写的流程来操作”。而安全测试的第一课就是永远不要信任客户端传来的任何数据。3.2 实操绕过步骤与工具演示我们进入Pikachu的“验证码绕过on client”页面。实际操作一遍你会看得更清楚。信息收集首先随意输入用户名、密码和验证码点击提交。此时浏览器可能会弹出“验证码错误”的提示。我们按F12打开开发者工具。代码审计切换到“Elements”或“元素”标签页审查表单元素。你可能会发现一个隐藏的input标签其name可能是“vcode”或“captcha”它的value属性值就是一串数字或字母这正是当前验证码图片对应的“正确答案”。同时查看form标签的onsubmit属性或者页面引用的JavaScript文件找到负责校验的函数。绕过操作方法有多种选择最直接的一种方法A修改前端逻辑在开发者工具的“Console”控制台中输入document.forms[0].onsubmit null;这行命令会清空表单的提交校验函数。然后你再提交就会发现验证码错误提示不再出现表单直接发往服务器。方法B篡改验证码值更常见的是在提交前通过开发者工具直接修改那个隐藏的input的value值将其改为验证码图片上显示的内容。或者更暴力地直接修改校验函数让它永远返回true。结合暴力破解这才是此漏洞的危险之处。既然验证码校验形同虚设攻击者就可以毫无阻碍地对用户名和密码进行暴力破解。我们可以使用Burp Suite的Intruder模块。首先在浏览器中配置代理指向Burp然后在Pikachu页面进行一次正常的提交此时Burp会截获请求。将截获的POST请求发送到Intruder模块。在Positions标签页将用户名和密码字段设置为攻击载荷位置而那个隐藏的验证码字段例如vcodexxxx保持原样不动。因为服务端不校验或校验逻辑有误这个固定的验证码值可以重复使用。随后在Payloads标签页加载常用的用户名和密码字典开始攻击。你会发现即使验证码图片在不断变化但由于我们每次请求都携带了第一次抓到的那个“正确”验证码值或直接删除了验证码参数攻击依然可以持续进行直至破解成功。实操心得在实际渗透测试中遇到客户端校验不要想当然认为就是“on client”漏洞。很多现代前端框架如React, Vue的校验逻辑虽然写在客户端但最终提交时服务端会进行二次校验。真正的“on client”漏洞往往出现在一些老旧系统、内部管理系统或者开发人员安全意识薄弱的场景中。判断的关键在于是否可以通过修改前端数据或逻辑直接影响到服务端的业务判断。4. “On Server”服务端验证码绕过逻辑的陷阱服务端验证码校验是正确的方式但实现不当同样会导致绕过。Pikachu的“on server”模块模拟的就是一种经典的逻辑缺陷。4.1 漏洞原理会话与验证码的绑定失效一个安全的服务端验证码流程应该是1. 服务器生成一个随机验证码字符串。2. 将该字符串存入服务器会话Session中同时生成图片返回给客户端。3. 用户提交表单时服务器比对用户输入的验证码和Session中存储的是否一致。4.无论比对成功与否服务器都应立即使当前Session中的验证码失效即使用一次后立即作废以防止“重放攻击”。Pikachu “on server”模块的漏洞就在于缺失了第4步或者存在其他逻辑错误。常见的有以下几种情况验证码永不过期Session中的验证码在被使用后没有被清除或标记为已使用。导致同一个验证码可以被重复使用多次。验证码与用户会话绑定错误验证码没有和具体的用户会话或请求绑定。例如验证码可能存储在全局变量、数据库或文件中并且没有与当前登录尝试进行强关联导致A用户生成的验证码可能被B用户使用。验证码校验后逻辑分支处理不当服务器校验验证码正确后直接进入了处理用户名密码的流程但并没有在验证码校验通过后立即将其销毁。如果在处理密码校验可能涉及数据库查询耗时较长时攻击者并发地发起另一个请求这个请求可能仍然能通过验证码检查。4.2 实操绕过利用逻辑缺陷进行重放我们进入“验证码绕过on server”页面。这次前端看起来没有隐藏的验证码字段了。测试验证码是否一次性首先我们手动操作输入正确的用户名admin、错误的密码以及图片上的正确验证码点击提交。服务器返回“用户名或密码错误”。关键步骤来了我们不刷新页面此时验证码图片还是旧的。我们使用相同的用户名、另一个错误密码再次输入同一个验证码图片上显示的旧验证码提交。如果服务器再次返回“用户名或密码错误”而不是“验证码错误”那么基本可以断定这个验证码被重复使用了即存在“重放”漏洞。使用Burp Suite进行自动化测试和之前一样配置代理在浏览器提交一次请求让Burp截获。将这个POST请求发送到Burp的Repeater模块。Repeater允许我们手动修改并重复发送同一个请求。在Repeater中我们保持captcha参数不变即第一次获取的正确验证码然后遍历修改username和password参数模拟暴力破解。每次修改后点击“Send”观察响应。如果对于不同的密码尝试服务器只提示密码错误而不提示验证码错误那么漏洞利用就成功了。更高级的并发绕过想象在一些更复杂的场景中验证码可能在校验成功后需要一小段时间才会被服务器清除。攻击者可以利用这个时间窗口编写脚本同时发起大量请求这些请求都使用同一个刚刚验证成功的验证码进行密码爆破。这就是所谓的“竞争条件”漏洞的一种体现。注意事项在测试“on server”漏洞时浏览器的Cookie尤其是PHPSESSID至关重要因为它维系着你和服务器之间的会话。在Burp Suite的Repeater或Intruder中操作时务必确保每次请求都携带了浏览器中当前有效的会话Cookie。如果会话过期你需要重新从浏览器获取一个新的请求包。5. 漏洞修复与安全开发建议理解了如何绕过才能更好地进行防御。针对这两类漏洞修复思路是截然不同的。5.1 根治客户端校验漏洞对于“on client”漏洞修复方案非常简单粗暴彻底删除所有用于安全决策的客户端校验逻辑。前端可以进行验证码格式检查如是否为4位数字但这仅仅是为了提升用户体验和减少无效请求绝不能作为安全凭据。所有关于验证码是否正确的判断必须放在服务端使用服务器生成的Session进行比对。同时确保验证码答案没有以任何形式隐藏域、JSON、注释等泄露在前端代码中。5.2 加固服务端验证码逻辑对于“on server”漏洞修复的核心原则是确保验证码的一次性、会话绑定性和即时失效性。一次性使用在服务器端一旦验证码被提交并参与了一次校验无论对错应立即从Session中清除该验证码值。通常是在校验代码之后立刻执行unset($_SESSION[‘captcha’])PHP示例。增强会话绑定生成验证码时可以将其与一个唯一的令牌Token或当前会话ID进行关联存储。校验时不仅要核对验证码内容还要核对关联关系。设置较短的有效期除了使用后立即销毁还可以为验证码设置一个绝对的有效期如2分钟。即使未被使用超过时间后自动失效。防御竞争条件在处理验证码校验的整个关键逻辑段读取Session、比对、清除Session可以考虑使用锁机制确保同一会话的验证码校验请求是串行处理的避免并发请求导致的状态混乱。增加复杂度使用安全的随机数生成器生成验证码避免使用易猜测的规律如递增数字。图形验证码应加入足够的干扰元素防止OCR识别。6. 从靶场到实战的思考延伸Pikachu的练习是一个理想的起点但真实世界的验证码绕过要复杂得多。验证码类型多样化除了简单的图形数字字母还有滑动拼图、点选文字、短信/邮件验证码等。每种类型都有其独特的攻击面例如短信验证码可能面临“短信轰炸”滥用接口耗尽用户费用或骚扰和“接口滥用”绕过次数限制的风险。自动化工具与AI对于图形验证码攻击者会使用打码平台人工识别或基于机器学习的OCR工具进行自动化识别。这就要求我们的验证码必须具备足够的抗识别能力。业务逻辑耦合验证码往往不是孤立的它和注册、登录、密码找回、支付等关键业务绑定。需要思考验证码在哪个环节触发触发频率是否有限制验证码失败后的流程是怎样的是否存在“万能验证码”或后门逻辑如输入特定字符串可通过这些都需要在安全测试中通过代码审计和模糊测试来发现。全链条安全一个安全的验证码系统需要从前端生成、网络传输、服务端校验、会话管理到最终销毁每一个环节都做好防护。安全是一个链条最薄弱的一环决定了整体的强度。完成Pikachu的这两个练习真正的收获不是学会了两个攻击技巧而是建立起一种“怀疑”和“追溯”的思维模式。看到验证码你会本能地去想“它的校验点在哪里数据流是怎样的状态如何管理哪里可能被突破” 这种思维才是安全测试中最宝贵的财富。