服务器端模板注入（SSTI）：高级利用指南

不确定如何为报告的漏洞设定奖励？我们分析了640多个跨行业的漏洞赏金计划，帮助您做出明智决策。公平奖励您的研究人员——立即尝试我们的漏洞赏金计算器！

尝试我们的漏洞赏金计算器

博客
黑客工具
SSTI：利用高级服务器端模板注入的完整指南
作者：blackbird-eu
2025年6月15日

服务器端模板注入（SSTI）漏洞在现代应用中仍然存在，因为开发人员继续在全面实施适当的输入验证方面遇到困难。然而，尽管存在这一事实，漏洞赏金猎人仍然偶尔会忽略这类注入漏洞，常常导致有影响的漏洞未被报告。主要原因是识别部分在实践中通常很困难。

在本文中，我们将揭示SSTI漏洞为何如此危险，并带您了解有效识别、利用和武器化它们的技术。我们还将探索跨不同模板引擎的高级和独特利用场景。

让我们开始吧！

什么是模板引擎？

开发人员经常使用模板引擎来将UI和其他静态组件（HTML模板文件）与应用程序逻辑和动态数据（用户输入）结合，以生成服务器响应。这种代码组件的重用使得开发过程更加 streamlined。模板引擎的工作原理是获取包含静态内容和特殊模板语法（用于占位符、变量和逻辑，如循环和条件）的模板文件，然后使用用户提供或应用程序数据处理此模板，以生成最终渲染的内容。

流行的模板引擎包括：

Python：Jinja2、Mako
PHP：Twig、Smarty
JavaScript：EJS、Handlebars、Pug
Java：Thymeleaf、FreeMarker、Pebble
C#：Razor
Ruby：ERB、HAML、Slim

什么是服务器端模板注入（SSTI）漏洞？

服务器端模板注入（SSTI）漏洞发生在未净化的用户输入直接连接到模板引擎时，允许攻击者注入恶意模板语法，该语法在服务器端进行评估。当Web应用程序将用户输入作为模板的一部分处理，而不是将其视为纯数据（处理用户输入的安全方式）时，攻击者可以利用模板引擎的内置函数来渲染自定义数据、访问秘密、读取本地文件，甚至实现远程代码执行。

更喜欢观看快速视频？查看我们YouTube频道上的“SSTI in 100 seconds”！

识别服务器端模板注入（SSTI）漏洞

在识别潜在的模板注入漏洞之前，我们必须检测是否正在使用模板引擎以及我们的注入点在哪里。这涉及通过注入模板引擎语法并观察应用程序的响应是否返回任何可能的服务器端评估迹象来系统测试用户输入字段。我们还可以使用指纹识别工具来检查是否正在使用模板引擎，尽管这种方法有其局限性。

强制应用程序返回服务器端评估指示的一种方法是故意触发错误。为此，我们需要发送以下特殊字符列表，这些字符可以破坏现有的模板引擎语法：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


