企业官网建设流程全解析

前言
在上一篇中，我们完成了最基础的表单爆破和前端验证码绕过。但在实际场景中，很多系统会把验证码和Token放到后端去校验，试图以此来防御自动化工具。本文记录了在 Pikachu 靶场中，针对“后端验证码”与“Token”防护机制的绕过思路与实战过程。核心依然在于寻找校验逻辑的信任边界漏洞。

场景三：验证码绕过（on sever）—— 后端校验缺陷
我们有一项方法可以增强他的安全性，比如每次登陆的时候都使用验证码，这样的话，我们很难在每次请求都附带上正确的验证码，对于爆破工具来说，识别这个可能是较为为困难的，当然了，如果验证码比较简单好识别的话，我们可以用一些图像识别程序去识别出里面的数字，如果他的校验是放在前端的话，那可能的安全问题就是当你验证失败的时候，他并没有刷新这个验证码。

我们先来输入一个错误的验证码，可以看到返回验证码输入错误。

但是如果在错误的情况下忘记刷新验证码了，或者我们没有出发请求让验证码刷新，只是一个单纯的表单提价失败，并没有请求验证码，那他是不是就不会刷新呢？如果没有考虑到这点，这也是一个不安全的情况。

这里先输入正确的验证码截取一个数据包。显示用户名和密码不存在，我们去代理模块找到数据包发送到重放器。

把验证码改为当前正确的验证码，点击发送，在响应中提示用户名和密码不存在。（这里最好不要点击页面渲染Render，避免重新发送验证码刷新请求）。

改完还是登陆失败，不知道验证码有没有刷新，换用户名和密码再登陆一次，验证码不变，点击发送。
这里还是只显示用户名和密码不存在，说明后端的验证码并没有被刷新。这样我们可以用这个验证码重复暴破。

把包发送到Intruder，攻击类型选择Cluster bomb，给用户名和密码添加 payload 标记，在用户名和密码的位置上添加一些常见的用户名和密码。


点击开始攻击，根据长度筛选，找到正确的用户名和密码，如果是服务端校验验证码的情况，没有考虑登录失败去刷新验证码的话，依然是一种不安全的情况，依然是可以暴破的。

场景四：Token 防爆破绕过

现象评估：查看登录请求包，发现除了账号密码，还多了一个 token 参数。每次刷新页面，Token都会变化。如果直接像以前那样跑字典，会一直报错 csrf token error。

操作路径：

1. 抓包与定位：
   首先清空HTTP历史记录，关闭拦截，刷新Pikachu网页，输入用户名1和密码1，在Burp suit 抓取POST登录请求并发送到重放器，发现 username、password、token 三个参数。‌而Token来自上一个GET请求类型的包———服务器的相应响应部分，也就是服务器返回过来的部分。
   我们可以在响应input 后面标黄的地方看到多出来一个隐藏的输入框，参数名为Token,他的值value和POST包里的一样，也就是说我们在发送请求包的时候，要带上服务器上一次发给我们的Token值。下面我们把包发送到Intruder。

2. 设置攻击类型：因为我们要让“每一次密码尝试”都匹配“最新的Token”，所以要把攻击类型改为 Pitchfork（音叉模式），为了降低难度，先把用户名改成 admin ，并将 password 和 token 两个值都打上标记（§）。‌

2. 配置 Payload 1（密码字典）：选择“简单列表”，加载弱口令字典。‌

3. 配置 Payload 2（动态 Token 提取）：这是最关键的一步。Payload 2 的类型选择 递归搜索 (Recursive grep)。这就要求我们在上一步的“设置”标签页里，配置好 Grep - Extract（检索-提取）。在响应包中选中 value=" 后面那串真实的 Token 值，Burp 会自动生成正则边界。‌
   

4. 设置重定向：在设置里，将重定向选项设置为 “总是”。这样每次请求完，Burp 才能自动跟随重定向去获取下一次的新页面（和新Token）。‌
   

5. 强制单线程（必做）：因为 Token 是一次性的，如果多线程并发，线程A拿到的 Token 可能被线程B用了，导致全部报错。因此，在“资源池”里新建一个资源池，把 最大并发请求数设置为 1。‌
   
   回到网页，刷新页面，点击F12，找到表单位置，找到并复制 value 的值。
   
   在payload2 里面找到初始payload,把刚刚复制的 value 值粘贴进去。
   

6. 开始攻击与分析：
   点击开始攻击。由于每一次请求都动态获取了新Token，爆破得以顺利进行。
   观察结果列表，绝大多数请求的长度是 3490x，但第一条（密码为 123456）的响应长度变成了 34879。
   在下方的响应预览中，我们看到了 login success。爆破成功！‌
   

💡 核心总结与防御思考
• 后端验证码校验缺陷：
• 原因：验证码在验证一次成功后，没有在 Session 中立即销毁，导致被重放利用。
• 防御：验证码必须一次一用，只要提交了请求（无论密码对不对），验证码立即失效。
• Token 防御机制：
• 原因：Token 虽然随机且一次性，但它是暴露在前端 HTML 里的。攻击者只要在抓包工具里编写正则，实现“动态提取、动态携带”，就能实现“取一个、用一次”的自动化绕过。
• 防御：在 Token 之外，必须叠加基于 IP 或账号的频率限制（Rate Limiting）。比如 1 分钟内失败 5 次就锁定账号或封禁 IP。
一句话总结：只要防护逻辑是在客户端（前端）完成的，或者校验完没做频率限制，在自动化工具面前都形同虚设。