PortSwigger靶场之CSRF where token validation depends on request method通关秘籍

一、核心理论知识：请求方法依赖型 CSRF 漏洞

该漏洞是 "无防御 CSRF" 的变种，本质是服务器的防护逻辑存在 "漏洞"：仅针对某一种请求方法（通常是 POST）做 CSRF 令牌验证，而对另一种方法（通常是 GET）完全不验证，导致攻击者可通过篡改请求方法发起 CSRF 攻击。

1. 漏洞产生的关键逻辑

• 正常 POST 请求 ：服务器要求请求必须包含有效的 csrf 令牌（如表单隐藏字段 csrf=xxxx），否则拒绝请求（防御生效）；
• 篡改后的 GET 请求 ：将原本的 POST 请求参数（如 email=xxx）通过 URL 传递（即 GET 参数），此时服务器不检查 CSRF 令牌，直接执行 "更改邮箱" 逻辑（防御失效）；
• CSRF 攻击成立：利用 GET 请求无需令牌的特性，构造恶意 HTML 自动发起 GET 请求，借助受害者的已登录状态完成攻击。

2. 与 "无防御 CSRF" 的区别

对比维度	无防御 CSRF	请求方法依赖型 CSRF
POST 请求防护	无任何验证	需 CSRF 令牌（防护生效）
GET 请求防护	无任何验证	无验证（防护失效）
攻击核心	构造 POST 型恶意表单	构造 GET 型恶意表单（绕开令牌验证）

二、实践步骤：从漏洞验证到攻击完成

需通过 Burp Suite 分析请求方法差异，再构造 GET 型恶意 HTML 上传到漏洞服务器，具体步骤如下：

步骤 1：登录账户，捕获 "更改邮箱" 的原始 POST 请求

1. 使用凭证 wiener:peter 登录靶场，进入 "我的账户"（My Account）页面；

2. 打开 Burp Suite，确保浏览器代理已配置（默认 127.0.0.1:8080），且 "代理" 模块处于 "拦截开启" 状态；

3. 在 "更改邮箱" 表单中输入测试邮箱（如 test@qq.com），点击 "提交"，Burp 会拦截到该 POST 请求；

4. 查看拦截的请求内容，核心结构如下（重点关注 method=POST 和 csrf 令牌字段）：

   
   此时若修改 csrf 令牌的值（如改为 csrf=zzzz），点击 "发送"，服务器会返回拒绝响应 （说明 POST 请求的 CSRF 验证生效）。

步骤 2：篡改请求方法为 GET，验证防御是否失效

1. 将拦截的 POST 请求发送到 Burp Repeater（右键 → Send to Repeater）；

2. 在 Repeater 模块中，点击 "Change request method"（更改请求方法，Burp 顶部菜单栏或右键菜单），将 POST 改为 GET；

3. 篡改后，请求结构会自动变化：POST 参数（email 和 csrf）会被移动到 URL 中作为 GET 参数，核心结构如下：

   GET /my-account/change-email?email=test-get%40example.com&csrf=yyyy HTTP/1.1
   Host: [你的靶场ID].web-security-academy.net
   Cookie: session=xxxx; csrf=yyyy

4. 点击 Repeater 的 "发送" 按钮，观察响应：

   • 若服务器返回302 是 "操作成功后的'指路牌'"，不是 "操作失败" ------ 它代表 "邮箱已改好，你去账户主页看结果吧"
   • 进一步测试：删除 URL 中的 &csrf=zzzz 参数，再次发送请求 ------ 若仍能成功修改邮箱，证明服务器对 GET 请求完全不做 CSRF 验证（漏洞确认）。

步骤 3：构造 GET 型 CSRF 恶意 HTML

由于服务器对 GET 请求不验证 CSRF 令牌，只需构造一个 "自动提交 GET 请求" 的表单即可，无需包含 csrf 字段。

1. 在 Repeater 中找到已验证有效的 GET 请求，右键点击；
2. 选择 Engagement Tools → Generate CSRF PoC ；
3. 勾选 "Include auto-submit script"，Burp 会自动生成 GET 型恶意 HTML（无需手动处理参数），复制该代码即可。

步骤 4：上传恶意 HTML 到漏洞服务器并验证

1. 访问靶场的 "漏洞服务器"（Vulnerability Server）页面；
2. 在 "Body" 输入框中粘贴步骤 3 构造的恶意 HTML，点击 "Store"（存储）；
3. 点击 "View Exploit"（查看漏洞页面）------ 此时你的浏览器会自动发起 GET 请求，跳转回靶场账户页面；
4. 刷新账户页面，检查邮箱是否已改为恶意 HTML 中设置的 2@qq.com：
   • 若已修改，说明恶意 HTML 有效；
   • 若未修改，检查 action 中的靶场 ID 是否正确、email 是否为未占用邮箱。

步骤 5：发起最终攻击，交付给受害者

1. 若自测成功，回到漏洞服务器页面，确认恶意 HTML 中的 email 是未被任何用户占用的新邮箱（避免与自己的测试邮箱冲突）；
2. 点击漏洞服务器的 "Deliver to Victim"（交付给受害者）按钮 ------ 靶场会模拟受害者（已登录状态）访问恶意 HTML 页面；
3. 受害者访问后，GET 请求自动发起，服务器不验证 CSRF 令牌，直接修改其邮箱，最终靶场提示 "实验室已解决"。

三、关键注意事项

1. 请求方法必须为 GET ：若误将 method 写为 POST，恶意请求会因缺少 csrf 令牌被服务器拒绝，攻击失败；
2. 邮箱唯一性 ：与无防御 CSRF 相同，email 值必须是未被注册的邮箱（可通过多次测试确认，如 test-get-123@web-security-academy.net）；
3. URL 参数拼接正确性 ：GET 表单的参数会自动拼接到 action URL 后（格式为 ?email=xxx），无需手动在 URL 中添加参数，避免重复导致错误；
4. 验证 GET 请求的无防护性 ：必须通过 Burp Repeater 确认 "删除 csrf 参数后 GET 请求仍有效"，否则无法绕开防御。

通过以上步骤，即可利用 "服务器对请求方法的防护不一致" 这一漏洞，绕开 CSRF 令牌验证，成功发起攻击并完成靶场任务。