1. 从验证码拦路说起为什么暴力破解值得单独拎出来练很多人第一次接触 pikachu 靶场都是冲着 SQL 注入和 XSS 去的暴力破解这一关往往被当成送分题草草跳过。但真到了实际项目里你会发现登录接口才是攻击面最集中的地方——验证码、Token、登录失败锁定、频率限制一层套一层。pikachu 的暴力破解模块之所以经典就是因为它把这几层防护拆成了递进的几个关卡让你能一层一层地理解防护是怎么被绕过的而不是一上来就面对一个综合防御体系。这篇文章面向的是刚打完 pikachu 基础关卡、想真正搞懂验证码和 Token 到底防住了什么、又漏在哪的安全学习者。我会从最裸奔的登录表单开始一路讲到带 Token 防护的场景把 Burp Suite 的 Intruder 模块、验证码的几种处理思路、Token 的提取与回填逻辑全部拆开讲。中间会穿插我自己踩过的坑比如 Intruder 跑了几千次请求结果全是 200 但没一个登录成功、比如 Token 每次请求都变导致 payload 对不上——这些问题在教程里通常一笔带过但实际操作时能耗掉你一下午。需要先明确一点本文所有操作都在本地搭建的 pikachu 靶场环境中进行目的是理解防护机制的薄弱点从而在开发时写出更靠谱的登录逻辑。任何针对非授权系统的测试都是违规的这个边界必须守住。pikachu 的暴力破解关卡通常分为三到四个递进难度无任何防护的纯表单、带验证码的表单、带 Token 的表单、以及 Token 加验证码的组合。每一关的绕过思路完全不同下面逐个拆。2. 第一关裸奔登录表单的爆破节奏控制2.1 先看清请求长什么样打开 pikachu 暴力破解的第一关页面就是一个普通的用户名密码登录框。这时候别急着开 Burp先做一件事手动提交一次错误的账号密码然后在 Burp 的 Proxy History 里找到这个 POST 请求。典型的请求体长这样usernameadminpassword123456submitLogin响应里通常会有一句username or password is not exists之类的提示。这句话就是爆破的信号灯——只要响应内容和成功登录时不一样Intruder 就能靠它来判断哪次尝试成功了。这里有个新手常犯的错误不手动提交就直接开 Intruder结果连请求里有哪些参数都没搞清楚payload 位置设错了跑半天全是无效请求。先手动走一遍完整流程再上自动化工具这个习惯能帮你省掉大量排查时间。2.2 Intruder 的四种攻击类型怎么选Burp Intruder 有四种攻击类型很多人只知道 Sniper其实选对类型能大幅提升效率攻击类型适用场景pikachu 暴力破解中的用法Sniper单个参数位置逐个替换已知用户名只爆破密码Battering ram多个位置用同一个 payload用户名密码相同的情况很少用Pitchfork多个位置各自独立字典一一对应用户名和密码有对应关系时用Cluster bomb多个位置字典交叉组合用户名和密码都未知全组合爆破pikachu 第一关通常是已知用户名 admin、未知密码所以用Sniper就够了。把 payload 位置设在 password 的值上加载一个常见密码字典比如 rockyou.txt 的前几千条或者自己整理的弱口令列表线程数设成 1 到 5 之间。2.3 线程数不是越大越好这里要重点说一下线程数。很多人觉得线程拉满跑得快但在本地靶场环境下线程数过高会导致请求丢失、响应错乱甚至把靶场的 Web 服务打挂。我一般设单线程或 3 线程配合 Grep-Match 功能标记响应中的关键字。具体操作在 Intruder 的 Options 标签里找到 Grep-Match添加login success或者成功后才出现的字符串。这样跑完之后结果列表里命中关键字的请求会被高亮一眼就能看出哪条成功了。提示如果响应长度差异明显也可以用 Grep-Extract 提取响应长度按长度排序找异常值。但关键字匹配更直观优先用这个。2.4 字典的选择比工具更重要工具再顺手字典不行也是白搭。pikachu 这种教学靶场密码通常就在常见弱口令列表里比如 123456、password、admin888 这类。但实际场景中字典要结合目标的信息来定制——比如目标公司名、域名、常见年份组合。我自己的习惯是准备三层字典第一层是几十条的超弱口令快速试第二层是几千条的常见密码第三层是结合目标信息生成的定制字典。pikachu 第一关用第一层就够了几秒钟出结果。3. 第二关验证码不是万能盾先搞懂它防的是什么3.1 验证码的三种失效姿势到了第二关登录框多了一个图形验证码。很多人第一反应是完了爆破不了了。但验证码的防护效果取决于它的实现方式常见的失效姿势有三种第一种是验证码不刷新。你提交一次错误密码后验证码图片没变还是原来那个。这种情况下你只要识别一次验证码然后固定这个值反复提交就行。第二种是验证码可复用。服务端校验完验证码后没有立即销毁 session 里的值导致同一个验证码能通过多次校验。这种在早期系统里很常见。第三种是验证码与请求分离。验证码的校验逻辑和登录逻辑不在同一个请求里处理导致你可以先获取一个验证码然后用它去跑密码字典。pikachu 第二关通常是第一种或第二种具体要看版本。判断方法很简单手动提交两次错误密码观察验证码图片是否变化。如果两次的验证码一样那就是不刷新如果变了但你能用同一个验证码连续提交多次成功那就是可复用。3.2 Burp 里的验证码处理实操假设验证码不刷新操作流程是这样的在浏览器里打开登录页让验证码显示出来但不要提交。在 Burp 里拦截这个 GET 请求获取验证码图片的请求记下 session 对应的验证码值。如果靶场把验证码明文存在 cookie 或隐藏字段里直接读出来就行。手动识别验证码图片上的字符pikachu 的验证码通常很简单四位数字或字母。构造 POST 请求把验证码字段固定成识别出的值密码字段设为 payload 位置。在 Intruder 里跑字典。如果验证码是明文存在响应里的有些靶场为了教学方便会这么做那就更简单了——用 Grep-Extract 把验证码提取出来然后在 Payload 里用递归提取的方式动态填充。不过 pikachu 一般不会这么送通常需要你手动识别一次。3.3 验证码识别的几条路如果验证码每次请求都变那就需要识别这一步。常见思路有手动识别适合验证码数量少的情况。用 Burp 的 Intruder 配合宏Macro每次请求前先获取新验证码人工识别后填入。效率低但准确率高。OCR 自动识别用 Python 的 ddddocr 库对简单图形验证码的识别率相当高。流程是请求验证码图片 → 保存到本地 → ddddocr 识别 → 把结果填入登录请求。打码平台实际项目中会用但学习和靶场环境没必要成本高且涉及外部服务。对于 pikachu 靶场我推荐用ddddocr写个小脚本因为它的验证码足够简单识别率接近 100%。脚本逻辑大致是import ddddocr import requests ocr ddddocr.DdddOcr() session requests.Session() # 获取验证码 img_resp session.get(http://靶场地址/pikachu/vul/burteforce/bf_form.php) with open(captcha.png, wb) as f: f.write(img_resp.content) # 识别 with open(captcha.png, rb) as f: code ocr.classification(f.read()) # 提交登录 data {username: admin, password: 123456, vcode: code, submit: Login} resp session.post(http://靶场地址/pikachu/vul/burteforce/bf_form.php, datadata) print(resp.text)这个脚本跑通之后把它嵌到爆破循环里每次请求前重新获取并识别验证码就能绕过验证码每次刷新的防护。注意ddddocr 的安装依赖 onnxruntimeWindows 下直接 pip install ddddocr 即可Linux 下可能需要额外装一些系统库。如果识别率不理想可以先用 PIL 对图片做二值化、去噪处理再喂给 OCR。3.4 一个容易忽略的点验证码的 session 绑定有些实现会把验证码和当前 session 绑定你换了 session 验证码就失效。这时候用 requests.Session() 保持会话就很重要。如果你用 Burp 的 Intruder要确保请求里的 Cookie 和获取验证码时的 Cookie 一致否则服务端会认为验证码无效。我在这一关卡过一次用脚本获取验证码时用的是 session A提交登录时不小心用了新的 session B结果验证码永远校验失败。排查了半天才发现是 Cookie 没对上。验证码和 session 的绑定关系是排查验证码类问题的第一检查项。4. 第三关Token 防护的提取与回填逻辑4.1 Token 到底防住了什么Token 防护的核心思路是每次请求都带一个服务端生成的、一次性的令牌服务端校验这个令牌是否有效且未被使用过。这样即使攻击者截获了请求也无法重放因为令牌已经失效了。在 pikachu 的 Token 关卡里登录表单里会多一个隐藏字段比如input typehidden nametoken valuea1b2c3d4e5f6这个 token 每次刷新页面都会变。如果你直接拿一个固定的 token 去跑字典第一次请求之后 token 就失效了后续请求全部失败。4.2 用 Burp 宏自动提取 TokenBurp 提供了 Macro宏功能可以在每次请求前自动执行一系列操作包括获取新 token 并提取出来。配置步骤如下在 Burp 的 Settings → Sessions → Macros 里新建一个宏。宏的步骤设为请求登录页面 → 从响应中提取 token 值。在提取规则里用正则匹配nametoken value([^])把捕获组设为变量csrf_token。回到 Intruder 的 Options → Sessions启用宏并设置每次请求前运行宏。在请求的 token 字段值里用%csrf_token%引用宏提取的变量。这样每次 Intruder 发请求前都会先跑一遍宏拿到新 token再填入登录请求。配置正确的话爆破就能正常进行。这里有个细节宏提取 token 的请求和登录请求必须是同一个 session。Burp 的 Session Handling Rules 里要确保 Cookie 一致否则服务端返回的 token 和登录时用的 session 对不上校验照样失败。4.3 脚本方案requests 里的 Token 处理如果不想折腾 Burp 的宏用 Python 脚本更直观import requests import re session requests.Session() url http://靶场地址/pikachu/vul/burteforce/bf_token.php # 先获取页面提取 token resp session.get(url) token re.search(rnametoken value([^]), resp.text).group(1) # 用提取的 token 提交登录 data {username: admin, password: 123456, token: token, submit: Login} resp session.post(url, datadata) print(resp.text)把这个逻辑放进循环里每次请求前重新获取 token就能绕过 Token 防护。关键点是每次都要重新 GET 页面拿新 token不能复用。4.4 Token 和验证码同时存在怎么办pikachu 的高难度关卡会把 Token 和验证码叠在一起。这时候你的脚本需要同时处理两件事获取新 token、识别新验证码。流程变成GET 登录页 → 提取 token、下载验证码图片。OCR 识别验证码。POST 登录请求带上 token 和验证码。判断响应如果失败则回到第 1 步。这个循环里任何一步出错都会导致失败。常见的坑包括token 提取的正则写错、验证码识别错误、session 中途丢失。建议在脚本里加日志把每次的 token 和验证码值打印出来方便排查。5. 那些教程不会告诉你的排查经验5.1 响应全是 200 但没成功先看这三处爆破跑完结果列表里所有请求的响应码都是 200但没有任何一条显示登录成功。这种情况我遇到过好几次排查下来通常是三个原因第一payload 位置设错了。比如把 payload 设在了 username 上而不是 password 上或者设在了 submit 按钮的值上。检查方法是看 Intruder 的请求预览确认§符号包住的是你要爆破的字段。第二Grep-Match 关键字写错了。成功登录后的响应里可能包含welcome或login success但你匹配的是success而实际响应里是successful差一个字母就匹配不上。解决办法是手动登录一次把成功响应的原文复制出来从中提取准确的关键字。第三请求缺少必要字段。有些表单除了 username、password、token 之外还有隐藏的 submit 字段或其他参数漏掉任何一个都可能导致服务端拒绝处理。对比手动提交的请求和 Intruder 里的请求逐字段核对。5.2 线程数和请求间隔的平衡本地靶场环境下我建议线程数不超过 5请求间隔设 0 到 100 毫秒。线程太高会导致两个问题一是靶场的 PHP 服务处理不过来返回 502 或超时二是某些防护逻辑会检测高频请求直接封 IP 或返回假响应。如果你发现跑了一部分请求后突然全部失败先检查是不是被限流了。把线程降到 1间隔加到 500 毫秒重新跑一遍看看。5.3 字典编码和特殊字符的坑密码字典里如果包含特殊字符比如、、%在 URL 编码或表单提交时可能被转义导致实际提交的密码和你字典里的不一致。Burp 的 Intruder 默认会对 payload 做 URL 编码但有些情况下需要手动调整。比如密码是password如果不编码直接提交服务端可能把当成参数分隔符实际收到的密码是pass。解决办法是在 Payloads 设置里勾选URL-encode these characters把、、%等字符加进去。5.4 成功之后的验证不能省Intruder 标记出某条请求成功了别急着下结论。手动用那组账号密码登录一次确认真的能进。有时候 Grep-Match 匹配到的只是响应里的巧合字符串实际并没有登录成功。自动化工具的判断结果永远要用人工验证兜底。6. 从靶场到开发这些防护该怎么写才对打完 pikachu 的暴力破解关卡最有价值的不是我学会了爆破而是我知道这些防护为什么会被绕过所以我开发时不会这么写。验证码方面正确的做法是每次校验后立即销毁 session 里的验证码值无论校验成功还是失败验证码与 session 严格绑定对同一 session 的验证码错误次数做限制超过阈值就强制刷新或锁定。Token 方面正确的做法是token 一次性使用校验后立即失效token 与用户 session 绑定token 生成用足够随机的源避免可预测。频率限制方面正确的做法是对同一 IP、同一账号的登录失败次数做计数超过阈值后增加延迟或临时锁定锁定策略要有梯度不能简单粗暴地永久封禁否则容易被用来做拒绝服务。这些防护单独用都有绕过方法但组合起来、再加上合理的阈值和监控就能把暴力破解的成本拉到很高。pikachu 靶场的价值就在于让你亲手体验单层防护有多脆弱从而理解纵深防御的必要性。我在实际开发中还会加一条登录接口的响应时间做归一化处理。如果用户名不存在时立即返回、用户名存在但密码错误时延迟 500 毫秒返回攻击者就能通过响应时间枚举出有效用户名。统一响应时间能堵住这个侧信道。最后分享一个我在靶场练习时的小习惯每打完一关把完整的请求响应、payload 配置、排查过程记到一个 Markdown 文件里。过一段时间回头看你会发现当时卡住的地方恰恰是你理解最深刻的地方。pikachu 的暴力破解模块不大但把这几关吃透登录接口的安全设计思路基本就通了。