POrtSwigger靶场之CSRF where token validation depends on token being present通关秘籍
一、核心理论知识：令牌存在性依赖型 CSRF 漏洞
该漏洞的本质是服务器的 CSRF 防御逻辑不完整：
- 正常逻辑：服务器应同时检查 “是否存在
csrf令牌” 和 “令牌值是否有效”（与用户会话绑定）； - 漏洞逻辑：服务器仅检查 “请求中是否包含
csrf参数”，若存在则拒绝（无论值是否正确），若完全删除csrf参数，则直接执行操作（验证失效）。
这种 “只要没有令牌就通过” 的设计，使得攻击者可构造不含 csrf 令牌的恶意请求，借助受害者的登录状态完成 CSRF 攻击。
二、实践步骤：从漏洞验证到攻击完成
步骤 1：登录账户，捕获 “更改邮箱” 的 POST 请求
- 使用
wiener:peter登录靶场，进入 “我的账户” 页面； - 打开 Burp Suite 并拦截 “更改邮箱” 的表单提交请求（确保浏览器代理已配置）；
- 观察拦截的 POST 请求，核心结构如下（包含
csrf令牌参数）：
步骤 2：验证 “删除 csrf 参数可绕开防御”
将拦截的请求发送到 Burp Repeater（右键 → Send to Repeater）；
测试 1：修改 csrf 令牌值为
csrf=invalid，发送请求。服务器会返回拒绝响应（如 403 Forbidden 或带错误提示），说明 “存在无效令牌时防御生效”。
测试 2：完全删除 csrf 参数删除请求体中的
&csrf=yyyy，仅保留email=1@qq.com，请求结构变为：
发送请求后，观察响应：返回 302 重定向（跳转到账户主页）且账户邮箱实际已修改，说明删除令牌后防御失效（漏洞确认）。
步骤 3：构造不含 csrf 令牌的恶意 HTML
由于服务器对 “无 csrf 参数的请求” 不验证，直接构造不含 csrf 字段的 POST 表单即可：
- 关键：表单中不能包含任何
name="csrf"的字段，否则服务器会触发验证并拒绝请求。
步骤 4：上传恶意 HTML 到漏洞服务器并验证
- 访问靶场的 “漏洞服务器”，将上述 HTML 粘贴到 “Body” 中，点击 “Store”；
- 点击 “View Exploit” 查看恶意页面，此时浏览器会自动提交请求；验证邮箱是否修改：访问靶场 “我的账户” 页面，若邮箱已变为2@qq.com，说明攻击有效。
步骤 5：发起最终攻击
- 确保恶意 HTML 中的
email是未被占用的新邮箱（避免冲突）； - 点击漏洞服务器的 “Deliver to Victim”，靶场会模拟受害者访问恶意页面；
- 受害者的邮箱被成功修改后，实验室提示 “已解决”。
三、关键注意事项
- 必须完全删除 csrf 参数：恶意表单中若误加
csrf字段（即使值为空），服务器会拒绝请求； - 邮箱唯一性：使用未被注册的邮箱（如
csrf-exploit-123@web-security-academy.net）； - 请求方法保持 POST：服务器可能仅对 POST 请求存在此漏洞，不可改为 GET。
通过以上步骤，利用服务器 “仅检查令牌存在性” 的缺陷，即可成功绕开 CSRF 防御，完成靶场任务。