真正起作用的CSRF防护必须同时满足令牌强随机、绑定用户上下文、有时效、用完即毁；PHP 7+应使用random_bytes(16)，验证需检查存在性、时效性、IP哈希并立即销毁。
只存一个 $_SESSION['csrf_token'] 并比对字符串，基本等于没防。真正起作用的 CSRF 防护必须同时满足：令牌强随机、绑定用户上下文、有时效、用完即毁——缺一不可。
为什么 md5(time().rand()) 生成的 token 不安全
这类写法看似“随机”，实则熵极低，攻击者可在几秒内爆破出有效值。PHP 7+ 必须用加密安全的随机源：
-
random_bytes(16)是底线，bin2hex(random_bytes(16))得到 32 字符十六进制字符串 -
mt_rand()、uniqid()、time()组合都不可信，不抗预测也不抗重放 - 生成后应立刻存入 session，并附带元信息：
'created_at'、'ip_hash'（可选但推荐）
验证时必须同步检查三件事
收到 $_POST['token'] 后，仅用 hash_equals() 比对字符串远远不够：
- 确认
$_SESSION['csrf_token']['value']存在且非空 - 检查
time() - $_SESSION['csrf_token']['created_at'] （例如 1 小时过期） - 可选但强烈建议校验
ip_hash：hash_equals($_SESSION['csrf_token']['ip_hash'], hash('sha256', $_SERVER['REMOTE_ADDR'])) - 验证通过后，必须立刻
unset($_SESSION['csrf_token'])，否则一次窃取=无限重放
多标签页场景下怎么避免“提交失败”
用户开两个编辑页，刷新其中一个导致另一个 token 失效，体验极差。这时不能退回到“单 token + 不销毁”，而应改用「令牌池」：
- 每次生成新 token 时，保留最近 3 个有效 token（含时间戳和 ip_hash）
- 验证时遍历池子，对任一匹配项执行完整校验 + 立即移除
- 池子大小需权衡：太大增加验证开销，太小仍可能误杀
- 不要用数据库存池子——session 已足够，避免额外 I/O 和竞态
最容易被忽略的是「绑定 IP」和「用完即毁」。前者让攻击者无法跨设备复用 token，后者堵死重放路径；两者都失效时，哪怕 token 本身再随机，防护也形同虚设。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