{
}
$
#
@
%)
"
'
|
{{
}}
${
<%
<%=
%>

注意：仅当当前配置设置未故意抑制错误消息时，错误才可见。

一旦我们确认了可能的注入点，我们就可以进入识别部分，这通常涉及发送不同的模板注入payload并观察被评估的payload。这一部分至关重要，因为它将帮助我们在利用过程中确定模板引擎以制作payload。

所有模板引擎都使用不同的语法。然而，您会注意到一些引擎有相似之处。让我们看几个常用的模板引擎。

Jinja2 (Python)

Jinja2是迄今为止最流行的基于Python的模板引擎。为了验证是否使用了Jinja2，漏洞赏金猎人通常注入一个简单的数学函数，例如：

1
2


{{7*7}}
{{7*'7'}}

如果存在注入漏洞，您应该在目标服务器的响应中观察到以下输出：

Twig (PHP)

Twig遵循与Jinja2类似的语法。我们可以注入以下函数来验证我们的模板注入payload是否被评估：

1
2


{{7*7}}
{{7*'7'}}

响应应包含此简单数学操作的输出：

ERB (Ruby)

ERB是另一个流行的模板引擎，常见于基于Ruby的应用程序中。此模板引擎遵循不同的语法。以下应在易受攻击的应用程序中渲染49：

1

<%= 7*7 %>

现在我们对模板注入漏洞有了基本了解，我们可以深入利用阶段，学习如何武器化这些简单的SSTI payload以实现RCE。

提示！确保不要将服务器端模板注入与客户端模板注入混淆。对于服务器端模板注入，payload评估完全发生在服务器端。相反，客户端模板注入（例如在AngularJS或VueJS中）仅在客户端评估，通常导致JavaScript代码执行。

利用基本SSTI漏洞

模板注入在ERB (Ruby)中

让我们看一个简单的易受攻击的代码片段示例，以更好地帮助我们理解模板注入是如何产生的，以及我们如何利用它们来实现远程代码执行：

模板注入在ERB (Ruby)中

正如您可能已经注意到的，开发人员（无意识地）在第7行直接将未净化的用户输入传递到模板中，允许任何人发送将在服务器端评估的ERB模板。

一个简单的数学payload如下验证服务器端执行：

1

%><%=7*7

甚至：

1

7*7

两个payload都将在服务器的响应中渲染49。

升级模板注入到RCE在ERB (Ruby)中

为了证明影响，我们可以执行系统命令或读取内部文件。执行系统命令，例如使用sleep诱导时间延迟或启动出站TCP连接，通常用于验证盲服务器端模板注入。

在ERB (Ruby)中，执行远程命令相当简单。回到我们的简化示例，如果我们发送以下payload：

1

%><%=`whoami`

我们实际上能够看到当前运行进程的系统用户，在这种情况下是root：

注意：特殊字符需要进行URL编码才能被模板引擎正确转发和解析。

提示！除了官方模板文档外，社区驱动的资源（如Swisskyrepo）是找到所有类型注入漏洞（包括服务器端模板注入）的工作payload的绝佳方式！

利用高级SSTI漏洞

在大多数情况下，利用模板注入漏洞是直接的。可以通过浏览模板引擎的官方文档或查找先前研究人员的文章来找到工作payload。

您会遇到目标运行的环境专门设计为防止可能的升级（例如沙箱）的情况。让我们更深入地研究简单函数调用不可用的情况。

沙箱环境中的模板注入

当直接函数（读取文件或执行系统命令）被限制或不可用时，例如在沙箱环境中，我们需要 resort to alternative exploitation methods。这可以通过查找内部预定义的自定义对象（参见下一节）或链接对象并使用本机模板引擎功能来完成。

让我们首先看另一个简化示例。

模板注入在Twig (PHP)中

在此沙箱环境中，直接函数如file_get_contents()或system()被阻止。然而，我们可以通过使用Twig的本机功能来利用注册的全局对象来绕过限制：

1
2
3


{%block X%}whoamiINTIGRITIsystem{%endblock%}
{%set y=block('X')|split('INTIGRITI')%}
{{[y|first]|map(y|last)|join}}

为了理解为什么此payload exactly works，让我们完全解构它。第一部分定义了名为X的块，其值等于我们要执行的系统命令、唯一分隔符和过滤器：

1
2
3


{%block X%}
whoamiINTIGRITIsystem
{%endblock%}

第二部分是另一个Twig语句，用于分隔在块X中声明的值：

1

{%set y=block('X')|split('INTIGRITI')%}

最后，我们使用过滤器映射提取的字符串值（whoami），在这种情况下是system：

1

{{[y|first]|map(y|last)|join}}

这允许我们使用变通方法执行系统命令，类似于使用函数调用。仅在这种情况下，环境是沙箱化的，不允许直接调用。

您始终可以浏览网络以找到类似的、替代的模板注入payload，这些payload提供沙箱绕过。

利用内部对象武器化SSTI

当直接函数调用不可用时，武器化模板注入的第二种方法是查找内部预定义的自定义对象，并搜索硬编码的秘密或不安全的函数调用。两种方法的唯一要求是对目标应用程序有更深入的了解。

让我们首先看另一个简化示例。以下代码片段展示了Twig (PHP)中的模板注入。然而，这次它还包含全局模板变量。

武器化模板注入与自定义对象在Twig (PHP)中

在这种情况下，我们可以清楚地注意到开发人员添加了2个自定义模板变量。在无法访问源代码的真实场景中，我们可以使用Twig的特殊变量：_context以及keys过滤器来列出和枚举所有模板变量，以映射出对象中的所有变量名称（键）。此外，我们使用join过滤器来分隔对象名称：

1

{{_context|keys|join(',')}}

此payload揭示了2个模板变量：files和secrets。files是对FileAccessMgmt PHP类的引用，该类列出了一个不安全的函数：get_style_sheet。secret是对全局模板变量的引用。在这种情况下，它可能持有从环境变量检索的数据库连接秘密的副本。

武器化SSTI以泄露自定义对象中的秘密

知道有一个声明了环境秘密的全局模板变量，我们可以尝试通过简单地访问正确的属性来返回敏感数据：

1

{{secrets.MYSQL_PASSWD}}

此payload将返回MYSQL_PASSWD环境变量的内容。

升级模板注入与不安全的自定义对象函数

下一个全局模板变量是对PHP类的引用。每当不允许直接函数访问时，我们可以尝试枚举内部对象函数，并利用这些函数读取本地文件、泄露秘密甚至执行系统命令。在无法访问源代码的真实场景中，您必须系统地探测所有自定义函数以升级您的初始发现。

在此简化示例中，我们只需要使用如下payload，它将允许我们利用不安全的函数通过简单路径遍历读取本地系统文件：

1

{{files.get_style_sheet('../../../../../etc/passwd')}}

虽然本文未记录所有模板引擎的利用场景，但每当您尝试利用模板注入时，基本原理保持不变：

步骤1始终涉及枚举模板引擎。此阶段包括系统地探测模板语法字符串并观察响应。

接下来，步骤2要求您查找可用文档以枚举全局函数调用，以执行系统命令、读取本地文件或启动出站TCP连接。

如果直接函数调用不可用（例如，在沙箱环境中），您可以尝试枚举并利用导入的包和依赖项。这将允许您仍然将您的初始发现升级到更高严重性的漏洞。

结论

在2025年测试服务器端模板注入（SSTI）仍然至关重要，尤其是因为开发人员继续在充分验证用户输入方面遇到困难。在本文中，我们已经介绍了多种识别和武器化模板注入以利用此漏洞的方法。

所以，您刚刚学到了关于服务器端模板注入（SSTI）漏洞的新知识……现在，是时候将您的技能付诸实践了！您可以通过在易受攻击的实验室中练习或……浏览我们在Intigriti上的70多个公共漏洞赏金计划来开始，谁知道呢，也许在您的下一次提交中赚取赏金！

立即在INTIGRITI上开始黑客活动

您可能还喜欢
GitHub dorking for beginners: How to find more vulnerabilities using GitHub search
2025年7月13日
继续阅读
Exploiting Log4Shell (Log4J) in 2025
2025年6月29日
继续阅读
Discovering hidden parameters: An advanced guide
2025年6月3日
继续阅读