首页/资讯中心/详情

CSRF漏洞实战：从原理到防御，以成绩修改靶场为例

CSRF漏洞实战：从原理到防御，以成绩修改靶场为例
📅 发布时间：2026/6/29 8:33:07

1. 项目概述：从一次“改分”实战看CSRF漏洞的本质

最近在带新人做安全测试，发现很多人对CSRF（跨站请求伪造）漏洞的理解还停留在“知道有这么个东西”的层面，真到了靶场环境，面对一个看似无害的链接或表单，往往就不知道怎么下手了。正好，手头这个“Grade靶场”的CSRF漏洞场景非常典型——目标就是利用漏洞，在未经授权的情况下修改学生的成绩。这听起来有点“黑客电影”的味道，但原理其实很朴素，就是利用了Web应用对用户请求来源的信任机制。今天，我就以这个“改成绩”的实战为例，把CSRF漏洞从原理到利用，再到防御，掰开揉碎了讲清楚。无论你是刚入门的安全爱好者，还是想巩固基础的开发人员，这篇文章都能让你对CSRF有一个透彻、实操层面的理解，而不仅仅是背下几个名词。

简单来说，CSRF攻击就是攻击者诱骗已经登录了目标网站（比如教务系统）的用户，去点击一个恶意链接或访问一个恶意页面。这个恶意请求会“借用”用户在目标网站上的登录状态（通常是浏览器自动携带的Cookie），以该用户的身份执行非本意的操作，比如转账、改密码，或者像我们这个靶场里的——更改成绩。整个过程，用户可能毫无察觉。这个靶场模拟的正是这样一个存在缺陷的“成绩管理系统”，我们接下来的所有操作，都将围绕如何发现并利用这个缺陷展开。

2. 靶场环境搭建与核心漏洞原理剖析

2.1 靶场部署与初步侦查

首先，我们需要一个可操作的靶场环境。网络上有很多优秀的开源靶场，比如Pikachu、DVWA、Webug等，它们都内置了CSRF漏洞场景。为了更贴近“Grade”这个主题，我们可以选择Pikachu靶场，它里面有一个非常清晰的“CSRF”模块，模拟了类似“修改个人信息”的场景，其原理与我们“改成绩”完全一致。部署方式很简单，通常是一个PHP项目，你只需要有一个支持PHP和MySQL的Web服务器环境（如XAMPP、PHPStudy），把源码丢到网站根目录，按照提示初始化数据库即可。

注意：请务必在本地虚拟机或隔离的网络环境中搭建和测试靶场。未经授权对任何线上系统进行测试都是非法且不道德的。

环境跑起来后，我们访问靶场，登录（默认账号密码通常在源码或文档里），找到CSRF测试模块。以Pikachu的“CSRF(get)”为例，它会展示一个表单，让用户修改昵称、邮箱等信息。我们的第一步不是急着攻击，而是扮演一个正常的用户和开发者，去理解这个请求的流程。

  1. 正常操作观察：我们先正常修改一次信息，比如把昵称改成“test_user”。在这个过程中，打开浏览器的开发者工具（F12），切换到“网络”(Network)标签页，并勾选“保留日志”(Preserve log)。点击提交后，我们会看到浏览器向服务器发送了一个HTTP请求。
  2. 关键请求分析：仔细查看这个请求。你会发现几个关键特征：
    • 请求方法：很可能是GET，也可能是POST。Pikachu的“CSRF(get)”模块用的就是GET。这意味着修改信息的参数（如nickname=test_user）直接附加在URL后面，形如http://target.com/csrf/get/edit.php?nickname=test_user&submit=submit。
    • 认证凭证：在请求头中，你会看到Cookie字段，里面包含了你的会话标识（如PHPSESSID=xxxxxx）。这就是你处于登录状态的证明。服务器靠这个Cookie来识别你是“谁”。
    • 缺乏Token：最关键的一点，查看请求的URL参数或请求体（如果是POST），你会发现没有一个随机的、一次性的令牌参数，比如csrf_token=abcdef123456。这就是漏洞存在的根本标志。

