必须用 random_bytes() 生成 CSRF Token，禁用 md5() 和 mt_rand()；正确做法是 bin2hex(random_bytes(16)) 或 bin2hex(random_bytes(32))。
PHP里生成CSRF Token必须用 random_bytes()，别碰 md5() 和 mt_rand()
弱随机源生成的Token等于把锁芯换成橡皮泥——攻击者几秒就能捏出钥匙。比如 md5(time().rand())，时间戳可推测、rand() 可被 seed 推断，自动化工具一跑就命中。
✅ 正确做法：PHP 7+ 直接用 bin2hex(random_bytes(16))（32 字符十六进制）或 bin2hex(random_bytes(32))（64 字符，更保守）；
⚠️ PHP openssl_random_pseudo_bytes()，并检查 $crypto_strong 返回 true；
❌ 错误写法示例：uniqid().mt_rand()、sha1(microtime())、任何带时间或进程 ID 的拼接；
立即学习“PHP免费学习笔记（深入）”；
生成后立刻存入 $_SESSION['csrf_token']，且确保 session_start() 已调用——没启 session，写进去也白写，下次读就是 Undefined index。
验证时必须用 hash_equals()，不能用 == 或 ===
直接比较会暴露响应时间差异，攻击者靠毫秒级延迟就能逐位爆破 Token。这不是理论风险，是已被实操复现的时序攻击路径。
验证逻辑要包含三要素：
- 检查
$_POST['csrf_token']是否存在 - 用
hash_equals($_SESSION['csrf_token'] ?? '', $_POST['csrf_token'])恒定时间比对 - 比对失败立即
die()或抛出异常，不执行后续逻辑
注意：如果 Token 存的是数组结构（如含 ip_hash 和 created_at），比对前先提取字符串值，再传给 hash_equals()；别把整个数组塞进去。
验证通过后必须销毁或轮换，不能“一次生成，反复使用”
留着旧 Token 就等于给攻击者发了张长期有效的门禁卡。用户开两个标签页同时提交？那不是妥协理由，而是该上令牌池机制的信号。
基础方案（单页友好）：
- 验证成功后立刻
unset($_SESSION['csrf_token']) - 下个表单页面重新生成新 Token
进阶方案（多标签页支持）：
- 存
$_SESSION['csrf_tokens'] = [bin2hex(random_bytes(16)), ...]（最多保留 3–5 个） - 验证时遍历比对，匹配即
array_splice()清除该项 - 每次新生成都
array_unshift()入栈，超量则array_pop()
⚠️ 关键细节：销毁操作后务必确认 session 已写回，避免因 session_write_close() 提前调用导致失效。
AJAX 请求的 Token 注入不能靠手写，得统一拦截点
表单里加 <input type="hidden"> 是基础，但 JS 发起的 fetch 或 XMLHttpRequest 很容易漏传、硬编码、甚至写死在前端代码里——防护断层就发生在这里。
推荐做法：
- 前端所有 POST/PUT/DELETE 请求，统一从
document.querySelector('meta[name="csrf-token"]')读取（服务端渲染时注入<meta name="csrf-token" content="xxx">） - 或统一设置请求头：
headers: { 'X-CSRF-Token': token } - 后端从
$_SERVER['HTTP_X_CSRF_TOKEN']或getallheaders()['X-CSRF-Token']读取并校验
GET 请求也不能豁免——只要带副作用（如 /api/logout、/admin/delete?id=123），就必须传 csrf_token 查询参数并校验。
真正容易被忽略的点是：Token 绑定上下文。只存一个字符串到 session，等于默认允许同 IP 下所有标签页、甚至恶意 iframe 共享它。至少得加 ip_hash 和 created_at，验证时一并比对。
