后台表单少了同源校验的公告为什么只评中等严重
后台表单少了同源校验的公告为什么只评中等严重？因为这类问题的后果不体现在机密性上，而是体现在完整性：能读到的东西没有变多，能被改动的东西变多了。评级维度里哪一项有值，直接决定分数上限。
公告字段逐项读法
这条来自 Drupal 的公告编号 SA-CONTRIB-2026-217，涉及 Advanced Filesystem 模块，问题类别写作 Cross-Site Request Forgery，发布于 2026 年 10 月 7 日，评级 Moderately critical，分值 12 / 25。受影响版本 <1.0.28，处理建议是升级到 1.0.28。
维度串是 AC:Basic/A:None/CI:None/II:Some/E:Theoretical/TD:Default。逐项对应的读法如下：
| 维度 | 公告取值 | 读法 | 对处置的影响 |
|---|---|---|---|
| 攻击复杂度 AC | Basic | 不需要特殊条件 | 不能靠「条件苛刻」推迟跟进 |
| 所需权限 A | None | 不要求攻击者先有账号 | 但受害方需处于登录状态 |
| 机密性 CI | None | 读不到额外内容 | 分数上不去的直接原因 |
| 完整性 II | Some | 部分数据可被改动 | 处置重点在改动范围 |
| 利用条件 E | Theoretical | 未给出可用利用路径 | 不必停站，但需排期 |
| 影响面 TD | Default | 常规部署即受影响 | 无法按特定环境排除 |
为什么机密性维度算零
跨站请求伪造的作用机制是借用访客已经存在的登录状态，让浏览器替攻击者发出请求。请求由合法会话发出，因此不会产生「额外可读数据」——机密性维度记为零。真正被打开的是动作权限：发帖、改配置、删附件这类只校验会话而不校验请求来源的动作。
这也解释了「中等」并不轻。同一维度串里攻击复杂度为 Basic、所需权限为 None，意味着只要管理员点到一个精心构造的页面，动作就可能被执行。
后台表单和公开表单的区别
公开表单（如留言、找回密码）没有登录态可借，缺失同源校验的后果通常落在滥用与垃圾提交上；后台表单的前提是操作者已登录，后果直接落在内容与配置上。同一项缺失在两种页面上的处置顺序并不相同，把两者混在一张清单里排优先级会失准。
站内三层收口
第一层是人机验证。表单接入 reCAPTCHA 验证码，作用是把自动化提交挡在动作之前，它处理的是「请求是不是程序发出来的」。第二层是内容侧把关：敏感词过滤与关键词替换在内容入库时生效，内容审核决定条目能否进入发布，它处理的是「请求带回来的内容是否可接受」。第三层是注入面收敛：内置的跨站脚本与 SQL 注入防护、JWT 认证与防采集干扰码，负责限制外部输入能到达的位置。
三层都不等价于同源校验。把验证码配好之后，仍然要单独确认后台动作是否校验请求来源——这一点在任何系统里都不能由人机验证替代。
自查清单
- 列出后台所有会写数据的表单入口，逐个确认是否校验请求来源；
- 对留言、找回密码等公开表单核对 reCAPTCHA 是否真正生效，而不是只在配置里开启；
- 检查内容审核是否覆盖到来自接口与批量导入的条目；
- 把「配置项已开启」与「动作被拦截」分成两栏记录，避免用前者代替后者。
常见问题
问：只有管理员会登录后台，还需要担心这类问题吗？ 答：这类问题的攻击对象正是少量高权限会话，账号数量少不降低风险，反而提高单次命中的后果。
问：升级到修复版本之外还要做什么？ 答：核对近期数据改动记录，确认是否已出现非本人操作的变更；若有，除升级外还要处理会话与凭据。
问：中等严重的公告可以放到季度维护里一起处理吗？ 答：完整性维度有值的后台表单问题，建议按周排期而不是并入季度维护，具体取决于该表单能改动什么。