Burp Suite实战：从BuyFlag靶场剖析Cookie伪造与参数数组绕过的艺术

打开Burp Suite的那一刻，仿佛握住了数字世界的万能钥匙。今天我们要解构的BuyFlag靶场，正是检验渗透测试基本功的绝佳试金石——它像一位严苛的教练，用三层防御机制考验着我们对HTTP协议、会话管理和PHP类型魔法的理解深度。

1. 靶场环境侦察与密码逻辑破解

靶场首页赫然显示"FLAG NEED YOUR 100000000 MONEY"，而查看源代码会发现一段关键PHP验证逻辑：

if (isset($_POST['password'])) { $password = $_POST['password']; if (is_numeric($password)) { echo "password can't be number"; } elseif ($password == 404) { echo "Password Right!"; } }

这段代码暴露了两个重要特征：

• 双重验证机制：先排除纯数字输入，再要求弱等于404
• 类型转换漏洞：==操作符触发PHP的自动类型转换

实战绕过方案：

1. 使用HackBar构造POST请求，参数设为password=404a
2. 在Burp Repeater中观察响应，确认返回"Password Right!"

注意：直接在Burp中修改GET为POST可能导致方法未真正转换，建议先用浏览器插件发送初始POST请求再拦截

2. Cookie会话控制与权限提升

通过第一关后，响应头中的Cookie: user=0引起了我的注意。在Web安全领域，这类布尔型会话标识极为常见：

Burp操作流程：

1. 在Proxy -> HTTP history中找到成功验证password的请求
2. 右键发送至Repeater，修改Cookie头为user=1
3. 观察响应变化，确认权限提升成功

POST /buyflag.php HTTP/1.1 Host: target.com Cookie: user=1 Content-Type: application/x-www-form-urlencoded password=404a&money=100000000

3. 科学计数法与数组参数的高级绕过

当尝试提交money=100000000时，系统返回"Number length is too long"。这提示我们需要更精巧的绕过方式：

方案对比表：

strcmp()漏洞利用细节：

// 假设后端校验逻辑 if (strcmp($_POST['money'], $flag) == 0) { echo $Flag; }

当money参数以数组形式提交时，strcmp()会返回NULL，在弱类型比较中等同于0。Burp中的最终攻击载荷：

POST /buyflag.php HTTP/1.1 Host: target.com Cookie: user=1 Content-Type: application/x-www-form-urlencoded password=404a&money[]=0

4. 渗透测试中的陷阱与调试技巧

在实际操作中，我遇到了Burp Repeater面板突然消失的情况——这提醒我们总要准备Plan B。我的应急方案是：

1. 立即保存当前工作空间（Ctrl+S）
2. 使用备用工具如Kali Linux中的旧版Burp
3. 检查Java环境变量配置

常见问题排查清单：

• 请求方法未正确转换 → 用浏览器插件先发送标准POST
• Cookie修改后无效 → 检查域名作用域和HttpOnly属性
• 数组参数不生效 → 确保Content-Type为application/x-www-form-urlencoded

在靶场通关的最后阶段，当那个熟悉的flag{...}格式字符串出现在响应中时，我习惯性地做了三件事：

1. 立即记录完整攻击链时间戳
2. 保存所有修改过的请求/响应包
3. 用不同浏览器验证漏洞重现性

这种严谨的习惯后来在真实渗透测试中多次帮我发现了边缘案例漏洞。记住，每个靶场都是现实漏洞的微缩景观，而Burp Suite就是我们观察这个景观的显微镜和解剖刀。