服务器端模板注入 — SSTI漏洞 ⚠️

引言

几乎所有的软件开发及相关元素都难以逃脱网络漏洞的陷阱。用于服务器端HTML代码管理的模板就是其中之一。针对服务器端模板的攻击被称为SSTI（缩写）。让我们详细探讨它的各个方面。

什么是服务器端模板注入？

大多数Web应用程序所有者更喜欢使用Twig、Mustache和FreeMarker等模板引擎，以便在电子邮件或网页的HTML部分中无缝嵌入动态和丰富的数据。当用户输入以不安全的方式或存在恶意元素的方式引入模板时，就会发生SSTI攻击。

SSTI是通过服务器端使用的内置模板将恶意元素插入到著名模板引擎中的行为。攻击者此举的主要目的是获取服务器端操作的控制权。

理解SSTI过程的最简单方法是通过真实示例来解释。现在考虑这样一个场景：您正在使用一个营销应用程序来发送客户电子邮件，并使用Twig模板系统通过姓名来称呼电子邮件接收者。

如果姓名在模板中添加时没有授予接收者任何修改能力，那么事情将会顺利进行。一旦允许接收端自定义电子邮件，发送方就开始失去对模板内容的控制。

威胁行为者可以利用用户端自定义功能作为机会，通过找出自定义中使用的模板生成引擎并根据他们的偏好更改有效负载来执行SSTI攻击。

SSTI攻击并非总是有计划的；有时，当用户端输入直接与模板交互时，它会无意中发生。这种情况为威胁行为者创造了引入模板引擎扭曲命令并根据他们的意愿操作服务器的机会。在每种情况下，SSTI攻击的结果大多都是破坏性的。

服务器端模板如何工作？

开发人员经常使用这些模板来创建预填充的网页，其中包含定向到服务器的定制化最终用户数据。使用这些模板可以减少服务器端请求处理期间浏览器到服务器的往返次数。

由于服务器端模板为预嵌入的用户输入提供了极大的灵活性和快捷方式，它经常与XSS或跨站脚本攻击混淆。

模板创建引擎是创建Web框架动态HTML的最优选资源。在结构层面上，模板包含预期HTML用户输出的静态部分，以及解释动态内容插入过程的特定规则。

尽管采用了最佳实践，模板系统并没有得到很好的保护，并且容易落入威胁行为者或恶意模板创建者手中。

允许提供或引入用户创建模板的Web应用程序很可能成为SSTI攻击的目标。假设作者在此上下文中编辑变量的数据。这将触发引擎使用模板文件在Web应用程序上添加动态组件。

此外，一旦发生HTTP请求，引擎会自动开始生成HTML输出响应。

要检查，您可以使用HTTP POST请求：

例如：

1
2
3

POST /endpoint-detail HTTP/1.1
Host: example.com
parameter=test_data

以下是测试此漏洞的几种方法。我们将为此使用不同的参数值。

