PHP开发中的CSRF攻击与防御实践-代码聚汇网

PHP开发中的CSRF攻击与防御实践

Coffee Wu·2026-08-19·阅读 21 GEO检测（免费）

CSRFPHP安全Web安全

|难度：普通|阅读约 13 分钟

1. CSRF攻击的本质与危害

CSRF（Cross-Site Request Forgery）是一种让用户在不知情的情况下以当前登录状态执行非预期操作的攻击方式。想象这样一个场景：你正在银行网站操作转账，同时打开了另一个标签页浏览论坛。攻击者可能在这个论坛页面中植入恶意代码，利用你已登录的银行会话悄悄发起转账请求。

CSRF攻击能够成功的关键在于：

用户已经登录目标网站（如银行系统）
用户的浏览器会自动携带该网站的认证cookie
攻击者可以诱导用户访问恶意页面

在PHP开发中，这类漏洞尤其危险，因为PHP的会话管理机制默认依赖cookie，而表单提交又极为常见。我曾在一个电商项目中遇到过真实案例：攻击者构造了自动提交的POST表单，当管理员浏览被篡改的页面时，后台商品价格被批量修改。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. PHP中CSRF的典型攻击场景

2.1 表单提交漏洞

最常见的攻击载体是HTML表单。假设有一个修改用户密码的PHP接口：

php复制// change_password.php
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    $newPassword = $_POST['new_password'];
    // 直接修改密码...
}

攻击者只需在自己的网站上放置如下代码：

html复制<form action="https://victim.com/change_password.php" method="POST">
    <input type="hidden" name="new_password" value="hacked123">
</form>
<script>document.forms[0].submit();</script>

2.2 图片URL攻击

即使不使用表单，简单的GET请求也可能造成危害：

php复制// transfer.php
if (isset($_GET['amount']) && isset($_GET['to_account'])) {
    $account->transfer($_GET['amount'], $_GET['to_account']);
}

攻击者可以诱导用户加载一个"图片"：

html复制<img src="https://victim.com/transfer.php?amount=1000&to_account=ATTACKER">

2.3 AJAX请求风险

现代前端技术使得攻击更加隐蔽：

javascript复制fetch('https://victim.com/api/update_profile', {
    method: 'POST',
    body: JSON.stringify({email: 'attacker@example.com'}),
    credentials: 'include' // 携带cookie
});

3. 防御CSRF的核心方案

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

这是最可靠的防御方案，实施步骤：

生成令牌并存储：

php复制// 在会话开始时
$_SESSION['csrf_token'] = bin2hex(random_bytes(32));

在表单中嵌入令牌：

php复制<form action="/submit" method="post">
    <input type="hidden" name="csrf_token" value="<?= $_SESSION['csrf_token'] ?>">
    <!-- 其他表单字段 -->
</form>

验证令牌：

php复制if ($_POST['csrf_token'] !== $_SESSION['csrf_token']) {
    die('CSRF token validation failed');
}

关键细节：令牌应该每个会话唯一，且单次使用。我建议对敏感操作（如支付）使用一次性令牌。

PHP 7.3+支持设置SameSite属性：

php复制session_set_cookie_params([
    'lifetime' => 86400,
    'path' => '/',
    'domain' => $_SERVER['HTTP_HOST'],
    'secure' => true,
    'httponly' => true,
    'samesite' => 'Strict'
]);

这种方式的优点是：

浏览器会自动阻止跨站请求携带cookie
不需要修改现有业务逻辑
兼容性良好（主流浏览器均支持）

3.3 双重提交Cookie验证

适合前后端分离架构的方案：

前端从cookie读取令牌：

javascript复制const token = document.cookie.match(/csrf_token=([^;]+)/)[1];

在自定义头或请求体中携带：

javascript复制fetch('/api', {
    method: 'POST',
    headers: {
        'X-CSRF-TOKEN': token
    }
});

后端验证一致性：

php复制if ($_COOKIE['csrf_token'] !== $_SERVER['HTTP_X_CSRF_TOKEN']) {
    http_response_code(403);
    exit;
}

