Handlebars JS 会自动转义输出以防止注入，但像三重大括号或编写不佳的自定义辅助函数这样的不安全模式可以完全绕过这种保护。 这样做时，攻击者可以注入 XSS 有效载荷、窃取数据或通过开发者默认认为安全的模板运行恶意代码。
本指南向您展示如何安全使用 Handlebars，重点介绍危险与安全的示例，并解释如何在 pipeline使用 Xygeni 等工具。
为什么 Handlebars 模板可能存在风险
默认情况下，Handlebars JS 会对值进行转义以阻止直接注入。但许多开发者在不了解风险的情况下关闭了此功能。例如，使用三括号会显示原始 HTML：
If userInput is <script>alert('XSS')</script>, 脚本在浏览器中执行。因此，即使一个不安全的模板也可能危及整个应用程序。
这些基本错误已经导致了真实存在的、有据可查的攻击案例，而不仅仅是理论上的风险。以下是其中两个最值得注意的案例。
Handlebars 漏洞的真实示例
尽管 Handlebars JS 默认情况下，转义值，历史表明不安全的模式或弱 车把助手 已造成严重问题：
1. Handlebars 中的原型污染（npm 公告 GHSA-2cf5-4w76-r9qv）
2021 年，在 handlebars 软件包本身。该缺陷允许 原型污染，攻击者可以通过精心设计的模板将属性注入全局对象。
- 影响： 原型污染可以让攻击者运行代码、获得更高的访问权限或窃取数据。
- 攻击： 攻击者发送了如下恶意输入
__proto__属性。当模板被渲染时，这些被污染的对象会改变应用程序的行为。 - 教训： 即使是模板引擎，如果不更新，也可能存在风险。运行依赖项扫描并及时更新软件包至关重要。
2. Asana 自定义 Handlebars 助手中的 XSS（2019）
2019 年，安全研究人员发现 体位法，一款任务管理工具，让用户能够 XSS 因为自定义帮助器不安全。开发者编写了返回原始字符串的帮助器，使用 SafeString，绕过 Handlebars 的内置转义。
- 影响： 攻击者将恶意 JavaScript 注入共享任务或评论中。
- 攻击： 有效载荷如下
<script>alert('XSS')</script>当受害者打开这些字段时，该程序就会在受害者的浏览器中运行。 - 教训： 除非别无选择，否则切勿禁用转义。务必检查自定义 车把助手 在部署它们之前。
Handlebars 中的漏洞类型
不安全使用 Handlebars JS 模板可能会暴露不同类型的漏洞。了解这些漏洞有助于开发人员准确了解需要预防的漏洞：
跨站点脚本（XSS）
这是最常见的缺陷。当开发人员使用三重括号时就会发生这种情况 {{{}}} 或禁止转义的原始助手。
- 影响： 攻击者可以注入
<script>在用户浏览器中运行的标签、HTML 或 iframe。 - 计费示例：
If
userInput包含<script>alert('XSS')</script>，它会立即执行。
污染原型
正如所见 npm advisory GHSA-2cf5-4w76-r9qv，恶意输入可以通过精心设计的模板修改全局对象。
- 影响： 这可能导致任意行为、权限提升或数据泄露。
- 教训： 始终保持
handlebars更新并运行依赖项检查 CI/CD.
服务器端模板注入 (SSTI)
当不受信任的输入直接传递到服务器上运行的模板引擎时，就会发生 SSTI。 Handlebars JS如果开发人员使用原始用户输入编译模板，攻击者就可以在服务器级别执行有效载荷。
引擎可能会尝试评估它，从而暴露服务器端文件。
- 影响： 与仅影响浏览器的 XSS 不同，SSTI 可以直接访问服务器环境。
- 预防： 切勿编译来自不可信来源的模板。相反，应仅使用预定义的模板，并在渲染前对输入进行清理。
其他生态系统也存在类似的风险。例如，请参阅我们的指南 Python依赖注入 在不同的环境中学习安全做法。
帮助者中的逻辑滥用
定制化 车把助手 如果允许原始字符串或使用未经验证的输入，则可能会很危险。
- 影响： 攻击者可以绕过转义或诱骗帮助者泄露敏感数据。
- 计费示例：
此助手会完全禁用转义，因此应避免使用。
资料泄漏
有时帮助程序或配置错误的模板会泄露敏感信息。
- 影响： 令牌、配置值或数据库凭证可以在 HTML 输出中呈现。
- 教训： 切勿在模板中泄露秘密；验证并扫描存储库中的意外泄漏。
这些类别共同展现了风险的范围，从浏览器渲染错误到服务器完全被攻破。即使 Handlebars 模板中的一个微小错误，如果不加以修复，也可能演变成供应链问题。
为什么这对开发人员很重要
这些漏洞并非理论上的；它们已经在 Asana 和 Handlebars 等实际平台上被利用过。 npm 包 就其本身而言，由于 Handlebars JS 在 Node.js 和前端项目中被广泛使用，一个项目中不安全的辅助函数或过时的依赖项可能会迅速演变成影响多个项目的软件供应链风险。
想要自动阻止这些风险吗？ 开始免费试用 Xygeni 并添加 guardrails 在您的 pipeline ！
安全使用车把的最佳实践
为了避免注入缺陷，请遵循以下安全编码实践：
1. 始终使用双括号
这完全绕过了转义。但是，安全助手应该仅限于一些简单的操作，例如格式化日期或修剪文本。
4. 使用内容安全策略（CSP）
此外，强制使用强大的 CSP 标头来减少任何注入的爆炸半径。
这些最佳实践在开发过程中至关重要。此外，您还可以添加自动检查，确保不安全的代码永远不会进入生产环境。
自动验证 CI/CD Pipelines
单靠人工审核是不够的，不安全的车把设计可能会在没有自动化检查的情况下流入生产环节：
- SAST 定位、竞价/采购和分析/优化数字媒体采购，但算法只不过是解决问题的操作和规则。： 旗帜
{{{in.hbs文件。 - 秘密扫描仪：检测模板中嵌入的凭证。
- CI/CD guardrails：不安全时中断构建 车把助手 或出现三重括号。
例如，你可以加强护栏 pipelines:
这些检查降低了不安全模板进入生产环境的几率，但需要在每个代码库中始终如一地强制执行这些检查。 pipeline 这时就需要像 Xygeni 这样的专用平台了。
您还可以了解如何确保 pipelineBitbucket 中的 s 在我们的 Bitbucket 安全常见问题解答s.
Xygeni 如何帮助防止不安全的车把使用
编写安全的代码很重要，但真正的保护来自自动化。 西吉尼 & Handlebars JS 通过在工作流程中添加检查来提高安全性：
- SAST 用于模板: 扫描
.hbs捕获不安全的文件{{{或有风险的自定义助手。 - Guardrails: 在 GitHub、GitLab 或 Bitbucket 中设置简单规则。如果发现不安全的 Handlebars JS 代码，则构建停止。
- 自动修复: 建议安全修复 pull requests，将三重括号替换为安全的双括号或可信赖的辅助调用。
- 秘密和配置检查： 在模板中隐藏的令牌或凭证泄露之前找到它们。
- CI/CD 安保防护: 在合并期间阻止不安全的代码片段，因此只有安全的代码才能进入生产环境。
使用 Xygeni，安全 Handlebars JS 使用不再仅仅是一个指南。它成为你自动化 pipeline.
将它一起
Handlebars 默认是安全的，但误用仍然会给注入攻击带来风险。遵循这些最佳实践，例如验证输入、限制危险的辅助函数以及强制执行内容安全策略 (CSP)，可以弥补大部分安全漏洞。真正的优势在于这些检查能够自动运行。 pipeline 而不是每次都依赖人工审核。
将这些习惯与 Xygeni 等平台结合起来，既能保证模板安全，又不会减慢交付速度。
常见问题解答
Handlebars JS 使用安全吗？
是的，默认情况下会进行转义。Handlebars 会自动转义输出以防止注入。风险在于开发者可能会覆盖此保护机制，最常见的方法是使用三重花括号 ({{{ }}}) 或返回原始未转义字符串的自定义辅助函数。
Handlebars 中的 XSS 和服务器端模板注入 (SSTI) 有什么区别？
XSS攻击主要影响浏览器：恶意脚本会在受害者的会话中运行。SSTI攻击则更为严重，它指的是将不受信任的输入直接编译到服务器上的模板中，这不仅会暴露浏览器，还可能暴露服务器端文件或环境访问权限。
如何判断我的车把辅助装置是否安全？
如果辅助函数使用 SafeString 返回原始字符串，或者以其他方式绕过 Handlebars 的默认转义机制，则存在风险。应将自定义辅助函数限制为简单的、不返回字符串的操作，例如格式化日期或修剪文本。
自动化工具能否在产品出厂前检测出不安全的车把使用情况？
是的。 SAST 规则可以标记 .hbs 文件中的三重大括号，密钥扫描器可以捕获嵌入在模板中的凭据， CI/CD guardrails 当检测到不安全模式时，可以直接阻止构建，在人工审查之前发现问题。
