AURIX TriCore联合调试：HighTec与UDE协同配置实战指南
2026/9/28 6:04:38
以下是第七周周六学习内容的详细展开。今天你将把本周学到的 CSRF 攻击与防御知识全部串联，在 DVWA 的 Low、Medium、High 三个安全级别中独立完成一次“攻击—检测—加固”的完整实践。这不仅是对 CSRF 漏洞的终极检验，也是为你建立“面向防御的攻击思维”的关键一步。
第七周·周六：DVWA CSRF 全难度手工复现——攻击、绕过与防御总结
🎯 今日学习目标（达成效果）
- 能独立复现DVWA CSRF 关卡 Low 难度的 GET 型 CSRF 攻击，并成功修改受害者密码；
- 能成功绕过Medium 难度的 Referer 校验防御，通过构造文件名或借助其他绕过手法完成攻击；
- 能体会High 难度 CSRF Token 的防御强度，并理解为什么在没有 XSS 的前提下无法直接绕过；
- 能为 Low 级别编写出完整的 CSRF PoC 页面，并从防御者视角提出至少三条加固建议；
- 能用表格总结CSRF 的三大防御手段及其各自的局限性，形成自己的安全知识库；
- 能从攻击者视角转换为防御者视角，在脑海中形成“漏洞发现→漏洞利用→安全加固→回归测试”的完整闭环。
✍️ 一、环境准备与目标确认
1. 实验拓扑
- 靶机：DVWA (192.168.1.200 或本地 127.0.0.1)
- 攻击机：你的主机（可同机使用不同端口或文件来模拟跨域）
- 受害者浏览器：推荐使用隐私窗口或不同浏览器，确保初始状态下未登录 DVWA，然后手动登录。
2. 关卡切换
登录 DVWA → DVWA Security → 依次选择 Low / Medium / High，每完成一个级别后重置数据库（Setup → Reset DB），避免密码混乱。
3. 基本操作接口
DVWA CSRF 页面的密码修改接口在 Low 级别为：
GET http://靶机/vulnerabilities/csrf/?password_new=新密码&password_conf=新密码&Change=ChangeMedium 和 High 级别的接口路径相同，但防御机制增强。
✍️ 二、Low 级别——无防御，直接攻击
攻击步骤
- 在攻击机创建
csrf_low.html：
<!DOCTYPEhtml><html><body><h1>恭喜你获得免费 iPhone！点击领取</h1><imgsrc="http://靶机/vulnerabilities/csrf/?password_new=lowhack&password_conf=lowhack&Change=Change"style="display:none;"></body></html>- 在受害者浏览器中登录 DVWA，保持会话。
- 同一浏览器新标签页打开
csrf_low.html（通过文件或 HTTP 服务）。 - 返回 DVWA，使用旧密码登录失败，使用
lowhack登录成功。
攻击原理
浏览器加载<img>标签时自动携带 DVWA 的 Cookie，服务器误认为受害者本人发起请求。由于无任何校验，攻击直接成功。
防御建议（Low 升级到安全）
- 禁止使用 GET 方法修改资源，一律使用 POST；
- 加入随机 CSRF Token，与用户会话绑定；
- 设置 SameSite=Lax Cookie 属性。
✍️ 三、Medium 级别——Referer 校验与绕过
防御机制
DVWA Medium 检查 HTTP Referer 头是否包含服务器主机名（如localhost或127.0.0.1或服务器 IP）。如果包含，则放行；否则拒绝。
直接攻击失败
使用 Low 级别的<img>攻击页面，请求的 Referer 是攻击页面的 URL（如http://攻击者IP/csrf_low.html），不包含目标主机名，请求被拦截。
绕过思路（文件命名绕过）
后端代码简化了检查逻辑，仅用类似stripos($_SERVER['HTTP_REFERER'], '目标主机名')的方式。我们可以让攻击页面的 URL 中包含主机名字符串。
- 将攻击 HTML 文件重命名为
192.168.1.200.html（假设目标 IP 是 192.168.1.200）。 - 放置在攻击者 Web 服务器根目录，并通过浏览器访问：
http://攻击者IP/192.168.1.200.html - 此时 Referer 为
http://攻击者IP/192.168.1.200.html，包含了目标 IP 字符串，校验通过。 - 密码被成功修改。
注意：若目标为本地localhost，可将文件名包含localhost字样，如localhost_page.html。
Medium 修复建议
- 严格校验 Referer 必须完全匹配白名单域名，而非子串包含；
- 同时校验 Origin 头；
- 添加 CSRF Token 作为根本防御。
✍️ 四、High 级别——CSRF Token 与无法直接绕过的屏障
防御机制
High 级别在修改密码表单中加入了一个隐藏的user_token，每次页面加载时随机生成，并与当前会话绑定。提交请求时必须携带该 Token，且 Token 只能使用一次或有效期很短。
尝试直接攻击
即使构造自动提交的 POST 表单，由于无法获取受害者的有效 Token，提交后服务器返回 “CSRF token is incorrect”，攻击失败。
绕过条件
只有在存在 XSS 漏洞的情况下，攻击者才能通过脚本读取页面中的 Token 并完成自动化 CSRF 攻击（即 XSS+CSRF 组合）。DVWA 存储型 XSS 可用于此。但如果没有 XSS，外部页面无法突破同源策略读取 Token，CSRF 防御在 High 级别非常坚固。
防御总结
- CSRF Token 是目前最有效的防御手段，但必须保证 Token 随机、绑定会话、不在 URL 中传递。
- 结合 SameSite Cookie 和 Origin 头校验形成纵深防御。
📝 五、测试题与解析
测试题：请写出 DVWA Low 级别 CSRF 漏洞的完整 PoC 代码，并从防御者角度提出三条加固措施。
参考答案：
PoC 代码（GET 型）：
<imgsrc="http://靶机/vulnerabilities/csrf/?password_new=attacker&password_conf=attacker&Change=Change">加固措施：
- 使用 CSRF Token：在表单中嵌入随机、不可预测的 Token，服务端验证；
- 禁止使用 GET 执行敏感操作：修改密码必须使用 POST 方法，降低直接通过 URL 攻击的风险；
- 设置 SameSite 属性：将会话 Cookie 设置为 SameSite=Lax 或 Strict，阻止跨站请求自动携带 Cookie。
✅ 今日学习效果自检清单
- 我独立在 Low 级别用 GET 方式修改了受害者密码
- 我成功通过文件名构造绕过了 Medium 的 Referer 校验
- 我在 High 级别体验了 Token 防御的强度，并明白 XSS 是它的克星
- 我能清楚对比三种防御手段（Token、Referer、SameSite）的优劣
- 我能够从攻击和防御两个角度写出一份简短的 CSRF 安全分析报告
- 我理解所有防御措施都不能孤立存在，XSS 漏洞会直接威胁 Token 防御
⚠️ 阶段避坑重点
- 不要混淆 Medium 的 Referer 检查和 Origin 检查：Medium 用的是 Referer 子串匹配，极易绕过；Origin 通常在 CORS 中更重要，但 CSRF 防御中 Referer 更常见。
- 不要在 High 级别试图用静态 Token：Token 每次刷新都不同，无法通过猜测或重放成功。
- 攻击页面一定要在真实浏览器中测试：使用隐私窗口、清除 Cookie 后再登录受害者账号，确保攻击是由已登录状态触发的。
- 实验结束后及时重置数据库：避免密码混乱影响后续实验。
🎉 今天你完成了 CSRF 漏洞从零到精通的完整闭环。经过这一周的学习，你已经能够独立发现、利用并加固 Web 应用中两种最普遍的漏洞——XSS 和 CSRF。下周我们将进入更深层次的高阶漏洞领域（文件上传、命令执行、逻辑漏洞等），并将你的渗透思维从“单一漏洞”提升到“攻击链”的高度。