当前位置：首页 > news >正文

CSRF攻击原理与防御实战：从Pikachu/DVWA靶场到现代Web安全实践

news 2026/7/1 10:14:48

1. 从一次“被点赞”说起：理解CSRF攻击的本质

前几天，我团队里一个刚入行的安全工程师小张，气冲冲地跑来找我，说他的社交媒体账号“被操作”了。他明明在认真写代码，后台却显示他给一堆完全不认识的营销号点了赞，甚至还自动转发了一条广告。他第一反应是账号被盗了，但检查登录记录、改密码、开二次验证，一通操作下来，问题依旧。直到他排查到浏览器里一个很久没关的标签页——那是一个他之前登录过的、安全性有问题的内部测试论坛。问题就出在这里：他在不知情的情况下，浏览器自动向社交媒体网站发送了“点赞”和“转发”的请求，并且成功了。这就是一个典型的跨站请求伪造攻击，也就是我们常说的CSRF。

简单来说，CSRF攻击就是“借刀杀人”。攻击者利用你浏览器里已经存在的登录状态（比如你登录了网银、邮箱、社交平台后没有退出），诱骗你的浏览器向目标网站发送一个它精心构造的恶意请求。因为你的浏览器会自动带上你的登录凭证（如Cookie），目标网站会认为“哦，这是用户本人发来的合法操作”，于是乖乖执行，比如转账、改密码、发微博。整个过程，你作为用户可能完全感知不到，攻击者甚至不需要知道你的密码。

为什么我们今天还要反复聊CSRF？因为它太“经典”了。在OWASP Top 10安全威胁榜单里，CSRF曾长期占据高位，虽然随着防护意识的普及，其直接排名有所下降，但由CSRF思想演变出的、或与之结合的攻击方式从未消失。尤其是在各种后台管理系统、API接口、以及一些对历史包袱较重的应用中，CSRF漏洞依然常见。像pikachu、DVWA、74cms这类专门用于安全学习和测试的靶场，都把CSRF作为必考科目，就是因为它是理解Web安全基础逻辑的绝佳案例。

2. CSRF攻击的核心原理与实现方式拆解

要防御CSRF，必须先彻底理解它如何工作。这背后的核心逻辑，是Web赖以运行的基础协议——HTTP协议的无状态特性，以及浏览器为了用户体验而设计的“自动携带凭证”机制。

2.1 攻击链条的三要素

一次成功的CSRF攻击，必须同时满足三个条件，缺一不可：

用户已登录受信任网站A，并在本地（浏览器）生成了Cookie：这是攻击的“燃料”。没有这个登录态，后续请求就是未授权的。
用户在未登出网站A的情况下，访问了恶意网站B：这是攻击的“触发器”。网站B可能通过邮件、论坛、广告等任何方式诱导用户点击。
网站B中包含了指向网站A的恶意请求：这是攻击的“武器”。这个请求会利用浏览器自动携带Cookie的机制，伪装成用户本人的操作。

2.2 常见的攻击载体与请求伪造方式

攻击者如何把恶意请求塞给用户的浏览器呢？主要有以下几种方式，理解它们有助于我们在开发时进行针对性防护：

1. 自动提交的HTML表单（最常见）这是最经典、最直接的方式。恶意网站B的页面上隐藏着一个表单，这个表单的action指向目标网站A的敏感操作接口（如修改邮箱的URL），表单里填好了攻击者预设的参数（如新的邮箱地址）。页面加载时，通过一段简单的JavaScript自动提交这个表单。

<!-- 恶意网站B上的页面代码 --> <body onload="document.forms[0].submit()"> <form action="https://bank.example.com/transfer" method="POST"> <input type="hidden" name="to" value="attacker_account" /> <input type="hidden" name="amount" value="10000" /> <!-- 其他必要参数 --> </form> </body>

用户一旦访问这个页面，表单立刻被提交，一个携带用户Cookie的转账请求就悄无声息地发往了银行网站。

