模板注入到底是什么：从数据流看它的边界

模板注入的根因是模板源码由数据决定，而不是模板里最终填进去了什么数据

理解它的关键是画出三条线：入口、信任边界、危险点。

先说结论

漏洞的本质是「不可信数据到达了危险点」，防御的本质是「在中间加一道能正确判断的关卡」。

• 入口：数据从哪来，谁都能改吗
• 边界：跨边界时有没有做类型与格式判断
• 危险点：拼接、解析、执行、反序列化
• 前置条件：需要什么权限、什么配置
• 影响面：能读到什么、能改到什么

数据流：从入口到危险点

Jinja2 的沙箱能拦住属性链，但传进上下文的配置对象仍可能从 globals 泄漏，沙箱不等于隔离。

信任边界在哪

模板表达式可以直接读到环境变量与配置，很多事故里影响面比命令执行更直接，也更难被规则拦住。

边界两侧的数据可信度不同，所有校验都应该发生在边界上，而不是散落在业务代码里。

这个问题的几个关键事实

决定它「是理论还是现实」的几条：

• 用户输入进入 render_template_string 这类接口，模板源码由外部数据决定，才具备注入前提，普通变量替换不具备
• 先编译再渲染、模板只从固定目录加载，能把注入面压到接近零

影响面怎么判

评估危害时先问：需要什么身份、需要开什么配置、能不能碰到内网。三个问题的答案决定了它是「低危」还是「要连夜修」。

为什么总是修不干净

用字符串替换拼模板，以为过滤掉两层花括号就安全

开了沙箱却把请求对象与配置整体传进上下文

根因通常是「同一个入口有多个解析器」，修了一个，另一个还通。

再补充几点

这几条不改变结论，但会改变你评估风险时的顺序。

• 升级到仍在维护的引擎版本，并关掉模板里的任意属性与方法调用，能挡掉大部分已知手法
• 只在注册入口做过滤，忘了邮件模板与站内信模板

理解数据流，比背 payload 有用得多。