这个分析过程就是“侦查”。它告诉我们，这个修改操作仅依赖于浏览器自动携带的Cookie来认证用户身份，而请求本身（无论来自哪里）只要参数正确，服务器就会执行。这就为CSRF攻击打开了大门。

2.2 CSRF漏洞的深层原理与条件

为什么没有Token就是漏洞？这需要从Web的“无状态”和“信任”机制说起。HTTP协议本身是无状态的，服务器无法记住上一次是谁来的。为了维持登录状态，发明了Session（在服务器端）和Cookie（在客户端，通常是Session ID）这套机制。服务器告诉浏览器：“给你个通行证（Cookie），下次来带着，我就知道是你了。”

CSRF攻击正是滥用了这份“信任”。它基于一个关键假设：浏览器在向某个域名发送请求时，会自动携带该域名下的Cookie。攻击者构造一个请求，这个请求指向目标网站（例如靶场的修改成绩接口）。当受害者在已经登录目标网站的情况下（即浏览器存有有效Cookie），访问了攻击者精心设计的页面，这个页面会自动或诱导用户向目标接口发起请求。此时，浏览器“老实巴交”地附上了受害者的Cookie，服务器一看Cookie有效，便认为是受害者在主动操作，于是执行了修改动作。

一次成功的CSRF攻击需要同时满足以下几个条件：

  1. 目标操作存在：网站有一个明确的操作接口，比如修改数据、转账、发帖。
  2. Cookie/Session认证：这个操作依赖Cookie或Session来识别用户身份，且没有其他强验证（如二次密码、验证码）。
  3. 请求可预测：攻击者能够完全预测该操作所需的所有HTTP请求参数（如用户ID、要修改的成绩值等）。这些参数通常可以通过分析正常请求轻易获得。
  4. 缺乏不可伪造的令牌：请求中没有使用随机的、与当前用户会话绑定的Token（CSRF Token）。或者，即使有Token，但存在其他逻辑缺陷导致Token可以被攻击者获取或绕过。

我们这个“Grade靶场”场景，完美符合以上所有条件。修改成绩是一个操作，用Cookie登录，请求参数（学号、课程、新成绩）固定或可预测，并且最关键的是——没有CSRF Token验证。

3. 漏洞利用实战：手工构造与自动化攻击

理解了原理，我们开始动手。攻击的核心是“伪造请求”。根据目标接口使用的是GET还是POST方法，我们的利用方式略有不同。

3.1 GET型CSRF利用——最简单的攻击

如果修改成绩的接口使用GET方法（就像Pikachu的get模块），那么利用起来简单得令人吃惊。攻击者只需要构造一个URL，里面包含所有必要的参数。

假设我们分析出正常修改成绩的请求是：http://grade.local/change_score.php?student_id=1001&course=math&new_score=95&submit=1

那么，恶意URL就是它本身！攻击者会想方设法让受害者点击这个链接。方式包括：

  • 在论坛、评论区发布带有该链接的图片或文字：“ 看看这个有趣的图片 ”，实际上点击后是提交改分请求。
  • 通过短链接服务隐藏真实URL。
  • 将其嵌入到邮件或即时消息中。

手工验证：你可以在已登录靶场的情况下，直接在浏览器地址栏输入这个恶意URL并回车，你会发现成绩真的被修改了，而页面可能只是跳转了一下，甚至没有任何明显提示。这就是GET型CSRF的威力——简单、直接、隐蔽。

3.2 POST型CSRF利用——需要一点HTML技巧

更多的情况下，修改操作会使用POST方法，以传输更多数据或遵循RESTful规范。POST请求的参数不在URL里，而是在请求体（body）中。这时，仅仅一个链接就不够了，我们需要一个能自动提交POST表单的页面。

攻击者会搭建一个恶意网站，页面上包含一个隐藏的HTML表单和一段自动提交的JavaScript代码。