2. 自动加载的IMG/SCRIPT标签对于使用GET方法的敏感操作（这本身是错误的设计，但确实存在），攻击更加简单。只需要在恶意页面插入一个资源标签，其src属性就是目标URL。

<img src="https://social.example.com/like?post_id=12345" width="0" height="0" />

当浏览器解析到这段代码，它会尝试去加载这个“图片”，实际上就是向social.example.com发起了一个GET请求，如果用户登录了该社交网站，这个“点赞”请求就会生效。<script>,<iframe>等标签也可以被类似利用。

3. 诱骗点击的链接（需要一点交互）这种方式需要用户点击，但链接可能被伪装成“抽奖”、“查看照片”等极具诱惑性的文本或按钮。

<a href="https://bank.example.com/transfer?to=attacker&amount=10000"> 点击领取您的百万红包！ </a>

注意：现代浏览器默认的SameSite Cookie策略（后面会详述）对这类通过第三方站点发起的跨站POST请求（如表单提交）有了很好的缓解作用，但对于GET请求以及一些老旧浏览器，威胁依然存在。绝不能将安全完全寄托于浏览器特性。

2.3 一个简单的攻击场景模拟

让我们用pikachu靶场（一个知名的Web漏洞练习平台）里的CSRF漏洞来还原一下攻击过程，这样会更直观：

环境：pikachu平台有一个存在CSRF漏洞的“修改个人信息”页面。假设它对应的真实网站是https://vulnerable-app.com/user/update_profile。
用户行为：你登录了vulnerable-app.com，然后没有关闭页面，接着去浏览另一个标签页。
攻击触发：你在另一个标签页点开了一封钓鱼邮件里的链接，这个链接指向攻击者控制的网站evil-site.com。
恶意页面：evil-site.com的页面里隐藏着一段代码，它会自动向https://vulnerable-app.com/user/update_profile提交一个表单，将你的邮箱修改为攻击者的邮箱。
结果：由于你的浏览器里存有vulnerable-app.com的登录Cookie，这个修改请求被服务器认为是合法操作，执行成功。攻击者随后可以使用“找回密码”功能，通过他控制的邮箱重置你的密码，从而完全接管你的账户。

这个模拟过程清晰地展示了CSRF的隐蔽性和危害性：用户只是在浏览网页，核心账户信息就可能已经易主。

3. 深入靶场：从Pikachu与DVWA看CSRF漏洞的实战挖掘

理论学习之后，最好的巩固方式就是动手。Pikachu和DVWA这两个靶场提供了非常友好的CSRF漏洞实战环境。我们以Pikachu为例，拆解一下漏洞挖掘的思路和流程，这对于安全测试人员或想提升代码安全性的开发者都很有价值。

3.1 Pikachu CSRF漏洞关卡分析

在Pikachu平台的CSRF模块下，通常会有“GET型”和“POST型”两种漏洞场景。

GET型CSRF漏洞挖掘：

目标定位：找到一处通过GET请求参数进行敏感操作的功能点，例如http://target/user/delete?id=123。
登录状态：首先，你需要用一个测试账号（如lucy/password）正常登录系统。
请求分析：打开浏览器开发者工具（F12）的“网络(Network)”标签页，进行一次正常的删除操作。观察这个请求：
- 请求方法：确认是GET。
- 请求URL：记录完整的URL和参数，例如/csrf/get/del.php?id=1。
- 认证凭证：查看请求头，确认Cookie被自动发送。
漏洞验证：新开一个浏览器标签页（或无痕窗口），在未登录的情况下，直接访问上一步记录的完整URLhttp://pikachu-host/csrf/get/del.php?id=1。正常情况下应该提示未登录或失败。
构造攻击：在另一个标签页（保持已登录pikachu的状态），访问一个你自己搭建的简单HTML页面，页面内容就是一张图片，其src指向那个删除URL。
```
<img src="http://pikachu-host/csrf/get/del.php?id=2" />
```
结果观察：刷新pikachu的用户列表页面，你会发现ID为2的用户被删除了。这就证明了，只要用户处于登录状态，任何能诱使其浏览器发起这个GET请求的途径，都能完成攻击。

