表单中的CSRF攻击是什么？如何添加CSRF令牌？

CSRF攻击利用浏览器自动携带Cookie的特性，诱骗用户在已登录状态下执行非本意的操作。其成功在于攻击者通过恶意网页发起跨站请求，而服务器因收到有效会话Cookie误认为请求合法。防御核心是CSRF令牌机制：服务器为每个会话生成唯一、不可预测的随机令牌，嵌入表单隐藏字段，提交时比对会话中存储的令牌与表单提交的令牌，一致则放行，否则拒绝。此机制确保攻击者无法伪造含正确令牌的请求。HTML示例显示令牌作为隐藏输入字段存在于转账表单中；服务器伪代码展示验证流程——提取会话与表单令牌，匹配则执行操作，否则报错并记录安全警报。除令牌外，SameSite Cookie属性（推荐Lax模式）可有效限制跨站Cookie发送，增强防护；Referer头检查可作辅助但不可靠；双重提交Cookie模式利用同源策略限制，将令牌存于Cookie和表单并比对，减轻服务端存储压力。主流框架普遍集成自动化CSRF防护：Django通过{% csrf_token %}模板标签自动插入并由中间件验证；Flask-WTF在表单类中内置令牌，validate_on_submit()自动校验；Laravel用@csrf指令生成令牌，中间件拦截验证；Spring Security默认开启，要求非GET请求携带令牌，通过响应

表单中的CSRF攻击，简单来说，就是利用你已经登录某个网站的身份，在你不察觉的情况下，通过一个恶意网页，诱导你的浏览器向那个网站发送一个你本不打算执行的请求。这可能导致你的密码被修改、资金被转走，或者其他敏感操作被执行。添加CSRF令牌，是目前公认最有效且广泛使用的防御手段，它确保了每个提交的表单请求都确实是你本人意图发出的。

解决方案

要有效防御CSRF攻击，核心在于为每个用户的会话生成一个独一无二的、难以猜测的随机字符串——这就是CSRF令牌。这个令牌会在服务器端生成并存储在用户的会话中，同时也会被嵌入到用户即将提交的表单中，通常是一个隐藏字段。当用户提交表单时，服务器会同时接收到表单中携带的令牌和会话中存储的令牌。只有当这两个令牌完全匹配时，服务器才会认为这个请求是合法的，并允许其执行。如果令牌不匹配，或者缺失，请求就会被拒绝。

以下是一个概念性的HTML表单和服务器端验证的伪代码示例：

HTML表单：

<form action="/transfer_money" method="POST">     <input type="hidden" name="_csrf_token" value="[这里是服务器生成的随机令牌]">     <label for="recipient">收款人:</label>     <input type="text" id="recipient" name="recipient">     <label for="amount">金额:</label>     <input type="number" id="amount" name="amount">     <button type="submit">确认转账</button> </form>

服务器端验证逻辑（伪代码）：

function process_transfer_request(request):     // 从用户会话中获取存储的CSRF令牌     session_csrf_token = get_token_from_session(request.session)      // 从请求的表单数据中获取提交的CSRF令牌     form_csrf_token = request.form['_csrf_token']      // 比较两个令牌     if session_csrf_token and session_csrf_token == form_csrf_token:         // 令牌匹配，请求合法，执行转账操作         perform_money_transfer(request.user, request.form['recipient'], request.form['amount'])         return success_response()     else:         // 令牌不匹配或缺失，可能是CSRF攻击，拒绝请求         log_security_alert("CSRF token mismatch detected.")         return error_response("非法请求或会话过期。")

这种机制确保了攻击者无法轻易伪造一个有效的请求，因为他们无法预知或获取到正确的CSRF令牌。

CSRF攻击的原理是什么？它为什么会成功？

说起来，CSRF攻击能得逞，其实是利用了HTTP协议的一个“小聪明”——浏览器在发送请求时，会自动带上目标域名下的所有相关Cookie，包括会话Cookie。这听起来很方便，但正是这个特性，给攻击者留下了可乘之机。

想象一下这个场景：你刚刚登录了你的网上银行，浏览器里自然保存着你的登录会话Cookie。接着，你可能不小心点开了一个钓鱼网站或者一个恶意广告。这个恶意网站里，可能藏着一段看不见的HTML代码，比如一个自动提交的表单，或者一段JavaScript代码。这段代码的目标不是攻击你的浏览器本身，而是直接向你的网上银行地址发起一个请求，比如“转账1000元到某个账户”。

由于你的浏览器还“记住”着你银行的登录状态（通过会话Cookie），它在发送这个恶意请求时，会很“听话”地把你的银行会话Cookie也一并带上。银行服务器收到这个请求后，一看Cookie，哦，这是我的合法用户发来的请求啊！于是，在用户毫不知情的情况下，这笔转账就被执行了。这就是所谓的“困惑的代理人”问题——你的浏览器成了攻击者的代理人，去执行了你本不希望执行的操作。攻击者不需要知道你的密码，也不需要直接访问你的账户，只需要诱骗你的浏览器去帮你“完成”操作就行了。这种攻击方式的隐蔽性和高效性，着实让人头疼。

除了CSRF令牌，还有哪些方法能增强表单安全性？

