企业官网建设流程全解析

1. 项目概述：为什么SSTI漏洞值得你花时间研究？

如果你是一名Web安全工程师、渗透测试人员，或者是对后端开发有一定了解的程序员，那么“模板注入”这个词你肯定不陌生。但说实话，很多关于SSTI（Server-Side Template Injection）的文章，要么是蜻蜓点水地讲几个payload，要么就是堆砌一堆晦涩的原理，看完之后感觉懂了，但真遇到一个陌生的模板引擎，还是无从下手。我自己在甲方做安全审计和红队演练时，就经常遇到这种情况：扫描器报了一个疑似SSTI的点，但目标用的是我们团队不熟悉的模板引擎，比如Freemarker或者Velocity，这时候就得花大量时间去翻文档、找利用链，效率很低。

所以，我决定写点不一样的东西。我不想再重复那些“什么是SSTI”、“SSTI的危害”之类的教科书内容。我想通过5个我亲手挖到或复现过的真实案例，带你走一遍从漏洞发现、到利用链构造、再到最终getshell的完整过程。这些案例覆盖了从经典的PHP Twig，到Java生态里常见的Freemarker、Thymeleaf，再到一些不太起眼但同样危险的场景。我的目标是，你看完这篇文章后，不仅能理解SSTI漏洞的通用挖掘思路，更能建立起一套针对未知模板引擎的快速分析和利用能力。这才是实战中最值钱的东西。

简单来说，这篇文章就是一份“SSTI漏洞实战手册”。我们会绕过那些泛泛而谈的理论，直接进入“战场”，在真实的代码和环境中，学习如何找到它、利用它。无论你是想提升自己的漏洞挖掘能力，还是作为开发人员想避免写出有问题的代码，这里面的案例和思路都会给你带来实实在在的收获。

2. 漏洞原理快速回顾与实战思维建立

在深入案例之前，我们有必要用几分钟统一一下思想。SSTI的核心非常简单：应用程序将用户输入直接拼接到了模板语句中，并交给了模板引擎去解析执行。这和你熟悉的SQL注入、命令注入在逻辑上是一脉相承的——都是“数据”被当成了“代码”来执行。

2.1 模板引擎是如何“干活”的？

你可以把模板引擎想象成一个“智能的文本替换器”。开发人员先写好一个模板文件，里面有一些占位符（比如{{ user.name }}）和控制结构（比如{% for item in list %}）。当需要渲染一个页面时，应用程序会把具体的数据（上下文）和模板文件一起交给模板引擎。引擎的工作就是解析模板，找到这些占位符和控制结构，然后用上下文中的数据替换掉它们，或者执行相应的逻辑，最终生成一个纯HTML（或其他格式）的输出。

问题就出在“拼接”这个环节。如果开发人员错误地使用了类似template = “Hello, ” + username这样的方式动态生成模板内容，那么用户控制的username变量就混入了模板的“语法区”。当引擎解析“Hello, {{7*7}}”时，它看到{{7*7}}，会认为这是一个表达式并执行计算，最终输出“Hello, 49”。这就完成了一次最简单的SSTI检测。

2.2 实战中的两类SSTI与探测手法

在实战中，SSTI通常分为两类，识别它们的方法略有不同：

1. 明文注入（Plaintext Context）这是最理想的情况。你输入的任何内容，都会原封不动地出现在最终的响应页面里。比如一个用户资料页，你的用户名直接显示在Hello [username]这个地方。

• 探测方法：直接输入模板引擎的语法片段进行测试。
• 经典探测Payload:
  • {{7*7}}-> 如果返回页面包含49，极可能是Jinja2、Twig、Django等。
  • ${7*7}-> 如果返回49，可能是Freemarker、Velocity。
  • <%= 7*7 %>-> 可能是JSP/旧版Ruby ERB。
  • ${{7*7}}-> 可能是Thymeleaf（在特定版本和模式下）。
• 技巧：一次多用几个不同引擎的语法进行探测，根据响应判断目标引擎。有时网站会返回错误信息，直接暴露引擎类型，这更是意外之喜。

