Handlebars JS：安全使用以避免注入缺陷

在使用 Handlebars 时，开发者往往没有意识到错误使用模板可能会暴露严重的注入漏洞。虽然 Handlebars JS 会自动转义输出，但诸如三括号或编写不当的 Handlebars 辅助函数等不安全的模式可能会绕过保护措施。因此，攻击者可能会注入 XSS 负载、窃取数据或运行恶意代码。

本指南向您展示如何安全使用 Handlebars，重点介绍危险与安全的示例，并解释如何在 pipeline使用 Xygeni 等工具。

为什么 Handlebar 模板可能存在风险

默认情况下，Handlebars JS 会对值进行转义以阻止直接注入。但许多开发者在不了解风险的情况下关闭了此功能。例如，使用三括号会显示原始 HTML：

<!-- Unsafe usage -->
<div>{{{userInput}}}</div>

If userInput is <script>alert('XSS')</script>, 脚本在浏览器中执行。因此，即使一个不安全的模板也可能危及整个应用程序。

这些基本的错误凸显了风险。因此，历史表明，滥用 Handlebars 会导致严重的野外攻击。让我们回顾一些最值得注意的案例。

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。
计费示例：

<!-- Unsafe -->
<div>{{{userInput}}}</div>

If userInput 包含 <script>alert('XSS')</script>，它会立即执行。

污染原型

正如所见 npm advisory GHSA-2cf5-4w76-r9qv，恶意输入可以通过精心设计的模板修改全局对象。

影响： 这可能导致任意行为、权限提升或数据泄露。
教训： 始终保持 handlebars 更新并运行依赖项检查 CI/CD.

服务器端模板注入 (SSTI)

当不受信任的输入直接传递到服务器上运行的模板引擎时，就会发生 SSTI。 Handlebars JS如果开发人员使用原始用户输入编译模板，攻击者就可以在服务器级别执行有效载荷。

// Insecure Handlebars usage (server-side)
const template = Handlebars.compile(req.query.view);
res.send(template({}));

{{#with "require('fs').readdirSync('.')"}}

引擎可能会尝试评估它，从而暴露服务器端文件。

影响： 与仅影响浏览器的 XSS 不同，SSTI 可以直接访问服务器环境。
预防： 切勿编译来自不可信来源的模板。相反，应仅使用预定义的模板，并在渲染前对输入进行清理。

其他生态系统也存在类似的风险。例如，请参阅我们的指南 Python依赖注入在不同的环境中学习安全做法。

帮助者中的逻辑滥用

定制化 车把助手 如果允许原始字符串或使用未经验证的输入，则可能会很危险。

影响： 攻击者可以绕过转义或诱骗帮助者泄露敏感数据。
计费示例：

Handlebars.registerHelper('raw', input => new Handlebars.SafeString(input));

此助手会完全禁用转义，因此应避免使用。

资料泄漏

有时帮助程序或配置错误的模板会泄露敏感信息。

影响： 令牌、配置值或数据库凭证可以在 HTML 输出中呈现。
教训： 切勿在模板中泄露秘密；验证并扫描存储库中的意外泄漏。

这些类别共同展现了开发者面临的各种风险。因此，即使是 Handlebars JS 中的小错误，如果不加以修复，也可能演变成供应链问题。

为什么这对开发人员很重要

这些漏洞证明不安全使用并非理论上的，它已经在 Asana 等真实平台中被利用。 npm 包。此外，随着 Handlebars JS 在 Node.js 和前端项目中的广泛使用，不安全的帮助程序或过时的依赖项很快就会成为软件供应链风险。

想要自动阻止这些风险吗？开始免费试用 Xygeni 并添加 guardrails 在您的 pipeline ！

安全使用车把的最佳实践

为了避免注入缺陷，请遵循以下安全编码实践：

1. 始终使用双括号

<!-- Safe -->
<div>{{userInput}}</div>

这可确保模板引擎在渲染之前转义 HTML。

2. 验证并清理输入

此外，在将输入传递给模板之前，请验证输入。类似这样的库验证器

3. 限制危险的帮助者

设计不佳 车把助手 经常导致漏洞：

// Dangerous helper
Handlebars.registerHelper('raw', function (input) {
  return new Handlebars.SafeString(input);
});

这完全绕过了转义。但是，安全助手应该仅限于一些简单的操作，例如格式化日期或修剪文本。

4. 使用内容安全策略（CSP）

此外，强制使用强大的 CSP 标头来减少任何注入的爆炸半径。

这些最佳实践在开发过程中至关重要。此外，您还可以添加自动检查，确保不安全的代码永远不会进入生产环境。

自动验证 CI/CD Pipelines

人工审核是不够的。需要澄清的是，除非有自动化检查，否则不安全的 Handlebars 模式可能会进入生产环境：

SAST 定位、竞价/采购和分析/优化数字媒体采购，但算法只不过是解决问题的操作和规则。：旗帜 {{{ in .hbs 文件。
秘密扫描仪：检测模板中嵌入的凭证。
CI/CD guardrails：不安全时中断构建 车把助手 或出现三重括号。

例如，你可以加强护栏 pipelines:

# Example Guardrail Rule
if: contains('{{{')
then: fail_build("Unsafe Handlebars triple braces detected")

这些检查减少了不安全模板的可能性，但是自动化规模化需要一个平台。Xygeni 正是为此提供了额外的保护。

您还可以了解如何确保 pipelineBitbucket 中的 s 在我们的 Bitbucket 安全常见问题解答。

Xygeni 如何帮助防止不安全的车把使用

编写安全的代码很重要，但真正的保护来自自动化。西吉尼 & Handlebars JS 通过在工作流程中添加检查来提高安全性：

SAST 用于模板: 扫描 .hbs 捕获不安全的文件 {{{ 或有风险的自定义助手。
Guardrails: 在 GitHub、GitLab 或 Bitbucket 中设置简单规则。如果发现不安全的 Handlebars JS 代码，则构建停止。
自动修复: 建议安全修复 pull requests，将三重括号替换为安全的双括号或可信赖的辅助调用。
秘密和配置检查： 在模板中隐藏的令牌或凭证泄露之前找到它们。
CI/CD 安保防护: 在合并期间阻止不安全的代码片段，因此只有安全的代码才能进入生产环境。

使用 Xygeni，安全 Handlebars JS 使用不再仅仅是一个指南。它成为你自动化 pipeline.

将它一起

Handlebars 基本上是开箱即用的，但误用仍然可能引发注入攻击。遵循最佳实践、验证输入并使用安全助手有助于降低风险。然而，真正的优势在于，这些检查在您的 pipelines.

总之，将良好的编码习惯与 Xygeni 等工具相结合有助于防止注入缺陷并确保模板安全，而不会减慢交付速度。