POrtSwigger靶场之CSRF where token validation depends on token being present通关秘籍

一、核心理论知识：令牌存在性依赖型 CSRF 漏洞

该漏洞的本质是服务器的 CSRF 防御逻辑不完整：

• 正常逻辑 ：服务器应同时检查 "是否存在 csrf 令牌" 和 "令牌值是否有效"（与用户会话绑定）；
• 漏洞逻辑 ：服务器仅检查 "请求中是否包含 csrf 参数"，若存在则拒绝（无论值是否正确），若完全删除 csrf 参数，则直接执行操作（验证失效）。

这种 "只要没有令牌就通过" 的设计，使得攻击者可构造不含 csrf 令牌的恶意请求，借助受害者的登录状态完成 CSRF 攻击。

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

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

1. 使用 wiener:peter 登录靶场，进入 "我的账户" 页面；
2. 打开 Burp Suite 并拦截 "更改邮箱" 的表单提交请求（确保浏览器代理已配置）；
3. 观察拦截的 POST 请求，核心结构如下（包含 csrf 令牌参数）：

步骤 2：验证 "删除 csrf 参数可绕开防御"

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

2. 测试 1：修改 csrf 令牌值 为 csrf=invalid，发送请求。服务器会返回拒绝响应 （如 403 Forbidden 或带错误提示），说明 "存在无效令牌时防御生效"。

3. 测试 2：完全删除 csrf 参数 删除请求体中的 &csrf=yyyy，仅保留 email=1@qq.com，请求结构变为：

   

   发送请求后，观察响应：返回 302 重定向（跳转到账户主页）且账户邮箱实际已修改，说明删除令牌后防御失效（漏洞确认）。

步骤 3：构造不含 csrf 令牌的恶意 HTML

由于服务器对 "无 csrf 参数的请求" 不验证，直接构造不含 csrf 字段的 POST 表单即可：

• 关键：表单中不能包含任何 name="csrf" 的字段，否则服务器会触发验证并拒绝请求。

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

1. 访问靶场的 "漏洞服务器"，将上述 HTML 粘贴到 "Body" 中，点击 "Store"；
2. 点击 "View Exploit" 查看恶意页面，此时浏览器会自动提交请求；验证邮箱是否修改：访问靶场 "我的账户" 页面，若邮箱已变为2@qq.com，说明攻击有效。

步骤 5：发起最终攻击

1. 确保恶意 HTML 中的 email 是未被占用的新邮箱（避免冲突）；
2. 点击漏洞服务器的 "Deliver to Victim"，靶场会模拟受害者访问恶意页面；
3. 受害者的邮箱被成功修改后，实验室提示 "已解决"。

三、关键注意事项

1. 必须完全删除 csrf 参数 ：恶意表单中若误加 csrf 字段（即使值为空），服务器会拒绝请求；
2. 邮箱唯一性 ：使用未被注册的邮箱（如 csrf-exploit-123@web-security-academy.net）；
3. 请求方法保持 POST：服务器可能仅对 POST 请求存在此漏洞，不可改为 GET。

通过以上步骤，利用服务器 "仅检查令牌存在性" 的缺陷，即可成功绕开 CSRF 防御，完成靶场任务。