在Web应用开发中，针对用户输入拼接模板的场景应采取哪些措施防止模板注入漏洞？

防止模板注入（Server-Side Template Injection, SSTI）的核心原则是不将用户输入作为模板语法的一部分进行解析。具体措施如下：

一、直接防御措施

1. 逻辑与数据分离：禁止使用字符串拼接方式将用户输入嵌入模板源码。应通过模板引擎提供的参数传递机制（如上下文变量赋值）渲染数据，确保用户输入仅被视为纯文本而非可执行指令。
2. 使用无逻辑模板引擎：优先选择基于占位符替换的无逻辑模板引擎（如 Mustache），这类引擎不支持复杂的表达式求值或控制流，从根本上消除代码执行面。
3. 沙箱隔离：若业务必须动态解析模板，需在受限的沙箱环境中执行。移除或禁用模板引擎中的危险内置函数、对象访问链（如 Java 的 getClass()、Python 的 __subclasses__）以及文件系统读写能力。
4. 严格的输入校验：对用户输入实施白名单校验，限制允许的字符集和长度，拒绝包含模板特殊定界符（如 {{、{%、${）的输入。
5. 输出编码：在最终渲染阶段对数据进行上下文相关的转义，防止跨站脚本（XSS）等次生漏洞。

二、判断依据

• 当系统允许用户自定义邮件模板、页面布局或报表格式时，存在 SSTI 风险。
• 若模板引擎报错信息中泄露了底层语言的对象结构或堆栈，说明输入已被当作模板语法解析。

三、适用条件

• 内容管理系统（CMS）与低代码平台：需支持用户自定义视图时，必须启用强沙箱。
• 常规 Web 表单处理：无需动态模板功能，应彻底禁用模板语法的动态解析。

四、常见误区

• 误以为仅靠过滤关键字即可防御：攻击者可通过字符串拼接、编码转换等方式绕过简单的黑名单过滤。
• 混淆 XSS 与 SSTI：XSS 影响客户端浏览器，而 SSTI 可导致服务端远程代码执行（RCE），危害层级不同。
• 过度信任模板引擎默认配置：许多模板引擎默认开启了丰富的内置方法，未做安全裁剪即直接使用会带来风险。