跨站请求伪造出现在备份子模块上，光靠会话凭据为什么挡不住

跨站请求伪造出现在备份子模块上，光靠会话凭据为什么挡不住？因为这类攻击借用的是浏览器的一个默认行为：已登录用户的每一次请求都会自动携带会话凭据，攻击者只需要诱导浏览器发出一个请求，凭据就跟着走了。Drupal 2026 年 10 月的公告 SA-CONTRIB-2026-217 里，Advanced Filesystem 的备份子模块正是因为未充分校验某些请求，被标为跨站请求伪造。防线因此不能压在凭据上，要压在请求本身的来源与一次性凭证上。

公告的成因与评级怎么读？

这份公告把缺陷评为中等偏重（Moderately critical），修复版本是 1.0.28，成因原文只有一句：备份子模块未对某些请求做充分校验。评级字符串里值得看的是攻击复杂度为 Basic、对完整性的影响为 Some——攻击门槛不高，主要风险在于诱导已登录管理员执行非本意的备份类写操作。备份子模块之所以值得单独点名，是因为它天然带着读写大量文件的能力，一旦被借道执行，影响会超出模块本身，牵连到整站数据的可用性。

会话凭据为什么挡不住这类攻击？

会话凭据解决的是”证明你是谁”，不解决”这是不是你真实想做的操作”。浏览器对 Cookie 的处理是自动的：只要目标域匹配就携带，不管请求由哪个页面发起。攻击者构造的页面里，一个隐藏表单或者一张图片地址就能把请求发出去，服务器看到的是带合法凭据的”正常”请求。所以判断一个写请求可信与否，要看请求之外的信息：请求从哪个源发起、有没有服务端预先下发的一次性动作凭证。这些是凭据本身给不了的，也是跨站请求伪造类缺陷的共性缺口。

三道常用校验各自挡什么？

第一道是来源校验：核对请求头里的来源信息与目标是否同源，挡住从外部页面发出的请求，配置成本低，但要覆盖全部写入口才有效。第二道是一次性票据：写操作要求携带服务端预先下发、用后即废的凭证，攻击者拿不到未来请求的票据，伪造请求即使发出也通不过。第三道是人为确认：高危写操作引入二次确认或验证码，AnQiCMS 支持 reCAPTCHA 验证码接入表单防机器人，给高危动作再加一道人工关口。三道不是互斥关系：来源校验加一次性票据是基础配置，验证码与人工确认按操作敏感度叠加。

站点侧能做什么收口？

先把备份类入口的可达范围收小：备份与恢复属于全站级能力，访问面要限定在管理端，不与公开功能混用。再是对系统本身的跟进：同类问题在成熟系统里同样出现过，AnQiCMS 在 v3.6.6 里修复了站点切换登录凭证可被伪造的高危问题，升级说明同时建议轮换站点密钥并修改管理员密码——这类发布说明值得逐条读，修复项往往就是攻击者已经盯上的位置。最后保持备份习惯：防护做得再完备，高风险操作前先做一次完整备份，出问题时才有干净的还原点，这是动作层面的兜底。

常见问题

问：只对后台入口做来源校验够吗？ 答：不够。校验要覆盖全部写入口，遗漏的任何一个子模块都会成为绕过点，本次公告针对的正是备份子模块这类边缘入口。

问：一次性票据和验证码选一个就行吗？ 答：它们挡的东西不同：票据挡伪造请求，验证码与人工确认挡自动化滥用；高危操作建议叠加配置而不是二选一。

问：普通站点怎么判断自己有没有暴露？ 答：盘点全部写操作入口，逐一确认是否有来源校验或一次性凭证；清单列不全，本身就是风险信号。