PHP项目中如何防止CSRF攻击？

wen PHP项目 2026-06-19 4

PHP项目中如何防止CSRF攻击：全面防护策略与实战指南

📚 目录导读

【什么是CSRF攻击？——核心原理与危害】
【PHP项目CSRF攻击的典型场景】
【CSRF防护的黄金法则：Token验证机制】
【实战代码：双Token验证（Session+表单）】
【进阶防护：SameSite Cookie属性】
【Referer验证：辅助防线与局限性】
【框架内置防护：Laravel/Symfony/ThinkPHP实例】
【常见问题问答（QA）】
【构建多层防护体系】

什么是CSRF攻击？——核心原理与危害

CSRF（Cross-Site Request Forgery，跨站请求伪造）是一种利用用户已登录身份，诱导用户在不知情的情况下执行恶意操作的攻击方式，攻击者通过构造恶意链接或表单，在用户访问第三方网站时，自动向目标站点发起带有用户凭证（如Cookie）的请求。

PHP项目中如何防止CSRF攻击？

攻击流程示例：

用户A登录了银行网站bank.com（Session未过期）。
用户A访问了攻击者控制的恶意网站evil.com。
evil.com页面包含一个隐藏的表单，自动提交到bank.com/transfer?amount=1000&to=attacker。
由于浏览器自动携带bank.com的Cookie,服务器误认为这是用户A的合法操作。

核心危害：修改密码、转账、发布内容、删除数据等,且用户完全无感知。

PHP项目CSRF攻击的典型场景

表单提交：用户编辑资料、发表评论、触发支付。
API接口：RESTful API（如 /api/user/delete POST请求）。
文件上传：诱导用户上传恶意文件。
异步请求：AJAX或Fetch发起的跨站请求。

关键点：任何改变服务器状态的请求（GET/POST/PUT/DELETE）都可能成为攻击目标，注意：GET请求尤其危险，因为攻击者只需构造一个<img>标签即可触发。

CSRF防护的黄金法则：Token验证机制

核心思想：服务器生成一个随机且唯一的Token，嵌入表单或请求头中，每次请求时验证Token的合法性，攻击者无法预知Token值,因此无法伪造合法请求。

Token设计原则：

不可预测性：使用强随机数生成（如random_bytes()）。
一次性：每次提交后刷新Token（或结合时间窗口）。
绑定用户：Token与当前用户Session关联。
安全传输：通过HTTPS传输,防止中间人截取。

实现步骤：

用户访问表单页面时,服务器生成Token并存入Session。
将Token作为隐藏字段嵌入表单（或放入请求头）。
用户提交表单时,服务器比对Session中的Token与提交的Token。
匹配则处理请求,否则拒绝。

实战代码：双Token验证（Session+表单）

1 生成Token（PHP函数）

function generateCsrfToken(): string {
    if (empty($_SESSION['csrf_token'])) {
        // 使用random_bytes生成32字节随机数，并转换为十六进制
        $_SESSION['csrf_token'] = bin2hex(random_bytes(32));
    }
    return $_SESSION['csrf_token'];
}

2 嵌入表单（HTML）

<form action="/submit.php" method="POST">
    <input type="hidden" name="csrf_token" value="<?= generateCsrfToken() ?>">
    <input type="text" name="username">
    <button type="submit">提交</button>
</form>

3 验证Token（表单处理）

session_start();
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    $submittedToken = $_POST['csrf_token'] ?? '';
    $sessionToken = $_SESSION['csrf_token'] ?? '';
    if (!hash_equals($sessionToken, $submittedToken)) {
        // 使用hash_equals防止时间差攻击
        die('CSRF验证失败，请求已拒绝');
    }
    // 验证通过，处理业务逻辑
    // 可选：刷新Token（防止重复使用）
    unset($_SESSION['csrf_token']);
}

4 框架集成（Laravel示例）

Laravel默认启用CSRF防护，所有POST请求需携带csrf_token：

// Blade模板
<form method="POST" action="/profile">
    @csrf  <!-- 自动生成隐藏字段 -->
    ...
</form>
// 或通过JavaScript获取Token
<meta name="csrf-token" content="{{ csrf_token() }}">

进阶防护：SameSite Cookie属性

SameSite是Cookie的一个安全属性，用于控制Cookie在跨站请求时的发送行为，PHP 7.3+原生支持。