当然，在网络安全领域，单一的防御措施往往不够，多层防御才是王道。除了CSRF令牌，我们还有其他一些辅助手段可以增强表单的安全性，虽然它们各有优缺点，不能完全替代令牌，但能提供额外的保障。

一个非常重要的补充是利用

SameSite

Cookie属性。现代浏览器普遍支持这个属性，它可以指示浏览器在跨站请求时如何发送Cookie。

• Strict

  模式：浏览器只会在同站请求中发送Cookie，完全阻止跨站请求携带Cookie。这对于CSRF防御效果极佳，但可能影响一些正常的跨站链接跳转（比如从外部网站点击链接回到你的网站，可能需要重新登录）。

• Lax

  模式：这是目前推荐的默认值。它允许顶级导航（比如用户点击一个链接）和GET请求携带Cookie，但会阻止POST请求和IFRAME等非顶级导航请求携带Cookie。这在很大程度上缓解了CSRF，同时又保留了基本的可用性。

• None

  模式：允许所有跨站请求携带Cookie，但必须同时设置

  Secure

  属性（即只能通过HTTPS发送）。这种模式下，

  SameSite

  属性对CSRF防御几乎没有帮助，需要依赖其他防御措施。

另一个可以考虑的是检查HTTP请求的

Referer

头。理论上，如果一个请求是从你的网站内部发出的，那么

Referer

头应该指向你的网站域名。服务器可以检查这个头信息来判断请求来源。然而，这个方法并不完全可靠。用户可以禁用

Referer

头，一些代理或防火墙也可能修改或移除它。更糟糕的是，在某些情况下，攻击者甚至可以伪造

Referer

头。所以，它只能作为一种辅助的、不那么强力的防御手段。

还有一种“双重提交Cookie”模式。这种方式下，服务器不存储CSRF令牌在会话中。相反，它在用户首次访问时生成一个令牌，并将这个令牌同时设置在用户的Cookie中（作为非HTTPOnly Cookie），同时也在表单中嵌入这个令牌。当用户提交表单时，服务器会比较表单中提交的令牌和Cookie中的令牌是否一致。由于恶意网站无法直接读取或设置另一个域的Cookie（受同源策略限制），它们就无法获取到正确的Cookie令牌来伪造请求。这种方式的好处是减轻了服务器的会话存储压力，但实现起来可能稍微复杂一些。

总的来说，CSRF令牌仍然是核心且最可靠的防御手段。而

SameSite

Cookie属性是极佳的补充，尤其是

Lax

模式，能在不牺牲太多用户体验的前提下提供显著的防御效果。其他方法，如

Referer

头检查，则更多是作为锦上添花，不能作为主要防线。

在主流Web框架中，CSRF令牌是如何工作的？

好消息是，对于我们开发者来说，大部分现代Web框架都已经把CSRF防御这件“麻烦事”处理得相当自动化和优雅了。这意味着我们不需要从零开始编写复杂的令牌生成、存储和验证逻辑，而是可以利用框架提供的强大功能，大大降低了实现难度和出错的风险。

以Python的Django框架为例，它的CSRF保护是默认开启的。你只需要在HTML模板的表单中简单地加上

{% csrf_token %}

这个模板标签，Django就会自动为你生成一个隐藏的input字段，里面包含了当前会话的CSRF令牌。当用户提交表单时，Django的中间件会自动拦截请求，并验证这个提交的令牌是否与用户会话中存储的令牌一致。如果令牌不匹配，或者请求方法是POST、PUT、DELETE等且没有携带有效令牌，Django会直接返回一个403 Forbidden错误，拒绝这个请求。

对于Python的Flask框架，如果你使用像Flask-WTF这样的表单扩展，CSRF保护也是内置的。当你定义一个

FlaskForm

子类时，它会自动包含一个CSRF令牌字段。在渲染表单时，令牌会自动添加到HTML中；在处理表单提交时，

form.validate_on_submit()

方法会自动进行CSRF令牌的验证。这使得在Flask中实现CSRF保护变得非常简洁和直观。

PHP的Laravel框架也有类似的机制。在Blade模板中，你只需要在表单内部添加

@csrf

指令，Laravel就会自动生成一个隐藏的CSRF令牌字段。Laravel的CSRF中间件会负责验证所有POST、PUT、PATCH、DELETE请求中的令牌。如果令牌验证失败，会抛出

TokenMismatchException

。

Java的Spring Security框架同样提供了强大的CSRF保护。它默认就是开启的，会为每个请求生成一个唯一的CSRF令牌，并要求所有非GET请求（如POST、PUT、DELETE等）都必须包含这个令牌。Spring Security通常通过将令牌放入HTTP响应头或HTML表单的隐藏字段中来传递，并在服务器端进行严格的验证。

这些框架在实现细节上可能有所不同，比如令牌的存储方式（会话、Cookie）、生成算法、验证流程等，但它们的核心思想都是一致的：在表单提交前生成并嵌入一个随机令牌，在服务器端接收请求时严格验证这个令牌。它们还处理了令牌的生命周期管理，例如令牌的过期、刷新等问题，这极大地减轻了开发者的负担，让我们能够更专注于业务逻辑的实现，同时确保了应用程序的安全性。所以，充分利用和理解你所用框架的CSRF保护机制，是构建安全Web应用的关键一步。