这段常态化时期，每天都整理和学习历年能打穿小朋友的漏洞，本文转载自

https://forum.butian.net/share/2491     这个师傅写的真得很细

这篇文章是关于某系统模板注入漏洞的分析，具体内容如下：

1. 漏洞概述：

   • 漏洞是由于程序在处理传入的SQL语句时使用了Freemarker模板渲染，导致模板注入问题。

2. SQL注入分析：

   • 文章首先介绍了SQL注入问题，通过分析公开的payload和接口逻辑，发现程序对传入的SQL语句进行了黑名单过滤，但存在漏掉的exp()函数关键字，可以利用它进行报错注入。

3. 模板注入分析：

   • 进一步分析发现，程序在处理SQL语句时，使用了Freemarker模板，这导致了模板注入漏洞。
   • 通过分析代码，发现传入的sql参数值被当作模板处理，Freemarker模板中的<#assign>语句可以创建一个继承自TemplateModel类的变量。
   • 利用Freemarker的Execute类，可以执行系统命令，从而实现模板注入。

4. 漏洞利用过程：

   • 文章通过反编译和调试，详细分析了漏洞的成因和利用过程。
   • 描述了如何通过构造特定的payload来绕过SQL关键字过滤，以及如何利用Freemarker模板引擎执行系统命令。

5. 修复措施：

   • 官方在最新版本中使用了setNewBuiltinClassResolver(TemplateClassResolver.SAFER_RESOLVER)来禁用Freemarker模板注入中常用的三个类的解析，从而修复了该漏洞。

某系统前阵子公开了模板注入的漏洞，漏洞点在于程序对传入的sql语句处理时使用了freemarker模板渲染导致的问题。代码对该接口传参的处理先经过sql关键字的过滤，且分析中发现了一处可用的sql注入的payload,故先从sql注入开始介绍。

某系统前阵子公开了模板注入的漏洞，漏洞点在于程序对传入的sql语句处理时使用了freemarker模板渲染导致的问题。代码对该接口传参的处理先经过sql关键字的过滤，且分析中发现了一处可用的sql注入的payload,故先从sql注入开始介绍。

1.sql注入

下载源码后导入idea运行（使用mysql数据库）

先来看一眼公开的模板注入的payload，传参的字段和接口名称让人不免怀疑此处是否还有sql注入，于是看看接口逻辑

POST /jeecg-boot/jmreport/queryFieldBySql HTTP/1.1
Host: localhost:8080
Content-Type: application/json
Content-Length: 100

{"sql":"select '<#assign value="freemarker.template.utility.Execute"?new()>${value("whoami")}'"}

反编译漏洞依赖包后导入idea，全局搜索queryFieldBySql定位漏洞代码如下

打上断点，bp发送payload({"sql":"select 1 from demo"})，开始调试

进入i.a()方法

定义了黑名单的sql关键字

String[] var1 = " exec |peformance_schema|information_schema|extractvalue|updatexml|geohash|gtid_subset|gtid_subtract| insert | alter | delete | grant | update | drop | chr | mid | master | truncate | char | declare |user()|".split("|");

先调用b()方法匹配是否存在内联注释，在把传入的值全部转化为小写，在调用c（）方法判断是否有sleep()函数的关键字，接着挨个和黑名单数组中的关键字逐一匹配，匹配到了则拦截并抛出异常

接着经过一大段基础配置的调用来到此方法，步入

又初始化了一些基本配置，由于此处paramArray传入为空，来到如下函数

跟进

步入发现函数去除了传入参数末尾的分号（如果有的话），又进行了一遍i.a()方法的拦截sql关键字。后由于传入var1为空，直接进入

var0 = a(var2,var0)

正则匹配 ”${“ 和 “}“ 之间的字符串存入hashmap中，我们的注入的payload此次明显是匹配不到的，接着进到如下方法

freemarker模板的方法，此处分析sql注入，暂时跳出

跟进

又是一些处理sql拦截的代码，匹配诸如 where/and/or/=等字符进行相应的过滤，接着回到此处向下执行

最终调用jeeecg的minidao层服务执行sql语句

分析下来发现程序对sql的传参基本只做了黑名单过滤，但是其中漏掉了exp()函数关键字的匹配，使用exp()函数即可实现报错注入

2.模板注入

接着分析上面提到的调用freemarker函数的地方，我们的payload “sql”参数的值作为var1 传入

跟进函数调用，默认var0为空，进行一些初始化后来到如下函数

创建一个名为"template"的模板对象，使用模板对象对var1和var3进行处理，故跟进process()方法

继续跟进process()

跟进this.visit(this.getTemplate().getRootTreeNode())

accept()方法匹配到ftl表达式，将插值和插值的传参赋值给templateElementsToVisit

而后第一次调用this.visit(el)；（el此时为freemaker表达式中的插值，即“<#assign value="freemarker.template.utility.Execute"?new()>”），顺带提一下，在freemarker模板中，<#assign value="freemarker.template.utility.Execute"?new()>语句可以创建一个继承自 freemarker.template.TemplateModel 类的变量

继续跟进一系列方法到此处

经过freemaker处理ftl语句后

targetMethod就是构造的ftl语句中传入的需要使用的命令执行的类freemarker.template.utility.Execute

即freemarker.template.utility.Execute.exec(argumentStrings),当然此处argumentStrings的值为空，还没有真正命令执行

接着进入visit()的第二次调用，传入ftl语句中插值的赋值，即“${value("calc")}”

接着进到关键调用exec(),将获取到的ftl语句中value的值传入

跟进exec()方法使用系统命令执行我们ftl语句中对value的赋值

3.修复

目前官方在最新版本使用了

setNewBuiltinClassResolver(TemplateClassResolver.SAFER_RESOLVER)

禁用了freemarker模板注入中常用三个类的解析

原文始发于微信公众号（黑伞安全）：常态期讨老口子3: JeecgBoot 模板注入分析