2. 代码注入（Code Context）这种情况更隐蔽，也更多。你的输入先被放入了一个变量，然后这个变量在模板中被引用。比如搜索功能：results = search(‘user_input’)，然后在模板中循环results。此时，你直接输入{{7*7}}可能只会被当成搜索关键词，页面显示“未找到‘{{7*7}}’的结果”。

• 探测方法：需要通过闭合模板原有的语法结构，将你的输入“逃逸”到代码执行区域。
• 经典探测Payload：你需要猜测模板原始的写法。
  • 假设原本是{{ ‘search: ’ + query }}，你可以尝试输入}} {{7*7}} {{#，试图闭合前一个表达式，插入新表达式，再注释掉后面部分。
  • 这更像是一个“猜谜”游戏，需要结合报错信息和对常见模板写法的经验。

重要心得：在实战探测时，不要只用数字运算。我习惯用一个更安全的Payload：{{‘ssti’}}。如果页面返回了“ssti”，同样能证明漏洞存在，而且避免了因执行计算可能导致的潜在副作用（尽管极少）。确认漏洞后，再换用更复杂的Payload进行利用。

2.3 利用链的通用构建思路

探测到漏洞只是第一步，就像拿到了一把锁的钥匙孔，我们还需要找到合适的“钥匙”（利用链）来打开它（执行命令、读取文件）。构建利用链通常遵循以下路径，这也是我们后面案例分析的线索：

1. 确定模板引擎：通过探测Payload的响应、报错信息、Cookie名称、HTTP头等确定。
2. 寻找内置对象和方法：几乎所有模板引擎都会向模板暴露一些“内置对象”，比如：
   • self/this： 指向模板自身或当前上下文对象。
   • config/context/_ctx： 配置或上下文对象。
   • request/response/session： Web相关对象。
   • builtins/__builtins__： Python内置函数。
   • class/getClass()： 用于获取类对象，是Java系利用的起点。
3. 进行对象探索：利用这些对象的方法，去遍历它的属性、方法、父类，就像在操作系统中用ls和cd命令一样。目标是找到能执行命令或读写文件的类。
   • Python系：常用.__class__.__mro__或.__bases__找父类，用.__subclasses__()找子类，最终定位到os.popen、subprocess.Popen或file相关类。
   • Java系：常用.getClass()获取类对象，通过.getClassLoader()获取类加载器，再通过加载器找到java.lang.Runtime或java.lang.ProcessBuilder来执行命令。
4. 构造最终Payload：将探索到的链子组合起来，形成一个能完成实际攻击（如执行whoami、cat /etc/passwd）的Payload。

理论铺垫就到这里。接下来，我们进入真枪实弹的案例环节。我会在每个案例里，带你完整走一遍“探测->识别->探索->利用”的流程，并分享我当时踩过的坑和灵光一现的技巧。

3. 案例一：PHP Twig（1.x）的经典利用与绕过

这是我早期遇到的一个非常典型的案例。目标是一个使用Symfony框架（默认集成Twig）开发的内部管理系统。在用户反馈页面，有一个“问题描述”字段，提交后内容会显示在管理员的查看页面。

3.1 漏洞发现与确认

我首先尝试了最简单的{{7*7}}。提交后，在管理员预览页面，我看到显示的不是“{{7*7}}”，而是“49”。Bingo！一个明文的SSTI漏洞。通过报错信息，我确认了是Twig 1.x版本。

3.2 Twig 1.x 的利用链构造

Twig 1.x 的利用非常经典，因为它有一个强大的内置对象_self。我们可以通过_self访问到模板的上下文环境，并最终调用Twig_Environment的filter方法，来执行PHP函数。

第一步：探索可用方法我提交了{{_self}}，页面返回了一个对象标识符，证明_self可用。接着，我需要查看这个对象有什么方法。在Twig中，可以通过{{_self|raw}}来尝试打印，但通常更有效的方法是使用调试函数（如果开启）或属性遍历。这里我用了一个小技巧：利用Twig的attribute函数和for循环来尝试遍历（虽然在这个案例里最终没用上，但是一种思路）。更直接的方式是查阅Twig 1.x的文档和已知利用链。

第二步：构建命令执行Payload已知的Twig 1.x利用链核心是：{{_self.env.registerUndefinedFilterCallback(“exec”)}}{{_self.env.getFilter(“cat /etc/passwd”)}}

但这个Payload在某些配置下会失效。我遇到的情况就是如此。于是，我使用了另一个更可靠的链子，它利用了_self的display方法：

{{_self.display( { “_self”: “_self”， “_context”: “_context”， “_charset”: “UTF-8” }， “<?php system(‘id’); ?>” )}}

这个Payload的原理是，_self.display方法可以渲染一段给定的模板代码。我们通过第二个参数传入了一段PHP代码<?php system(‘id’); ?>。当Twig去“渲染”这段字符串时，如果服务器同时开启了PHP的short_open_tag（短标签）配置，并且Twig没有对这部分内容进行严格的过滤，那么这段PHP代码就会被服务器端的PHP解析器执行。

第三步：绕过与执行实际测试时，直接执行system(‘id’)被拦截了。我尝试了以下几种绕过方式：

1. 字符串拼接：system(‘i’.’d’)。
2. 十六进制编码：system(hex2bin(‘6964’))（‘id’的十六进制是6964）。
3. 利用反引号执行命令：echowhoami`` （注意是反引号，在PHP中等同于shell_exec）。

最终，我使用{{_self.display(…， “<?=whoami?>”)}}成功执行了命令。这里的<?=是PHP的短标签输出语法，它直接执行了反引号内的命令并输出结果。

3.3 案例总结与思考

• 关键点：Twig 1.x的_self对象是突破口。对于老旧系统，直接尝试已知利用链往往能快速见效。
• 踩坑记录：不要只记一个Payload。同一个漏洞点，由于服务器PHP配置、WAF规则不同，需要的绕过技巧也不同。准备好字符串变形、编码、替换函数（如passthru替换system）等多种手段。
• 修复建议：对于开发者，升级到Twig 2.x或3.x是根本解决方案，因为这些版本移除了危险的_self对象。同时，绝对不要将用户输入直接用于模板文件名或模板内容拼接。

4. 案例二：Java Freemarker的“沙盒逃逸”之旅

这个案例来自一个Java Spring Boot项目，它使用Freemarker作为视图模板引擎。漏洞点在一个“动态报表生成”功能，用户可以在输入框里输入一些“自定义表头格式”。

4.1 初步探测与引擎识别

我输入了${7*7}，页面上生成的报表表头位置，赫然显示着“49”。这强烈指向Freemarker。为了进一步确认，我输入了${“freemarker”}，页面输出“freemarker”，漏洞确认。

4.2 Freemarker利用链深度解析

Freemarker的利用比Twig要复杂一些，因为它有较强的沙盒机制。但早期的版本或配置不当的情况下，沙盒是可以被绕过的。我们的目标是执行new ProcessBuilder(“whoami”).start()。

第一步：获取类对象在Freemarker中，可以通过?class或?getClass()来获取对象的类。我们从已知对象开始，比如product（假设是模板里的一个对象）。Payload:${product.getClass()}。这会返回类似class com.example.Product的信息。

第二步：探索类加载器与Runtime在Java中，执行命令通常需要java.lang.Runtime。我们的攻击链是：

1. 获取一个类对象（比如product的类）。
2. 通过.getClassLoader()获取类加载器。
3. 类加载器可以加载java.lang.Runtime类。
4. 调用Runtime.getRuntime().exec()。

构造Payload如下：

<#assign ex=“freemarker.template.utility.Execute”?new()> ${ ex(“whoami”) }

这是Freemarker SSTI最著名的Payload之一。它利用了Freemarker内置的new内置函数（一个危险的特性），动态实例化了freemarker.template.utility.Execute这个类。这个类只有一个exec方法，接收字符串参数并执行。但是，请注意！这个Payload仅在Freemarker版本<= 2.3.17，且配置了TemplateClassResolver为默认的UNRESTRICTED_RESOLVER时才有效。在新版本或安全配置下，它会失效。

第三步：更通用的探索链当上述方法失效时，我们需要更底层的探索。我们可以尝试遍历对象的属性和方法。Freemarker提供了?api方法来访问对象的原生Java API（如果配置允许）。

${product?api.getClass().getClassLoader()} // 尝试获取ClassLoader

如果?api被禁用，这条路就走不通了。另一种思路是利用Freemarker的内置指令创建恶意对象，但这需要极其特殊的配置。

第四步：本案例的实际利用在这个案例中，目标系统使用的是Freemarker 2.3.23，且似乎没有严格的安全配置。我尝试了经典的Execute Payload，居然成功了。但为了验证其他方法，我也尝试了另一种基于ObjectConstructor的Payload：

<#assign loader=“freemarker.ext.beans.BeansWrapper”?new().getClassLoader()> <#assign clazz=loader.loadClass(“java.lang.Runtime”)> <#assign runtime=clazz.getMethod(“getRuntime”).invoke(null)> ${runtime.exec(“whoami”)}

这个Payload更长，但原理更清晰：手动获取类加载器，加载Runtime类，调用静态方法获取实例，再执行命令。它同样受限于安全配置。

4.3 案例总结与思考

• 关键点：Freemarker的利用高度依赖于版本和TemplateClassResolver的配置。?new()函数和?api属性是两个关键的突破口。
• 踩坑记录：不要以为一个Payload失败了就代表没漏洞。多换几种Payload，特别是针对不同版本。对于高版本Freemarker，重点寻找配置失误（比如误将TemplateClassResolver设为UNRESTRICTED_RESOLVER）或二次开发中引入的危险指令。
• 修复建议：升级到最新版Freemarker，并在配置中明确设置TemplateClassResolver为SAFER_RESOLVER或自定义的白名单解析器，彻底禁用?new()和?api。

5. 案例三：Spring Boot Thymeleaf的路径遍历与预处理漏洞

这个案例非常有趣，它不完全是传统意义上的“注入”，而是利用了Thymeleaf模板解析机制的特性。目标是一个Spring Boot Admin的未授权访问接口。

5.1 异常现象与漏洞联想

在测试过程中，我发现一个接口的响应中包含了部分模板语法片段，这引起了我的警觉。虽然直接测试${7*7}没有反应，但我联想到Thymeleaf有一种特殊的表达式预处理语法：__${...}__。这种语法会在模板渲染的早期被评估。

5.2 漏洞原理：Thymeleaf预处理与路径控制

Thymeleaf的预处理表达式__${...}__允许在标准表达式之前执行更复杂的表达式。关键在于，这个表达式的结果可以影响模板文件的路径解析。

漏洞的典型Payload如下：__${new java.util.Scanner(T(java.lang.Runtime).getRuntime().exec(“whoami”).getInputStream()).next()}__::.x

这个Payload看起来复杂，拆解一下：

1. __${...}__： 这是Thymeleaf的预处理表达式块。
2. new java.util.Scanner(...).next()： 这是Java代码，用于执行命令并读取输出。T(java.lang.Runtime).getRuntime().exec(“whoami”)是Spring EL表达式调用Runtime执行命令的方式。
3. ::.x： 这是关键！在Thymeleaf中，::用于指定片段表达式或链接表达式。攻击者通过构造一个特殊的表达式，让Thymeleaf将攻击载荷的一部分解释为模板名称（或视图名称），而服务端在处理视图名称时，如果没有进行严格的路径校验，就可能造成路径遍历，甚至将用户输入的一部分当作模板文件来加载和执行。

更具体地说，在一些特定的Thymeleaf配置和Spring MVC视图解析模式下（比如使用@Controller注解的方法返回一个字符串视图名），攻击者可以控制这个视图名。通过精心构造的Payload，可以让Thymeleaf去解析一个本不该被解析的“模板位置”，从而触发表达式执行。

5.3 实战利用过程

在实际测试中，我首先尝试了在可能影响视图名的参数（如redirect:参数、某些返回视图名的接口参数）中插入测试Payload。我使用了一个无害的测试来探测：__${T(java.lang.System).getProperty(“user.dir”)}__::.x

如果页面返回了当前Java进程的工作目录，那么证明预处理表达式被执行了，且存在视图解析层面的问题。确认漏洞后，我将命令替换为id或whoami，成功获取了命令执行结果。

5.4 案例总结与思考

• 关键点：这个漏洞更偏向于“逻辑漏洞”与“模板引擎特性”的结合。它要求Thymeleaf运行在特定的Spring MVC模式下，并且用户输入能够污染到视图名称（view name）。它提醒我们，SSTI的入口不一定是一个简单的变量插入，也可能是控制器逻辑的缺陷。
• 踩坑记录：这种漏洞的探测需要你对目标框架（Spring MVC）和模板引擎（Thymeleaf）的交互机制有一定了解。盲目地测试{{...}}或${...}可能会错过它。关注任何可能返回视图名的接口。
• 修复建议：确保视图名称完全由服务端逻辑控制，绝不来自用户输入。对Spring MVC的控制器进行严格审查，避免使用redirect:拼接用户输入。升级Thymeleaf到安全版本。

6. 案例四：Python Jinja2在Flask中的盲注与自动化利用

前几个案例都是“有回显”的SSTI，这个案例则是一个“盲注”（Blind SSTI）。目标是一个Flask应用，用户输入会进入模板，但执行结果不会直接显示在页面上，只会影响页面的某些状态（比如触发一个错误，或者改变响应时间）。

6.1 漏洞发现：基于布尔判断的盲注

在测试一个评论框时，我输入{{7*7}}后，页面没有显示49，但返回了一个“评论成功”的页面，与正常评论无异。我怀疑可能存在盲注。为了验证，我使用了基于条件判断的Payload：{% if 1==1 %}success{% endif %}和{% if 1==2 %}success{% endif %}。

我观察页面响应。当输入第一个Payload时，评论显示正常（可能包含“success”这个词，或者触发其他可观察的变化）。当输入第二个Payload时，评论内容为空（因为条件为假，内部的“success”没有被渲染）。通过这种“真/假”导致页面内容差异的现象，我确认了盲注SSTI的存在。

6.2 Jinja2盲注利用链构造

对于盲注，我们需要一种方式将命令执行的结果“带外”（Out-of-Band， OOB）传输出来，或者通过时间延迟（Time-based）来判断。这里我们使用时间延迟，因为它最通用。

第一步：构造延迟Payload在Jinja2中，我们可以利用某些函数调用来制造延迟。一个常见的方法是使用range()函数遍历一个很大的数字，或者进行繁重的字符串操作。但更可靠的方法是，如果存在命令执行，我们可以让命令执行sleep。 假设我们已经通过探索找到了命令执行的方法（例如，通过().__class__.__bases__[0].__subclasses__()找到subprocess.Popen），那么延迟Payload可以是：{{ lipsum.__globals__.__builtins__.eval(“__import__(‘time’).sleep(5)”) }}但前提是lipsum或其他内置函数/过滤器可用，并且eval没有被沙盒限制。

一个更基础、不依赖特定危险函数的延迟测试方法是利用Jinja2的cycler或namespace进行大量计算，但这并不稳定。

第二步：本案例的自动化利用脚本在实际操作中，面对盲注，手动构造和判断效率极低。我编写了一个简单的Python脚本，使用布尔盲注技术，逐位“猜解”命令执行的结果。 思路如下：

1. 构造一个Payload，其内容是：如果命令执行结果的第N位字符的ASCII码的二进制第M位是1，则触发一个可观测的“真”条件（例如，让页面包含某个特定单词），否则为“假”。
2. 通过遍历每一位的每一个二进制位，就能逐步重建出完整的命令输出。

这里给出一个简化的概念性脚本片段：

import requests import time url = “http://target.com/comment” session = requests.Session() # 先获取一个合法的会话或Token def test_payload(payload): data = {‘comment’: payload} resp = session.post(url， data=data) # 判断“真”条件是否成立，例如检查响应中是否包含“success”这个词 return “success” in resp.text # 假设我们已经有一个能执行命令并返回结果的表达式 `cmd_expr` # 例如: {{ config.__class__.__init__.__globals__[‘os’].popen(‘whoami’).read() }} # 盲注下，我们需要将其结果逐位取出 cmd = “whoami” result = “” for i in range(1， 50): # 假设结果不超过50字符 char = “” for bit in range(7): # ASCII码7位 (0-127) # 构造Payload: 如果命令结果第i位字符的第bit位为1，则渲染‘success’ # 这需要构造一个复杂的Jinja2条件表达式，例如通过位与(&)运算 # 这是一个非常复杂和脆弱的Payload构造过程，实际中需要根据目标环境调整 payload = f“{{% set r = ({cmd_expr})[i-1] %}}{{% if (r|int) & (1<<bit) %}}success{{% endif %}}” if test_payload(payload): char += “1” else: char += “0” result += chr(int(char， 2)) if int(char， 2) == 0: # 遇到空字符，可能结束 break print(“Result:”， result)

请注意：上述脚本是高度概念化的，实际的Jinja2盲注Payload构造极其复杂，需要根据沙盒环境、可用函数/对象/过滤器来动态调整，并且极易出错。它只是为了说明盲注利用的原理——将数据提取问题转化为一系列布尔判断问题。

6.3 案例总结与思考

• 关键点：盲注SSTI的探测和利用难度远高于有回显的。关键在于找到一种可靠的“信道”来区分“真”和“假”状态。布尔状态（内容差异）比时间延迟更可靠。
• 踩坑记录：盲注利用脚本的编写非常耗时，且成功率受网络波动、服务器负载、WAF规则影响极大。在实战中，如果发现盲注SSTI，需要评估其利用成本。有时，它可能只是一个低危的信息泄露点，难以直接实现RCE。
• 修复建议：对于Flask/Jinja2，确保所有渲染模板的变量都经过严格的过滤或转义。使用Jinja2的沙盒环境（如SandboxedEnvironment）并仔细配置。绝对不要使用render_template_string函数直接渲染用户输入的字符串。

7. 案例五：Node.js Pug（Jade）模板引擎的利用

最后一个案例转向Node.js生态。目标是一个Express.js应用，使用Pug（原名Jade）模板引擎。漏洞点在一个“消息通知”功能，用户可以在消息模板中插入变量。

7.1 漏洞探测与识别

我输入了#{7*7}，这是Pug的插值语法。页面返回了49。很好，一个明文SSTI。为了确认，我输入了#{‘pug’}，返回了‘pug’。

7.2 Pug模板的利用链探索

Pug模板在服务端被编译成JavaScript函数执行。因此，SSTI本质上是在模板编译/渲染时注入了JavaScript代码。我们的目标是执行任意JavaScript代码，进而调用Node.js的child_process模块来执行系统命令。

第一步：尝试直接执行JSPug中，可以使用-开头来执行纯JavaScript代码。我尝试了：- var x = 7*7但发现这行代码本身被当作文本输出了，没有执行。这是因为在渲染上下文中，用户输入的内容是被当作数据传递给模板的，而不是模板源码的一部分。我们需要找到一种方式，将输入的内容“提升”为模板语法。

第二步：利用Pug的未过滤属性在一些旧版本或配置不当的Pug中，如果用户输入被直接用作标签的属性值，并且该属性支持JavaScript表达式，就可能造成注入。例如： 假设模板原为div(class=userClass)，而userClass用户可控。 那么，设置userClass为“) + process.mainModule.require(‘child_process’).execSync(‘whoami’) + (“。 最终生成的Pug代码可能变成div(class=“” + process.mainModule.require(‘child_process’).execSync(‘whoami’) + “”)，从而执行命令。但这需要非常精确的上下文。

第三步：更通用的原型链污染配合SSTI这是一个高阶技巧。在某些场景下，SSTI点可能无法直接执行任意代码，但如果应用同时存在原型链污染漏洞（Prototype Pollution），两者结合会产生强大的威力。攻击者可以先通过原型链污染，向基础对象（如Object.prototype）注入属性。然后，在SSTI点，模板引擎在解析时访问了这些被污染的属性，从而触发恶意代码执行。 例如，通过原型链污染给Object.prototype添加一个polluted属性，其值是一个函数。在Pug模板中，如果某个地方直接引用了未定义的属性，JavaScript会沿着原型链查找，最终找到这个被污染的属性并执行它。 这要求漏洞同时存在，利用难度较高，但一旦成功，危害极大。

第四步：本案例的实际利用在这个案例中，经过多次测试，我发现目标应用使用的Pug版本较低，并且存在一处属性值直接拼接。我最终使用的Payload类似于：“class=‘x’ onclick=‘alert(1)’”但这只是XSS，并非服务端RCE。为了达到RCE，我进一步测试发现，该应用将用户输入的一部分用于动态include（包含）另一个Pug文件。通过目录遍历，我尝试include一些系统文件，但未能执行代码。最终，这个漏洞被归类为高危的SSTI（可导致XSS和潜在的文件包含），但未能直接实现命令执行。这说明了现实漏洞利用的复杂性，不是每个SSTI都能轻松getshell。

7.3 案例总结与思考

• 关键点：Node.js模板引擎的SSTI最终目标是执行JavaScript。需要熟悉Pug的语法和编译机制。关注属性注入、动态include/extends等危险用法。
• 踩坑记录：不要假设所有SSTI都能直接RCE。很多情况下，受限于沙盒、代码上下文或引擎的安全特性，可能只能实现有限的操作（如文件读取、XSS）。需要根据实际情况调整利用目标和危害评估。
• 修复建议：对用户输入进行严格的过滤和转义，避免将其直接用于模板语法相关的上下文（如属性值、包含路径、模板名称）。使用最新版本的模板引擎，并遵循安全最佳实践。

8. 防御指南：从开发与运维角度杜绝SSTI

分析了这么多攻击案例，我们最后从防御者角度，总结一下如何避免SSTI漏洞。原则就一条：永远不要信任用户输入，永远不要将用户输入与模板语法拼接。

1. 严格使用“数据”与“代码”分离的模板模式这是最根本的。所有模板变量都必须来自服务端控制器明确传递的、经过处理的数据对象。在渲染模板时，只进行值的替换，不进行逻辑结构的拼接。

• 正确示例(Python Flask/Jinja2):

  return render_template(‘user.html’， username=filtered_username)

  在模板user.html中使用{{ username }}。
• 错误示例:

  template = f“<h1>Hello， {user_input}</h1>” return render_template_string(template) # 绝对禁止！

2. 选择合适的模板引擎并安全配置

• 及时更新：使用官方维护的最新稳定版本，及时修复已知安全漏洞。
• 启用沙盒/安全模式：
  • Jinja2: 使用SandboxedEnvironment，并仔细审查允许的函数和过滤器。
  • Freemarker: 设置TemplateClassResolver为SAFER_RESOLVER，禁用?new()和?api。
  • Thymeleaf: 避免使用预处理表达式__${...}__处理用户输入，严格控制视图解析。
  • Twig: 升级到2.x/3.x，避免使用_self等危险特性。

3. 实施输入验证与输出编码

• 白名单验证：对于已知格式的输入（如用户名、邮箱、电话号码），使用严格的白名单正则表达式进行验证。
• 上下文相关的输出编码：即使变量进入了模板，在最终输出到HTML时，也要确保进行了正确的编码（如HTML实体编码），防止SSTI与XSS形成组合拳。大多数现代模板引擎默认会自动转义HTML，请不要关闭此功能。

4. 代码审计与安全测试

• 重点审计：在代码审查中，重点关注所有动态生成模板内容的地方，如render_template_string， 字符串拼接+或f-string后传入渲染函数，以及动态的include、extends语句。
• 自动化扫描：在CI/CD流水线中集成SAST（静态应用安全测试）工具，可以辅助发现潜在的SSTI代码模式。
• 渗透测试：定期进行黑盒和白盒渗透测试，使用本文提到的探测Payload对用户输入点进行测试。

5. 最小权限原则运行模板引擎的应用程序进程，应使用权限最低的系统用户，避免使用root或管理员权限。这样即使被攻破，攻击者能造成的破坏也有限。

SSTI漏洞的挖掘和利用是一个深度依赖对模板引擎内部机制理解的过程。希望通过这五个真实案例的拆解，能帮你建立起一套从快速探测、引擎识别、到利用链构造的实战思维。记住，没有放之四海而皆准的Payload，唯有对原理的深刻理解，才是应对千变万化实战场景的不二法门。在安全的世界里，好奇心和学习能力，永远是你最强大的武器。