<!-- 恶意页面 exploit.html --> <html> <body> <h1>你中奖了！</h1> <p>正在跳转到领奖页面...</p> <!-- 隐藏的表单，指向目标靶场接口 --> <form id="csrf_form" action="http://grade.local/change_score.php" method="POST"> <input type="hidden" name="student_id" value="1001" /> <input type="hidden" name="course" value="math" /> <input type="hidden" name="new_score" value="0" /> <input type="hidden" name="submit" value="1" /> </form> <script> // 页面加载后自动提交表单 document.getElementById('csrf_form').submit(); </script> </body> </html>

当受害者访问这个恶意页面时，表单会自动提交。由于受害者浏览器里存有grade.local的登录Cookie，这个POST请求会带着Cookie发往靶场服务器，从而成功将学号1001的数学成绩改为0分。页面可能快速闪一下，受害者看到的只是“你中奖了”和一段跳转文字，完全不知道背后发生了什么。

3.3 利用技巧与场景扩展

在实际攻击中，攻击者会运用更多技巧提高成功率：

  • 结合XSS：如果目标网站本身存在XSS漏洞，攻击者可以注入脚本，直接在目标网站域内发起CSRF请求，完全绕开同源策略限制，威力巨大。
  • 精准钓鱼：通过社会工程学，使恶意链接或页面看起来与目标网站高度相关，例如伪造一个“教务系统安全升级，请重新验证”的页面，其中就嵌入了CSRF攻击代码。
  • 绕过Referer检查：有些简单的防御会检查HTTP请求头中的Referer字段，看请求来源是否是自己网站的页面。攻击者可以通过一些手段（如利用HTTPS跳转HTTP、某些浏览器的隐私设置或漏洞）来伪造或剥离Referer。

实操心得：在测试时，务必使用两个不同的浏览器（或一个浏览器的正常窗口和无痕窗口）来模拟攻击者和受害者。用一个浏览器（受害者）登录靶场，另一个浏览器（攻击者）访问你构造的恶意页面，观察受害者浏览器的状态或靶场数据是否发生变化。这是最清晰的验证方式。

4. 漏洞挖掘与自动化工具辅助

4.1 手工挖掘漏洞的步骤

作为一名安全测试人员，如何在一个Web应用中寻找CSRF漏洞？可以遵循以下步骤：

  1. 功能点枚举：列出所有具有状态改变功能的操作点。如：修改资料、修改密码、转账、发帖、删除、审核、评分（我们靶场的改成绩）、上传等。
  2. 请求分析：对每个功能点，使用代理工具（如Burp Suite）拦截其正常请求。
    • 查看方法：是GET还是POST？GET方法的风险通常更高。
    • 寻找Token：检查请求参数或头部（如自定义Header、表单隐藏域）是否存在看似随机的、名称如csrf_token、authenticity_token、_token等的参数。
    • 评估其他验证：除了Token，是否有验证码、二次密码、请求头校验（如X-Requested-With）？
  3. 移除Token测试：如果发现Token，尝试在重放请求时将其删除或修改为一个错误的值，观察服务器是否拒绝执行。如果服务器依然成功执行操作，说明Token校验逻辑存在缺陷。
  4. 构造POC：对于疑似存在漏洞的点（无Token或Token校验可绕过），按照上面第3节的方法，手工构造一个简单的HTML PoC（概念验证）页面。在自己的测试环境中验证其是否真的能触发非授权操作。
  5. 验证依赖：确认该操作是否完全依赖Session Cookie进行身份认证。可以尝试在未登录状态下直接发送请求（不带Cookie），看是否被拒绝。如果被拒，而在有Cookie且无Token时成功，则漏洞确认。

4.2 使用Burp Suite辅助测试