POST型CSRF漏洞挖掘：POST型因为需要提交表单数据，稍微复杂一点，但原理相通。

目标定位：找到一处通过POST修改数据的功能，如修改个人信息。
请求分析：正常操作一次，在开发者工具中捕获这个POST请求。不仅记录URL，还要记录所有的表单参数（name,email,phone等）及其格式。

构造恶意页面：创建一个HTML文件，里面包含一个隐藏的<form>，其action指向目标URL，method为POST，表单内填充好攻击者想要修改的值（比如把邮箱改成攻击者的）。

<form id="attackForm" action="http://pikachu-host/csrf/post/modify.php" method="POST"> <input type="hidden" name="name" value="Lucy" /> <input type="hidden" name="email" value="hacker@evil.com" /> <input type="hidden" name="phone" value="13800138000" /> </form> <script>document.getElementById('attackForm').submit();</script>

漏洞验证：在已登录pikachu的浏览器中打开这个恶意HTML文件。页面会自动提交表单，完成信息修改。查看pikachu的个人信息页，确认邮箱已被篡改。

实操心得：在测试POST型CSRF时，务必注意请求的Content-Type。如果是application/x-www-form-urlencoded，用上述表单方式即可。如果接口要求application/json，则需要使用JavaScript的fetch或XMLHttpRequest来构造请求，这涉及到跨域问题（CORS），但若目标站点CORS策略配置不当，攻击依然可能成功。这也是为什么单纯依赖“检查请求头”并不完全可靠。

3.2 DVWA靶场CSRF通关的进阶思考

DVWA将漏洞难度分为Low、Medium、High、Impossible四级，这为我们理解防护措施的演进提供了完美路线图。

Low级别：毫无防护。密码修改功能直接通过GET请求带参数完成，如?password_new=123&password_conf=123&Change=Change。攻击构造与pikachu的GET型完全相同。
Medium级别：引入了简单的服务端校验——检查请求来源（HTTP Referer头）。代码会判断$_SERVER['HTTP_REFERER']是否包含本机域名（如127.0.0.1）。绕过方法：攻击者可以控制一个子域名，或者利用某些浏览器扩展、本地文件（file://协议）发起请求，这些场景下Referer可能为空或可控，从而绕过检查。这告诉我们，依赖Referer并不完全可靠。
High级别：引入了Anti-CSRF Token。服务器在生成修改密码页面时，会生成一个随机的、不可预测的Token，并将其放在表单的隐藏域中，同时存储在用户会话（Session）里。提交表单时，服务器会比对提交的Token和会话中的Token是否一致。关键点：Token是随用户、随会话、甚至随请求变化的，攻击者无法提前预知。这是目前最主流的防御方案之一。
Impossible级别：在High级别的基础上，增加了当前密码验证。即修改密码必须提供原密码。这从根本上将CSRF攻击无效化，因为攻击者无法得知用户的原密码。这给了我们一个重要的设计原则：对于极其敏感的操作（如资金交易、密码修改），强制进行二次认证（原密码、短信验证码、MFA）是终极安全手段。

通过逐级通关，你能清晰地感受到安全防护是如何层层加码，以及攻击与防御之间的博弈关系。

4. 构建防线：CSRF防护的现代最佳实践

了解了攻击原理和漏洞挖掘方法，我们最终要落实到防御上。现代Web开发中，防御CSRF需要一套组合拳，而不是单一依赖某项技术。

4.1 黄金标准：同步令牌模式

这是目前应用最广泛、最有效的防御手段。其核心流程如下：

令牌生成：当用户访问一个包含表单的页面（如修改资料页）时，服务器端生成一个高强度、加密安全的随机字符串（即CSRF Token）。这个Token与当前用户的会话（Session）绑定。
令牌下发：服务器将这个Token作为隐藏字段（<input type="hidden" name="csrf_token" value="...">）嵌入到返回给用户的HTML表单中。对于单页应用（SPA），也可以通过API在初始化时返回，由前端存储（如放在内存或非HttpOnly的Cookie中）。
令牌提交：用户提交表单时，这个Token会作为表单数据的一部分被提交到服务器。
令牌验证：服务器接收到请求后，从请求体中取出提交的Token，并与当前用户会话中存储的Token进行比对。只有两者完全一致，请求才被认为是合法的。

