CSRF Token 生成机制详解：为何刷新页面会累积多个 Token？

本文解析 csrf token 在 php 中重复生成的根本原因，指出原始代码每次请求都新增 token 的逻辑缺陷，并提供单例式 token 管理的正确实现方案，确保每次会话仅维护一个有效 token，兼顾安全性与可预测性。

本文解析 csrf token 在 php 中重复生成的根本原因，指出原始代码每次请求都新增 token 的逻辑缺陷，并提供单例式 token 管理的正确实现方案，确保每次会话仅维护一个有效 token，兼顾安全性与可预测性。

在实现 CSRF 防护时，Token 的生命周期管理至关重要。原始代码中的 getToken() 函数存在一个关键逻辑错误：它未区分“初始化”与“复用”，而是每次调用都生成并追加新 Token 到 $_SESSION[‘tokens’] 数组中。这意味着：

• 首次访问：创建第一个 Token → 数组含 1 项
• 第一次刷新：生成第二个 Token 并追加 → 数组含 2 项
• 第二次刷新：再生成第三个 Token 并追加 → 数组含 3 项
• ……以此类推，Token 数量随刷新次数线性增长

这不仅造成内存浪费、增加校验复杂度，更违背 CSRF Token 的设计原则：每个用户会话应仅关联一个（或一组有限、轮换的）有效 Token，且表单提交时需严格比对当前有效 Token。

✅ 正确做法是采用“懒初始化 + 单例复用”模式：

function getToken() {
    // 若 session 中尚未设置 token，则生成并持久化
    if (!isset($_SESSION['csrf_token'])) {
        $_SESSION['csrf_token'] = bin2hex(random_bytes(32));
    }
    // 总是返回已存在的 session token，绝不重复生成
    return $_SESSION['csrf_token'];
}

// 使用示例
session_start(); // 确保 session 已启动
$token = getToken();

// 输出验证（刷新多次后始终只显示 1 个 token）
var_dump($_SESSION['csrf_token']); // string(64) "a1b2c3..."

? 关键改进点：

• 状态感知：检查 $_SESSION[‘csrf_token’] 是否存在，而非 $_SESSION[‘tokens’] 这一易混淆的数组结构；
• 单一来源：Token 存储为字符串而非数组，避免无意义累积；
• 幂等返回：函数调用结果恒定（同会话内），便于前端统一嵌入 <input type=”hidden” name=”csrf_token” value=”<?= htmlspecialchars($token) ?>”>；
• 安全增强建议：生产环境可进一步结合 Token 绑定（如绑定用户 Agent 或 IP 片段）、过期机制（如 $_SESSION[‘csrf_expires’] = time() + 3600）及一次性使用策略（提交后立即失效并重置）。

⚠️ 注意事项：

• 务必在调用 getToken() 前执行 session_start()；
• 避免在 AJAX 请求或表单重复提交场景中多次调用该函数——它本就应被调用一次、复用全程；
• 若需支持多 Tab 场景下的 Token 同步，可考虑引入轻量级锁或基于时间戳的 Token 刷新策略，但默认单 Token 模式已满足绝大多数应用需求。

通过修正 Token 生成逻辑，你不仅能解决“越刷越多”的异常现象，更能构建出符合 OWASP 标准、稳定可靠的 CSRF 防护基础。