三种模式：

Strict：完全禁止跨站发送Cookie（最严格，但影响用户体验，如第三方登录）。
Lax：允许部分安全请求（如GET链接、表单提交）携带Cookie。推荐作为默认值。
None：不限制，但必须配合Secure（仅HTTPS）。

PHP设置示例：

// 全局设置（php.ini或代码中）
session_set_cookie_params([
    'lifetime' => 0,
    'path' => '/',
    'domain' => '',
    'secure' => true, // 仅HTTPS
    'httponly' => true,
    'samesite' => 'Lax' // 阻止大部分CSRF
]);

注意：SameSite不能完全替代Token验证，因为攻击者仍可利用Lax模式下的POST表单提交。建议与Token结合使用。

Referer验证：辅助防线与局限性

原理：检查HTTP请求头中的Referer或Origin字段,判断请求是否来自本域名。

PHP实现：

$referer = $_SERVER['HTTP_REFERER'] ?? '';
$allowedHost = 'https://example.com';
if (strpos($referer, $allowedHost) !== 0) {
    die('非法来源');
}

局限性：

Referer可能被浏览器隐私设置禁用（如隐私模式）。
某些浏览器插件可能修改Referer。
攻击者可通过<meta>标签伪造Referer（旧版浏览器）。
不适用于同一站点的子域名或路径跳转。

仅作为辅助,不能作为唯一防护。

框架内置防护：Laravel/Symfony/ThinkPHP实例

Laravel（最成熟）

自动启用：所有路由默认受保护（web中间件组）。
排除特定路由：protected $except = ['webhook/*']。
AJAX请求：使用X-CSRF-TOKEN请求头。

Symfony

通过Form组件自动生成Token：{{ form_row(form._token) }}。
全局配置：framework.csrf_protection。

ThinkPHP（国内常用）

使用token方法生成隐藏域：{:token()}。
验证规则：自动验证或validate()方法。

框架优势：拦截器自动处理Token生成与验证,开发者只需配置即可。

常见问题问答（QA）

Q1：我的API接口也容易受CSRF攻击吗？ A：是的，建议为每个API请求添加Token（通过请求头X-CSRF-TOKEN），对于无状态API（如JWT认证）,可以使用自定义请求头或双重Cookie验证。

Q2：Token可以被攻击者获取吗？ A：如果网站存在XSS漏洞，攻击者可窃取Token。防止XSS是CSRF防护的前提，输出时使用htmlspecialchars()转义，并设置httponly Cookie。

Q3：Token每次刷新是否必要？ A：建议在敏感操作（如转账）后刷新Token，对于普通操作（如评论），可设置Token生命期（如30分钟），一次性Token安全性更高,但会增加服务器开销。

Q4：Samesite=Lax为何不彻底解决CSRF？ A：因为Lax模式下，POST表单仍会携带Cookie（如果来自第三方网站的链接跳转），例如用户点击恶意网站上的<form>自动提交，只要用户之前访问过目标站，Cookie依然有效,所以仍需Token验证。

Q5：如何处理AJAX请求的CSRF？ A：JavaScript从<meta>标签或API获取Token，然后添加到请求头：fetch('/api', { headers: {'X-CSRF-TOKEN': token} }),Laravel默认支持。

构建多层防护体系

单点防护不足，多层防御是王道：

防护层	优先级	实现难度	说明
Token验证	强制	低	核心防护，必须使用
SameSite=Lax	建议	极低	一次设置，全局生效
Referer校验	辅助	低	作为补充，防钓鱼
HTTPS加密	基础	中	防止中间人窃取Token
输入验证	基础	低	防XSS间接窃取Token

最终推荐方案：

所有需要身份认证的页面启用CSRF Token（写入表单或头）。
设置Session Cookie的SameSite=Lax和Secure。
检查Origin头（服务器端）,拒绝未知来源。
定期刷新Token（尤其敏感操作后）。
使用现代框架（如Laravel/ThinkPHP）的内置防护。

记住：CSRF防护不是可选项，而是安全基线，即使小型PHP项目，也应至少实现Token验证和SameSite两种措施,安全从每一行代码开始。

本文综合OWASP官方文档、PHP手册、Laravel/Symfony安全指南等内容，结合实战经验整理。