Burp Suite作为渗透测试神器，提供了强大的CSRF测试支持：

  1. 拦截与重放：用Proxy模块拦截修改成绩的请求，右键发送到Repeater模块。
  2. 生成POC：在Repeater中，右键请求，选择Engagement tools->Generate CSRF PoC。Burp会自动根据当前请求生成一个HTML攻击页面代码，并内置了自动提交脚本。你可以直接复制这段代码保存为.html文件用于测试，非常方便。
  3. 漏洞扫描：使用Scanner模块进行主动扫描时，它也会自动检测潜在的CSRF漏洞。但要注意，自动扫描可能会有误报和漏报，手工验证必不可少。

注意事项：Burp生成的POC有时会因为目标站点的同源策略（CORS）或复杂的JavaScript交互而失败。对于现代单页面应用（SPA），CSRF攻击可能更复杂，需要分析其API调用方式和认证机制（如是否使用Bearer Token而非Cookie）。此时，手工分析Ajax请求和前端代码变得尤为重要。

5. 从防御到修复：彻底杜绝CSRF攻击

知道了怎么攻击，才能更好地防御。作为开发者，修复CSRF漏洞是必须的。以下是几种主流且有效的防御方案，按推荐程度排序。

5.1 同步令牌模式（Synchronizer Token Pattern）

这是最经典、最有效的防御手段，也是OWASP首要推荐的方法。

原理：服务器在用户会话中生成一个随机、不可预测的令牌（CSRF Token），并在返回给用户的表单（或页面）中嵌入这个令牌（通常作为隐藏字段）。当用户提交表单时，必须将这个令牌一并提交回服务器。服务器验证提交的令牌是否与会话中存储的令牌一致，且是否未过期。攻击者无法构造合法的请求，因为他无法得知这个与特定用户会话绑定的随机令牌。

实现步骤：

  1. 用户访问包含表单的页面（如修改成绩页面）。
  2. 服务器端生成一个强随机数（如UUID），将其存入当前用户的Session中，同时将其输出到表单的一个隐藏输入框里。
<form action="change_score.php" method="POST"> <input type="hidden" name="csrf_token" value="<?php echo $_SESSION['csrf_token']; ?>"> <!-- 其他表单字段 --> <input type="text" name="new_score"> </form>
  1. 用户提交表单。
  2. 服务器端change_score.php在处理请求前，首先比较$_POST['csrf_token']和$_SESSION['csrf_token']是否一致。不一致则立即拒绝请求，返回错误。

关键细节：

  • 令牌需足够随机：使用密码学安全的随机数生成器。
  • 令牌需与会话绑定：每个用户、每个会话的令牌都应不同。
  • 令牌应一次性：最好每次提交后都使旧令牌失效，生成新令牌（更安全，但可能影响浏览器后退或多标签操作）。至少保证令牌有较短的有效期。
  • 对GET请求也要保护：如果某些GET请求会改变状态（不推荐，但历史代码可能存在），也需要为其添加Token验证，可以将Token放在URL查询参数中。

5.2 双重Cookie验证

这是一种在客户端实现的、相对简单的方案，常见于前后端分离的架构。

原理：在用户登录后，前端不仅从响应中获取用于身份认证的Cookie（通常是HttpOnly的），还会获取一个额外的CSRF Token（通过响应头或JSON body）。前端代码（通常是JavaScript）将这个Token写入另一个非HttpOnly的Cookie中，或者存储在内存（如Vuex/Redux）中。之后每次发起可能改变状态的请求（POST/PUT/DELETE等）时，前端需要将这个Token作为自定义请求头（如X-CSRF-TOKEN）发送给服务器。服务器验证请求头中的Token值与Cookie中的Token值是否一致。

为什么能防御：攻击者可以通过CSRF攻击让浏览器发送Cookie，但他无法通过JavaScript读取目标站点的Cookie（得益于同源策略），因此他无法知道这个Token的值，也就无法构造正确的X-CSRF-TOKEN请求头。

实现示例：

  1. 登录成功后，服务器在响应头设置：Set-Cookie: csrf_token=abc123; Path=/
  2. 前端JS保存此Token（从Cookie读取或从响应体解析）。
  3. 前端发起修改成绩的请求：