您可以发送一个多语言值，例如$<%[%%\\.，这是通常用于此类测试的特定模式。当引擎显示错误消息后，您可以在警报文本中诊断URL，并找出适合模板引擎的正确语法进行尝试。

当错误消息未揭示引擎详细信息时，使用对各种模板引擎有用的已知语法，例如：

1
2
3

=${7*3}
=<%= 7*3 %>
={{7*3}}

接下来，读取调试输出（例如，对于Django）。不同的模板引擎会有稍微不同的方式。

1
2
3

POST /endpoint-detail HTTP/1.1
Host: example.com
parameter={% debug %}

此请求将为您获取一个可读对象列表，可用于调试。从这里开始，像’settings’这样的对象也可能可访问。因此，尝试读取密钥，看看是否能够成功：

1
2
3

POST /endpoint-detail HTTP/1.1
Host: example.com
parameter={{settings.SECRET_KEY}}

服务器端模板注入的影响

与任何其他网络漏洞一样，SSTI会损害目标。例如，它的引入使网站容易受到多种攻击。

受影响的模板引擎类型以及应用程序使用它的方式是决定SSTI攻击后果的两个方面。

大多数情况下，结果对目标来说极具破坏性，例如：

• 远程代码执行
• 为后端服务器启用未经授权的类似管理员访问权限
• 在服务器端系统中引入随机文件和破坏
• 对内部基础设施的众多网络攻击

所有这些行为都可能造成超出想象的破坏。在极少数情况下，SSTI的困扰较小。

如何检测SSTI？

上述SSTI的后果是对开发人员和防御者的一个信号，要求他们具有远见并在早期阶段识别注入。然而，这并不像听起来那么容易，因为SSTI难以理解，看起来非常类似于XSS攻击，并且常常不可见。因此，必须付出额外的努力来更早、更精确地检测SSTI。

与任何其他攻击一样，开始的检测步骤是发现它的存在。最可行的方式是通过熟悉带有特殊字符序列的常用表达式来模糊测试模板。

如果测试人员无法执行字符序列，则意味着存在SSTI。

此外，可以查找具有.stm、.shtml和.shtm等扩展名的网页的存在。具有这些扩展名页面的网站很可能受到SSTI攻击的影响。

然而，并非所有这些方法都足以进行100%精确的SSTI检测，因为它的存在有两种上下文：纯文本和代码文本。

以下是分别在两种上下文中检测SSTI的最常见方法的详细说明：

1. 纯文本

在这种检测方法中，使用类似XSS输入的纯文本来检查漏洞的存在。为了验证这是否是SSTI的有利情况，您也可以在参数中使用数学表达式。

要检查一个站点，http://example.com/?username=${7*7} URL可以帮助进行SSTI检测。在这里，您需要用站点名称替换’example.com’。如果URL搜索结果包含任何数学值，则显示存在SSTI漏洞。

2. 代码上下文

这涉及构建一个能够获取服务器上存在的错误或空白响应的有效负载。此外，可以通过确保XSS漏洞的零概率来实现。您可以尝试在值中注入任意HTML来实现这一点。

当XSS不存在时，在这种SSTI检测方法中应使用第一种方法，即构建有效负载。

如何识别SSTI？

成功检测到SSTI注入后，重点必须放在识别受影响的模板引擎上。

有多种模板语言，但大多数使用相似的语法。这些语法的创建方式不会与使用的HTML元素冲突。这使得为受影响的模板引擎测试创建探测有效负载成为一项容易的任务。

提交无效语法也是识别SSTI漏洞的可行方法。您的提交将强制服务器端系统发出错误消息，以提供关键细节。

在大多数情况下，这是有效的。寻找替代方法的测试人员必须手动测试众多有效负载，并通过模板创建引擎分析它们的拦截过程。为了缩小选项范围，您可以根据过程中的试验尝试消除语法模式。

此外，根据各种模板引擎遵循的语法注入任意算术运算是一种非常常见的方法。

按回车键或点击以查看完整大小的图像

可以遵循上述逻辑树进行准确识别。在 aiming at precise SSTI identification 时，请记住类似的负载可以在多种语言（如Twig或Jinja2）中提供有效的响应。因此，测试人员应始终积累多个成功的响应以得出实质性结论。

服务器端模板注入攻击预防

在理解了SSTI攻击的后果之后，忽视它并且不学习预防方法是不明智的。放弃使用模板引擎不是一个值得考虑的替代方案，因为它在多个方面支持修改，同时不会对代码流造成任何干扰。

因此，开发人员和安全专家必须寻找其他方法，使应用程序和网站远离SSTI的影响。以下是一些专家批准的SSTI预防策略。

1. 有限的"编辑"访问权限

在任何情况下，除了开发人员和管理员之外，模板都不应可供任何人修改和更改。对所有人开放的模板是黑客的容易目标。因此，对模板执行访问规则并保持其可访问性受限是明智的。然而，这并非总是可实现的目标。

2. 快速审查

清理是另一种可行的技术，可以降低SSTI攻击的可能性。它指的是事先交叉检查所有预期内容是否存在破坏性元素。最重要的是，这种事先审查应在用户传输的数据上进行。可以通过使用正则表达式并创建已验证表达式列表来实现。请记住，此解决方案不能保证100%的保护。

3. 沙箱

为了更好地保护免受SSTI的侵害，沙箱是比清理更好的选择。这是一种预防性方法，涉及为用户创建一个安全且封闭的生态系统。当发现任何漏洞时，封闭环境没有危险的特性和模块，同时限制对其他数据的访问。尽管其效能值得称赞，但其实施是一项艰巨的任务。此外，通过利用 oversight 或错误配置很容易绕过它。

4. 选择无逻辑模板

您可以使用无逻辑模板来防止SSTI攻击。无逻辑引擎模板是用于分离代码解释和视觉渲染的模板。Mustache是无逻辑模板的一个常见例子。由于无逻辑模板使用 mil 控制流语句，所有类型的控制默认情况下都是数据驱动的，并使应用程序逻辑集成成为可能。这减少了远程代码执行的可能性。

5. 利用Docker容器

如果以上解决方案均无效，则防御者必须承认远程代码执行是不可避免的，并应尝试通过在执行完全锁定的Docker容器中执行模板引擎来实现自定义沙箱，以削减其影响。

最后的话

确保端到端系统安全需要对广泛的漏洞有详细的理解。SSTI（服务器端模板注入）就是这样一个漏洞。希望阅读本文能帮助您理解其严重性，并使您意识到组织数字资产需要网络安全。

最初发表于 https://www.wallarm.com。