关键实现细节与注意事项：

Token的强度与存储：必须使用密码学安全的随机数生成器（如/dev/urandom,Crypto.getRandomValues()）生成足够长的Token（如32字节）。Token必须存储在服务器端会话中，绝不能仅放在Cookie里（因为Cookie会被浏览器自动发送，失去了验证意义）。
每会话或每请求：通常采用“每会话一个Token”已足够安全。对于安全性要求极高的场景（如金融交易），可以考虑“每请求一个Token”（即每次提交后旧Token失效，生成新Token），但这会带来用户体验上的复杂性（如不能使用浏览器后退按钮）。
对GET请求的防护：严格遵循HTTP规范，GET请求必须用于获取数据，绝不能用于执行状态变更操作。这样就从设计上杜绝了通过<img>、<script>标签发起的CSRF攻击。所有写操作（POST, PUT, DELETE, PATCH）都必须使用Token验证。

4.2 利用浏览器特性：SameSite Cookie属性

这是一个几乎零成本、效果显著的防御补充。通过设置Cookie的SameSite属性，你可以指示浏览器在跨站请求时是否发送特定的Cookie。

SameSite=Strict：最严格。Cookie仅在同站请求（即当前页面的域名与请求目标域名一致）时发送。这意味着用户从谷歌搜索结果点击链接进入你的网站，初始请求也不会携带登录Cookie，需要重新登录。用户体验影响较大。
SameSite=Lax（现代浏览器的默认值）：平衡了安全与体验。允许在顶级导航（如点击链接）的GET请求中发送Cookie，但禁止在跨站的POST请求或通过<img>,<script>等标签加载的请求中发送。这能有效防御大多数CSRF攻击。
SameSite=None：Cookie在所有上下文中发送，但必须同时设置Secure属性（即仅通过HTTPS传输）。主要用于需要跨站共享登录态的场景，如第三方登录、嵌入式组件。

部署建议：对于绝大多数应用，将登录态Cookie设置为SameSite=Lax; Secure是一个非常好的起点。它可以作为Token机制的有力补充，甚至能防御一些Token实现不当的漏洞。

4.3 双重验证：检查自定义请求头

对于主要使用AJAX（通过fetch或XMLHttpRequest）的API，特别是单页应用（SPA），可以利用CORS（跨源资源共享）机制来防御。思路是：让前端在发送非简单请求（如Content-Type为application/json的POST请求）时，添加一个自定义的HTTP头，例如X-Requested-With: XMLHttpRequest。

服务器端配置CORS策略，只允许来自可信域的请求携带这个自定义头。由于浏览器同源策略的限制，攻击者无法通过<form>或<img>标签在跨站请求中伪造这些自定义头。因此，服务器只需检查请求中是否存在这个预期的自定义头，就可以判断请求是否来自自己的前端应用。

局限性：这种方法依赖于浏览器正确实施CORS策略。如果服务器CORS配置过于宽松（如允许任意源*），此防护将失效。因此，它通常作为辅助手段，与Token机制结合使用。

4.4 架构级防御：敏感操作的二次认证

对于修改密码、转账、变更核心邮箱等最高风险操作，任何技术防护都可能有被绕过的理论风险。此时，业务逻辑层面的二次认证是最后、也是最坚固的防线。

密码确认：执行操作前，要求用户再次输入登录密码。
验证码：通过短信、邮件或认证器App发送一次性验证码。
生物识别：在移动端或支持的环境下，调用指纹或面部识别。

这确保了即使CSRF攻击成功发起了请求，在没有用户二次授权的情况下，操作也无法完成。

5. 开发中的避坑指南与常见问题排查

在实际开发和代码审计中，即使知道了原理，也常常会因细节疏忽而引入漏洞。以下是一些高频的“坑点”和排查技巧。