fetch('/api/change_score', { method: 'POST', headers: { 'Content-Type': 'application/json', 'X-CSRF-TOKEN': getCSRFToken() // 从Cookie或内存读取 }, body: JSON.stringify({score: 95}), credentials: 'include' // 确保发送Cookie });
  1. 服务器端比较请求头X-CSRF-TOKEN的值和请求中携带的Cookie里csrf_token的值是否一致。

5.3 检查Origin/Referer Header

这是一种辅助性的防御手段，不应作为唯一依赖。

原理：服务器检查HTTP请求头中的Origin或Referer字段。这两个字段通常包含了发起请求的页面来源。如果请求来自同源站点（自己的网站），则放行；如果来自外域，则拒绝。

局限性：

  • Referer可能被篡改或缺失：有些浏览器出于隐私考虑，在某些情况下不会发送Referer（如从HTTPS跳到HTTP）。攻击者也可能通过某些浏览器漏洞或中间人攻击来篡改Referer。
  • Origin只存在于CORS请求：对于简单的表单提交，浏览器不会发送Origin头。
  • 配置复杂：需要精确维护一个合法的源（Origin）列表。

因此，这种方法通常作为其他主防御方案（如Token）的补充，用于增加攻击门槛。

5.4 框架内置防护与最佳实践

现代Web开发框架通常内置了CSRF防护：

  • Django：中间件django.middleware.csrf.CsrfViewMiddleware默认启用，为表单自动添加{% csrf_token %}标签。
  • Spring Security：默认启用CSRF保护，要求所有非GET请求携带_csrf参数。
  • Laravel：为每个活跃用户会话生成CSRF令牌，并通过@csrf指令在表单中嵌入。
  • Express (Node.js)：可以使用csurf中间件。

开发最佳实践：

  1. 遵循RESTful规范：使用合适的HTTP方法。GET请求只用于获取数据，永不改变状态。修改数据用POST、PUT、PATCH，删除用DELETE。这从习惯上减少了GET型CSRF的风险。
  2. 关键操作增加二次确认：对于修改密码、转账、删除重要数据等操作，要求用户输入当前密码或进行短信/邮箱验证。这虽然不是专门的CSRF防御，但能有效缓解CSRF造成的损害。
  3. 设置Cookie属性：为身份认证Cookie设置SameSite属性为Strict或Lax。SameSite=Lax可以阻止大多数跨站的POST请求携带Cookie，对防御CSRF有显著效果，已成为现代浏览器的默认或推荐行为。
  4. 定期安全审计与测试：将CSRF漏洞检查纳入代码审查和自动化安全测试流程。

6. 靶场实战进阶：漏洞组合与复杂场景

单一的CSRF漏洞利用已经很有威胁，但当它与其他漏洞结合时，会产生更大的破坏力。在“Grade靶场”或类似环境中，我们可以尝试探索一些进阶场景。

6.1 CSRF + XSS：链式攻击的威力

假设靶场的成绩查询页面存在一个存储型XSS漏洞，比如在显示学生姓名时未做过滤，攻击者可以将姓名设置为一段恶意脚本<script>...</script>。那么，所有查看该学生信息的老师或管理员，其浏览器都会执行这段脚本。

攻击者可以在这段脚本中嵌入CSRF攻击代码。例如，脚本自动构造一个修改管理员密码或提升攻击者权限的请求。由于脚本是在目标网站域内执行的，它完全拥有该域下的Cookie访问权限（除非Cookie是HttpOnly的），可以轻松读取CSRF Token（如果存在但可被读取），然后发起一个完全合法的、带Token的请求。这种组合攻击几乎可以绕过所有单纯的CSRF防御措施。

防御思路：根治XSS（对所有用户输入进行严格的输出编码），同时为关键Cookie设置HttpOnly属性，防止JavaScript读取，从而切断XSS获取Token的途径。

6.2 针对JSON API的CSRF攻击

现代前端应用常通过JSON API与后端交互。如果后端API仅依赖Cookie进行身份认证，并且没有实施CSRF防护，那么它依然可能受到攻击。

攻击者可以构造一个恶意页面，使用JavaScript的fetch或XMLHttpRequest向目标API发送JSON格式的POST请求。关键在于，需要设置credentials: 'include'（或withCredentials: true）来让浏览器携带Cookie。

<script> fetch('http://grade.local/api/update_score', { method: 'POST', headers: {'Content-Type': 'application/json'}, credentials: 'include', // 关键！携带Cookie body: JSON.stringify({studentId: 1001, score: 0}) }); </script>

如果服务器端没有检查Content-Type头部是否为预期值（如application/json），或者没有验证请求来源（Origin/Referer），也没有使用Token，那么这个攻击就会成功。

防御思路：对于API，除了使用CSRF Token，还可以采用以下方式：

  • 使用自定义请求头：如前文所述的双重Cookie验证，要求前端在请求中设置一个自定义头（如X-Requested-With: XMLHttpRequest），后端验证该头是否存在。因为浏览器在发起跨域请求时，默认不允许前端代码添加某些自定义头（这属于CORS预检请求的范畴），这能在一定程度上增加攻击难度，但并非绝对安全。
  • 采用Token-Based认证（如JWT）替代Cookie：将认证信息放在请求头（如Authorization: Bearer <token>）中，而不是Cookie里。由于浏览器不会自动在跨站请求中携带Authorization头，因此从根本上避免了CSRF。但需要注意保护Token不被XSS窃取。

6.3 绕过有缺陷的Token验证

有时，应用虽然使用了Token，但实现上有漏洞：

  • Token未绑定会话：所有用户共享同一个静态Token，或者Token生成算法可预测。
  • Token验证逻辑可绕过：服务器端验证Token时，存在逻辑缺陷。例如，先检查Token是否存在，如果存在则验证，如果不存在则跳过验证。攻击者只需在请求中不提供Token字段即可绕过。
  • Token泄露：如果网站同时存在XSS漏洞，攻击者可以通过XSS窃取到有效的Token。

在靶场测试中，可以尝试以下方法：

  1. 使用两个不同的账户A和B。
  2. 用A账户登录，获取其表单中的CSRF Token。
  3. 用B账户登录，在修改B自己信息的请求中，尝试使用A账户的Token。如果成功，说明Token未与用户绑定。
  4. 尝试删除请求中的Token参数，或者将其值改为空、0、null等，观察服务器反应。

7. 总结与反思：安全思维的建立

通过这个“Grade靶场”的CSRF漏洞利用实战，我们完成了一次完整的安全攻防推演。从环境搭建、原理分析、手工利用、工具辅助，到深入挖掘、组合攻击，最后回归防御与修复。CSRF作为一个“古老”但至今仍常见的漏洞，其核心教训在于：服务器不能无条件信任任何来自浏览器的、带有合法Cookie的请求。

对于开发者而言，修复CSRF漏洞在技术上并不复杂，同步令牌模式几乎是标配。但更重要的是将安全思维融入开发流程的每一步：在设计API时考虑HTTP方法的语义，在实现表单时第一时间引入CSRF防护中间件，在代码审查时检查关键操作是否有二次验证，在部署上线前进行必要的安全扫描。

对于安全测试人员和安全爱好者，CSRF是一个绝佳的入门漏洞。它逻辑清晰，利用简单，但又能引申出同源策略、Cookie机制、会话管理、前后端交互等一系列Web安全基础知识。通过手动构造PoC，你能更深刻地理解HTTP协议和浏览器行为。在掌握了基础之后，再去挑战那些与XSS、逻辑漏洞结合的复杂场景，你的Web安全实战能力会得到扎实的提升。

最后，记住所有安全研究的首要原则：仅在合法授权和可控的环境中进行测试。靶场就是我们安全的练兵场，在这里磨砺技术，是为了在真实世界中更好地构建和保护我们的数字家园。