登录异常疑似CSRF攻击

凌晨两点十七分，登录运维群里弹出一条告警：某后台管理系统在十分钟内出现了大量来自同一IP的异常疑登录请求，全部失败。攻击值班同事一开始以为是登录撞库，打算按常规封IP了事。异常疑但我扫了一眼日志，攻击发现事情没那么简单——这些请求的登录URL里，居然带着一个本该只出现在用户浏览器里的异常疑参数。

这就是攻击CSRF最阴的地方。它不撬锁，登录它让锁自己打开。异常疑

一个真实的攻击登录异常长什么样

先看日志片段（已脱敏）：

POST /admin/login HTTP/1.1 Host: internal.example.com Referer: https://evil-site.com/attack.html Cookie: session_id=abc123... Content-Type: application/x-www-form-urlencoded username=admin&password=123456&csrf_token=

注意那个Referer。正常用户从公司内网登录，登录Referer应该是异常疑内网地址或者空。但这个请求来自一个外部域名。攻击更诡异的是，csrf_token参数是空的——攻击者根本拿不到这个token，他只是在赌服务器不校验。

而服务器确实没校验。

CSRF不是“伪造请求”，是“借用身份”

很多人把CSRF理解成“伪造了一个请求”。不准确。攻击者没有伪造任何东西，他写了一个普通的HTML页面，里面藏了一个自动提交的表单，指向你的后台登录接口。然后他诱导已经登录后台的管理员打开这个页面。

浏览器一看：哦，是internal.example.com的请求，带上之前存好的session cookie。于是服务器收到的请求里，身份凭证是真实有效的。服务器以为这是管理员本人操作，实际上管理员只是打开了一个恶意网页。

这就是为什么我说“让锁自己打开”。钥匙在管理员自己兜里，攻击者只是骗他走到门前。

为什么登录接口也会中招

通常CSRF攻击的目标是“修改密码”“转账”“发帖”这类操作。登录接口本身被CSRF，听起来有点反直觉——我都能让管理员登录了，还攻击登录干嘛？

但这次的情况不一样。这个后台的登录逻辑有个设计缺陷：登录成功后，服务器会根据请求中的redirect_url参数跳转。攻击者构造的CSRF请求里，redirect_url指向了一个恶意页面，并且登录用的账号密码是攻击者自己注册的低权限账号。结果就是：管理员在不知情的情况下，用自己的浏览器登录了攻击者的账号，然后被跳转到恶意页面。接下来攻击者可以利用这个“已登录”的会话，诱导管理员在恶意页面里输入敏感信息，或者执行其他操作。

这叫“登录CSRF”，一种经常被忽略的变体。

防御其实不复杂，但总有人偷懒

最有效的办法就一个：给每个表单加一个随机生成的CSRF token，服务端校验。这个token不放在cookie里，放在页面HTML里，攻击者的跨站页面拿不到。上面那个案例里，csrf_token参数是空的，说明系统压根没启用校验。

另一个辅助手段是检查Referer和Origin头。但Referer可能被隐私设置抹掉，Origin在某些旧浏览器上也不可靠。所以token才是主力。

还有个细节：SameSite Cookie属性。把session cookie设成SameSite=Lax或Strict，浏览器就不会在跨站请求里带上它。这能挡住大部分CSRF，但有些老系统改不动cookie配置，那就只能靠token。

我的一点观察

很多开发者在写登录接口时，心理上觉得“登录不需要防CSRF，因为用户还没登录”。这个逻辑是错的。登录接口同样会读写session，同样会触发状态变更。只要浏览器会自动带上凭证，就有CSRF的风险。

那次事件最后查清楚了：是一个刚入职的实习生写的后台模块，直接从网上抄了一段登录代码，没加token校验。攻击者可能只是扫描器自动跑到了这个接口，顺手试了一下。但如果我们没发现，后果可能不只是几个失败日志。

安全这件事，往往不是被高手攻破的，而是被偷懒留下的缝隙漏掉的。

(责任编辑：时尚)