介绍

几乎任何软件开发或其他相关元素都落入了网络漏洞的陷阱。用于服务器端 HTML 代码管理的模板就是其中之一。针对服务器端模板的攻击被称为 SSTI（缩写）。让我们详细探索它的每个方面。

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

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

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

理解 SSTI 过程的简单方法是通过真实示例进行解释。现在考虑以下场景；您正在使用营销应用程序来发送客户电子邮件，并使用 Twig 模板系统按姓名来称呼电子邮件收件人。

如果在模板中添加名称而不授予收件人任何修改权限，那么事情就会顺利进行。一旦允许收件人自定义电子邮件，发件人就会开始失去对模板内容的控制权。

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

SSTI 攻击并非总是有预谋的；有时，当用户端输入直接与模板接触时，它会在不知不觉中发生。这种情况为威胁行为者提供了引入模板引擎扭曲命令并按照他们的意愿操作服务器的机会。在每种情况下，SSTI 攻击的结果大多是破坏性的。

服务器端模板如何工作？

开发人员经常使用这些模板来创建预填充的网页，其中包含定向到服务器的自定义最终用户数据。使用这些模板可以减少服务器端请求处理过程中浏览器到服务器的通勤。

由于服务器端模板为预嵌入的用户输入提供了极大的灵活性和快捷方式，因此它常常被误认为是 XXS 或跨站点脚本。

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

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

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

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

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

例如：

POST /端点详细信息 HTTP/1.1主机：example.comparameter=test_data

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

1. 您可以发送多语言值，例如 ${{<%[%'”}}%\.，这是此类测试中常用的特定模式。引擎显示错误消息后，您可以诊断警报文本中的 URL，并找出要尝试的模板引擎的正确语法。
2. 当错误消息未显示引擎详细信息时，请使用对各种模板引擎有用的已知语法，例如：

=${7*3}

=<%= 7*3%>

={{7*3}}

接下来，读取调试输出（例如，对于 Django）。不同的模板引擎执行此操作的方式略有不同。

POST /端点详细信息 HTTP/1.1主机：example.comparameter={% debug %}

此请求将获取可读对象列表，可用于调试。从这里，像“设置”这样的对象也可能是可访问的。因此，尝试读取密钥并查看是否可以成功：

POST /endpoint-detail HTTP/1.1Host: example.comparameter={{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 入侵的有效方法。您的提交将强制服务器端系统发出错误消息，以提供关键细节。

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

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

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

‍

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

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

因此，开发人员和安全专家必须寻找其他方法来使应用程序和网站远离 SSTI 的攻击范围。以下是一些专家认可的 SSTI 预防策略。

1. 有限的“编辑”权限

无论如何，模板不应该向除开发人员和管理员以外的任何人开放修改和更改。对所有人开放的模板很容易成为黑客的目标。因此，明智的做法是对模板执行访问规则并限制其可访问性。然而，这并不是一个可以一直实现的目标。

2. 快速审查

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

3.沙盒

为了更好地防范 SSTI，沙盒是比清理更好的选择。这是一种预防方法，涉及为用户创建一个安全且封闭的生态系统。封闭的环境没有危险的功能和模块，同时在发现任何漏洞时限制对其他数据的访问。虽然它的功效值得称赞，但实施起来却是一项艰巨的任务。此外，很容易通过疏忽或错误配置来绕过它。

4. 选择无逻辑模板

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

5.利用Docker容器

如果上述解决方案均不起作用，那么防御者必须承认远程代码执行是不可避免的，并且应该尝试通过在完全锁定的 Docker 容器中执行模板引擎来实现定制的沙盒来减少其影响。

结语

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