今天早上，检测击无我像往常一样打开后台准备发布新文章，法登结果登录页直接弹出一行红字：“检测到跨站请求伪造（CSRF）攻击，检测击无请求已拦截”。法登我愣了两秒，检测击无密码没错，法登验证码没错，检测击无怎么就进不去了？法登

刷新一次，还是检测击无被拦。再刷新，法登这次连红字都没了，检测击无直接给我个403页面。法登

我第一反应是检测击无浏览器插件惹的祸——之前装过个什么“网页安全盾”，偶尔会误伤正常请求。法登我把它禁用，检测击无清掉缓存，重新输入网址。结果一样。防火墙？公司这台电脑的防火墙设置我从来没动过，应该不是它。

折腾了十分钟，我换了个浏览器试。Chrome不行换Firefox，Firefox也不行换Edge。全都被拦。这时候我才意识到，问题可能出在服务器端，不是我这边的环境。

我赶紧登录服务器控制台，查看Nginx日志。日志里密密麻麻全是CSRF token mismatch的记录。时间戳从昨晚11点就开始，一直持续到今天早上，每五分钟一次。这说明攻击者不是手动操作，是用脚本在跑。

但奇怪的是，这些请求的IP地址全是同一个——来自我自己的办公网络出口IP。

这就很耐人寻味了。如果真是外部攻击，IP应该五花八门才对。同一个IP反复触发CSRF校验失败，更像是我这边某个程序在自动发送请求。我忽然想起来，昨晚为了测试新写的RSS抓取脚本，我开着后台任务跑了一夜。那个脚本会模拟登录请求来获取最新文章列表——它没带CSRF token。

找到了。攻击者不是黑客，是我自己的代码。

CSRF防护机制的工作原理很简单：服务器在渲染登录表单时生成一个随机token，存在session里，同时嵌入到表单的隐藏字段。提交登录请求时，服务器会比对提交的token和session里存的是否一致。我的脚本用requests库直接POST登录接口，只传了用户名和密码，没带那个隐藏字段，所以每次都被判定为“伪造请求”。

系统连续拦截多次后，触发了锁定机制，把整个登录入口暂时封了。这也解释了为什么我手动登录也被拦——服务器已经进入“防御模式”，对所有来自该IP的登录请求一律拒绝，不管带没带token。

解决办法很简单：等待锁定时间自动过期，或者手动清除服务器上的缓存和锁定标记。我选择后者，直接删了/tmp下的锁定文件，然后重启了PHP-FPM服务。再打开登录页，输入密码，顺利进去了。

这次误报让我反思了一件事：安全防护机制的误伤率，往往比我们想象中要高。CSRF攻击的典型特征是攻击者诱导用户点击恶意链接，利用用户已登录的身份发送伪造请求。但现实场景里，很多自动化脚本、API调试工具、爬虫程序——它们都容易触发CSRF校验失败。系统把这些合法但“不合规”的请求全部当成攻击，反而把真正的用户锁在门外。

说到底，安全策略不能只考虑“防住攻击”，还得考虑“别误伤自己人”。如果你的登录页频繁出现CSRF拦截，先别急着怪黑客，检查一下自己最近的代码改动、定时任务、或者浏览器插件。很多时候，最大的威胁不是外部入侵者，而是你昨晚写的那行没带token的测试代码。

(责任编辑：娱乐)