导出文件里存着的旧数据，怎么会变成新的注入点
导出文件里存的旧数据，重新导入后可能变成新的注入入口，原因是二次注入天生分两步走：恶意指令在第一次写入时并不被执行，只是被原样存进数据里；等到某个后续动作把它读出来、拼进查询语句时，才真正触发。导出再导入恰好制造了这样一个「先存后放」的循环，所以它是二次注入里容易被忽略的一条路径。一款主流程序在 2026 年 10 月的安全版本里，就修复了一处发生在其 WXR 导出这条数据重放路径上的二次注入。
一次注入和二次注入的区别在哪
一次注入是输入直接进了查询：表单填进去的内容当场被拼进语句，所以只要在写入那一刻做参数绑定和校验，就能挡住。二次注入把危险挪到了时间轴的另一端：内容第一次进来时看起来无害、顺利落库，真正的拼接发生在使用它的时刻——生成导出文件、渲染页面、或者再次导入。区别在于「校验的时机」和「危险的时机」不在同一步。
导出重放这条路径为什么容易被漏
导出被当成「读取」而不是「写入」，但它其实是一次重新组装：把库里的字段拼进一个结构化文件。如果拼装时不对字段做转义，那些当年侥幸存进来的可疑内容就会被写成文件里的可执行片段。等这份文件被导入到另一个实例时，导入逻辑又把它当外部输入直接落库、甚至当模板解析——两次信任叠加，谁都没在校验，路径就这么漏了过去。
校验放在写入层还是读取层
只放在写入层不够，因为二次注入危险在读取/重放那一步。合理的做法是两层都放，且用同一套规则：
| 环节 | 做什么 | 只放这层够吗 |
|---|---|---|
| 页面写入 | 参数绑定 + 敏感词过滤 | 否，管不到旧数据 |
| 生成导出 | 字段转义再写文件 | 否，管不到再导入 |
| 批量导入 | 视同外部输入做校验 | 关键，重放入口 |
| 接口写入 | 与页面写入同规则 | 否，管不到导出 |
批量导入时的三类字段风险
站内支持用 ZIP 压缩包和 Excel 表格做批量导入，这条路径的三类字段最该盯：一是标题与正文里可能被当模板解析的片段，二是自定义字段名——导入若把字段名当结构而非数据，就可能拼进语句，三是链接与标识类字段，容易携带跨站脚本。批量导入的特点是条数大、常由脚本触发，一旦绕过校验，问题会被一次放大成批。
站内的导入接口怎么收口
文档内容导入接口（路径含 import、archive）用于批量导入，还能按标题查询是否已存在。收口点在于：接口写入和页面写入必须共用同一套输入校验，而不是页面有、接口旁路无——否则攻击者会专门挑接口这条少校验的门进。导入前先用按标题查重的能力把明显重复挡掉，导入时对字段名与正文片段统一做绑定与转义，导出方向则保证「读出来再写进文件」这一步也转义。把 SQL 注入与 XSS 防护视为贯穿读写两向的一层，而不只是发布时的检查。
自查清单
先问导出文件在生成时有没有对字段转义；再问批量导入把文件字段当数据还是当结构；三问接口写入和页面写入是不是同一段校验代码；四问历史库里的旧数据，如果今天重放会不会触发。前两步任意为「否」，就需要补转义或补绑定。
常见问题
问：老数据当年是正常录入的，还会危险吗？ 答：会。二次注入看的是重放时怎么被拼接，不是当年怎么进来的；当年侥幸存入的片段，重放时可能变成可执行内容。
问：接口已经有鉴权，还需要校验吗？ 答：需要。鉴权管谁能调用，校验管内容怎么被拼进语句，两者不同层，接口这条路径不能只靠鉴权兜底。
问：按标题查重能防注入吗？ 答：不能，它只挡重复入库；注入防护靠参数绑定与转义，查重只是顺带减噪。