5.1 常见防护失效场景

Token生成与存储不当：
- 问题：Token不是随机生成的，或者使用了时间戳等可预测值。
- 排查：检查服务器生成Token的代码，确保使用了安全的随机源。检查Token是否与用户会话唯一绑定。
Token验证逻辑缺陷：
- 问题：服务器收到请求后，只是“检查Token是否存在”，而不是“检查Token是否与会话中的值匹配”。更糟糕的是，有的实现会先验证Token，如果验证失败，竟然还会继续执行业务逻辑！
- 排查：审计验证代码，必须是严格的字符串比对，且验证失败必须立即中断请求，返回明确的错误。
Token泄露：
- 问题：如果应用存在XSS（跨站脚本）漏洞，攻击者可以通过JavaScript窃取到页面中的Token。CSRF Token无法防御XSS，相反，XSS可以绕过CSRF防护。
- 排查：CSRF防护必须与XSS防护结合。确保Token不通过不安全的渠道（如URL参数、错误的Content-Type响应）泄露。对于SPA，避免将Token存储在可能被XSS攻击读出的全局变量中。
“宽松”的Referer检查：
- 问题：像DVWA Medium级别那样，只检查Referer是否“包含”某个字符串，而不是检查其协议、主机和端口是否完全匹配。攻击者可以注册www.attackerexample.com这样的域名来绕过。
- 排查：如果使用Referer检查（通常作为辅助），必须进行严格的全匹配，并处理好Referer头为空（某些隐私模式下）的边界情况。

5.2 安全配置检查清单

在项目上线前或进行安全审计时，可以对照以下清单进行检查：

检查项	安全要求	检查方法
敏感操作HTTP方法	所有状态变更操作（增删改）必须使用POST、PUT、DELETE等，禁止使用GET。	审查所有路由/控制器，确认写操作的HTTP方法。
CSRF Token部署	所有非只读的表单和API端点必须验证CSRF Token。	使用浏览器工具提交不带Token或错误Token的请求，观察是否被拒绝。
Token随机性	Token必须使用密码学安全随机数生成。	审查后端生成Token的代码。
Token绑定	Token必须与用户会话（Session）绑定。	尝试用一个用户的Token去操作另一个用户的会话，应失败。
Cookie的SameSite属性	会话Cookie应设置为`SameSite=Lax`或`Strict`。	在浏览器开发者工具的“应用(Application)”标签页查看Cookie属性。
CORS策略	对于API，CORS策略应严格限定来源（Origin），避免使用通配符`*`。	检查服务器的CORS响应头（`Access-Control-Allow-Origin`等）。
敏感操作二次认证	修改密码、支付等核心操作需二次验证。	走查核心业务流程。

5.3 针对现代前端框架的特别提示

如果你在使用React、Vue、Angular等框架，并且前后端完全分离（SPA）：

Token如何传递：后端应在用户登录后，通过一个安全的API端点将CSRF Token返回给前端。前端将其存储在内存（如Vuex/Redux store）或一个非HttpOnly的Cookie中。
Token如何附加：前端需要为每一个非GET的API请求，自动附加这个Token。通常可以通过配置全局的HTTP请求拦截器（如Axios的interceptors）来实现，将其放在请求头（如X-CSRF-Token）中。
框架内置防护：像Laravel、Django、Spring Security等主流后端框架，以及React的@rails/ujs等前端库，都内置了成熟的CSRF防护机制。优先使用这些经过社区验证的方案，而不是自己从头实现。

CSRF攻击的原理并不复杂，但它的防御需要开发者对Web的工作机制有清晰的认识，并在设计和编码的每一个环节保持警惕。从严格区分HTTP方法的语义，到正确实现Token验证，再到利用好浏览器的安全特性，这是一套完整的防御体系。下次当你编写一个表单或API接口时，不妨多花几分钟问问自己：这个端点，能抗住一次来自“另一个标签页”的偷袭吗？

查看全文

http://www.jsqmd.com/news/1101794/