存储型 XSS 出现在评论管理页，待审核评论是怎么把脚本带进后台的

存储型 XSS 出现在评论管理页，靠的是「待审核」这一环被误当成安全区。WordPress 7.1.3 官方安全说明里就列了这一条：评论管理页存在一处存储型 XSS，可经待审核评论触发（exploitable via pending comments）。它的关键不是脚本真的进入了审核通过的正文，而是后台列表在管理员打开时，把这条还没审核的评论也渲染了出来，于是脚本在后台环境里被执行。

为什么未审核内容也能触发

很多人以为「审核」是一道墙：内容没通过审核就不会对外生效。这道墙挡的是前台展示，挡不住后台渲染。评论管理页的作用恰恰是让管理员预览待审核内容，好决定放不放行。既然要预览，系统就得把它显示出来，而「显示」这一步如果没做转义，就等于把用户提交的东西当作界面的一部分执行了。

所以触发路径是：访客提交一条带脚本的评论，状态是待审核，它安静地躺在列表里；管理员打开评论管理页想处理积压，浏览器在渲染这条记录时执行了脚本。整个过程评论始终是「未审核」，但 XSS 已经发生。待审核描述的是内容能不能发布，不是它会不会被后台读取和显示——这两件事被混为一谈，才留下了口子。

危险点在于后台把它当可信数据渲染

同一份评论数据，在前台和后台的信任级别是不同的。前台受审核状态控制，未通过的不会出现；后台为了让人能判断，必须原样展示。危险就出在后台展示时默认「这是我自己的管理界面，数据是可信的」，于是直接把它拼进页面。

存储型的特征正在于此：脚本先被存进数据库，之后每次有人打开相关页面都会被再次执行，不是一次性触发。要收口，不能只在提交那一刻检查，还要保证无论这条数据后来在哪个界面、被谁打开，输出时都不被当作可执行内容。

收口的两层：入库校验与输出转义

真正稳的做法是把两道关卡叠起来，任何一道单独使用都不够。

只靠入库校验会漏，因为绕过过滤的写法总有新花样；只靠输出转义也不够，因为脏数据一旦在别的场景被拼接仍可能出问题。两层一起做，才把「存储—渲染」这条链真正切断。前端弹窗拦截之类的手段不能算这一层，它能拦的那道服务端与模板转义都做不了替代。

站内把三层防护分别放在哪

对照 AnQiCMS 的设计，可以看到同类问题被拆成了三道各管一段的防护，而不是堆在一处。

第一道是敏感词过滤与关键词替换，配合内容审核，管的是「内容本身能不能进、进的时候要不要处理」。这是入库校验的落地。第二道是内置的 XSS 防护与 SQL 注入防御，管的是数据在存储与查询链路上不被当作代码执行，属于更底层的输入收口。第三道是表单接入的 reCAPTCHA 验证码，它不判断内容危不危险，而是抬高批量提交的成本，让攻击者很难用脚本灌进大量待审核评论。

三道分别卡在提交、存储、渲染的不同位置，任何一道被绕过还有下一道兜底。这比把安全押在「反正没审核就不显示」这一个假设上稳得多。

常见问题

问：评论一直是待审核状态，前台没展示，还算中招吗？ 答：算。后台评论管理页会渲染待审核内容，脚本可在管理员打开时执行。

问：只删掉那条恶意评论能算处置完成吗？ 答：不能。存储型 XSS 要升级到官方修复版本，仅删单条评论不解决渲染未转义的根因。

问：前端拦截够用吗？ 答：不够。服务端入库校验与模板输出转义两层都要做，前端可被绕过。

问：敏感词过滤和内容审核是不是重复？ 答：不是。过滤处理词面，审核决定放行与否，二者与 XSS 的输出转义各管一段。