4. PHP框架中的CSRF防护实践

4.1 Laravel的实现

Laravel内置了CSRF中间件：

php复制// 表单中自动生成
@csrf

// 验证逻辑（VerifyCsrfToken中间件）
if ($this->isReading($request) || $this->tokensMatch($request)) {
    return $next($request);
}

最佳实践：

对API路由适当豁免（在$except数组中配置）
使用X-CSRF-TOKEN头处理AJAX请求
定期刷新令牌（通过Session配置）

4.2 Symfony的解决方案

Symfony提供多种防护方式：

twig复制{# 模板中 #}
<input type="hidden" name="token" value="{{ csrf_token('delete-item') }}">

{# 控制器验证 #}
$this->isCsrfTokenValid('delete-item', $submittedToken);

特色功能：

支持不同操作使用不同令牌
可配置令牌生存期
与表单组件深度集成

4.3 ThinkPHP的防护机制

最新版本中通过中间件实现：

php复制// 配置config/csrf.php
return [
    'expire'    => 3600,
    'token_name'=> '__token__',
];

// 模板中使用
{:token_field()}

注意事项：

需要手动开启中间件
AJAX请求需携带X-CSRF-TOKEN
与缓存机制配合使用时需注意令牌同步

5. 高级防护与边缘案例处理

5.1 文件上传的特殊处理

文件上传表单需要特殊处理，因为：

大文件上传可能超时导致令牌失效
多部分表单需要调整令牌位置

解决方案：

php复制// 在表单开始前放置令牌
<form enctype="multipart/form-data">
    <input type="hidden" name="csrf_token" value="...">
    <!-- 文件输入 -->
</form>

// 或者使用JavaScript追加
document.getElementById('fileForm').appendChild(tokenInput);

5.2 多标签页操作冲突

当用户同时打开多个标签页时：

后生成的令牌会使之前的失效
可能导致合法请求被拒绝

优化方案：

php复制// 允许多个有效令牌
$_SESSION['csrf_tokens'] = [
    bin2hex(random_bytes(32)) => time()
];

// 验证时遍历检查
foreach ($_SESSION['csrf_tokens'] as $token => $time) {
    if (hash_equals($token, $inputToken) && time() - $time < 3600) {
        unset($_SESSION['csrf_tokens'][$token]);
        return true;
    }
}

5.3 性能优化技巧

高并发下的优化手段：

使用加密签名替代存储（JWT模式）

php复制$token = bin2hex(random_bytes(16));
$signature = hash_hmac('sha256', $token, 'secret_key');
setcookie('csrf_token', $token.'.'.$signature);

缓存令牌替代会话存储
对只读操作放宽验证

6. 测试与漏洞挖掘

6.1 手工测试方法

抓取目标请求（使用Burp Suite或浏览器开发者工具）
移除CSRF令牌后重放请求
检查是否仍然成功执行

6.2 自动化扫描工具

推荐工具组合：

OWASP ZAP的主动扫描
Burp Suite的CSRF PoC生成器
自定义脚本检测缺失令牌

6.3 常见误报处理

以下情况可能误判为漏洞：

公开API接口（设计上无需防护）
静态资源请求
已通过其他方式防护的接口（如二次认证）

验证方法：

检查响应头是否有安全控制（如CORS策略）
确认业务影响程度
测试不同用户上下文中的行为

7. 应急响应与补救措施

当发现CSRF漏洞时：

立即评估影响范围：

哪些功能受影响
可能泄露的数据类型
攻击门槛（是否需要认证）

临时修复方案：

nginx复制# 在Nginx层添加验证
location ~ \.php$ {
    if ($http_referer !~* "^https://yourdomain.com") {
        return 403;
    }
}

长期解决方案：

全站部署令牌验证
关键操作添加二次认证
实施安全头（如Content-Security-Policy）

用户通知：

强制密码重置
会话失效处理
安全公告发布

在最近一次安全审计中，我们发现一个通过图片标签触发的CSRF漏洞，攻击者可利用它修改用户邮箱。通过实施令牌验证+SameSite Cookie双重防护，最终彻底解决了这个问题。