CSRF 自愈机制：token 错位自动重试的设计思路

CSRF 自愈机制的核心设计只有一句话：校验失败时不要直接把用户挡在门外，而是自动拉取新 token 重发一次——把"偶发的 token 错位"和"真正的跨站攻击"分开处理，前者无感修复，后者照旧拦截。Clara BBS 的新版编辑器就是这么做的，所以用户在长时间停留后发帖，绝大多数情况下不会再看到"页面已过期，请刷新后重试"。

先搞清楚：token 错位是常态，不是漏洞

结论：绝大多数 CSRF 校验失败并非攻击，而是会话与页面生命周期不同步导致的"合法但不新鲜"。

CSRF（跨站请求伪造）防护的基本做法，是服务端给当前会话签发一个 token，随表单一起提交，服务端比对一致才放行。问题在于 token 和会话绑定，而页面寿命往往比会话状态长很多。典型的错位场景有四种：

• 页面开了很久没动，期间会话轮换或超时，表单里揣的还是旧 token；
• 同一个账号开了多个标签页，其中一个页面刷新过，另一个还拿着旧值；
• 站点地址 www 与裸域混用，浏览器把两套域名当两个站点，会话互相覆盖；
• 浏览器回退缓存把旧页面整页恢复，token 字段跟着一起"复活"。

这四类都是真实用户、真实意图，只是提交的凭证过期了。对它们一刀切地弹"页面已过期"，是把工程问题转嫁给了用户。

自愈的三步：识别、换票、只重试一次

结论：自愈机制必须包含三个约束——可识别、可换 token、只重试一次，缺一个都会变成隐患。

设计思路拆成三步就清楚了：

第一步，让失败可识别。 服务端校验不通过时，不能只返回一个笼统的 403，而要给出明确标识（Clara BBS 的做法是页面提示"页面已过期，请刷新后重试"），前端才能判断这是"该换票"而不是"该放弃"。

第二步，拿一次新 token。 前端识别到该标识后，先向服务端索取当前会话的新 token，再带着同一份表单数据（标题、正文、分类、附件等原样保留）重新提交一次。这一步的价值在于：用户不需要重新填一遍几百字的帖子。

第三步，只重试一次。 这是最关键的安全约束。如果重试可以无限循环，就等于把 CSRF 校验变成了走过场。所以重试次数必须硬性限制为一次：第二次仍然失败，就把控制权交还用户，提示刷新页面——因为此时大概率不是 token 错位，而是站点配置或登录态真的有问题。

另外两个工程细节值得写进设计里：重试必须是"先取票、再重发"的顺序，不能把新旧 token 同时带上；写操作的重试还要考虑重复提交，避免用户收到两次"发帖成功"。

哪些情况不该自愈

结论：自愈只针对"同一会话内的凭证过期"，跨域来源、会话已失效、权限变化一律不许自愈。

判断边界可以简单粗暴一点：如果新 token 拉取得顺利、且请求来源仍是本站当前会话，就允许重发；如果连新 token 都拿不到，说明会话本身已经废了，此时应当引导重新登录，而不是硬重试。

还有一类容易被误判成 token 问题的情况——站点地址配置错误。如果后台「基本设置」里的站点地址没填对（缺少 https://、或 www 与裸域混着用），浏览器会把它当成两个不同站点，会话在跳转间丢失，token 自然永远对不上，表现为"怎么刷新都过期"。Clara BBS 的排查建议就是：后台「基本设置」按 `https://主域名` 的格式填全，统一用一个域名访问。

用户侧遇到时的处理顺序

结论：出现"页面已过期"提示时，先刷新，再检查域名是否统一，最后才怀疑程序。

实操建议按这个顺序走：正常状态下直接刷新页面重发即可；如果反复出现，检查是不是从 www 和裸域两个入口交替访问；仍不行就看登录态是否还在（是否掉登录）；管理员则可顺带核对后台的站点地址配置。由于 Clara BBS 保存即生效、无需清缓存，配置改完立刻就能验证。

回到设计本身：CSRF 防护的目标是拦住伪造请求，不是惩罚真诚的用户。加上一层"换票重发一次"的自愈逻辑，安全强度一分不减，而绝大多数本该发生在用户身上的摩擦被悄悄吸收掉了——这就是这个机制值得做的全部理由。