如果我们的模版 test.vm 内容改如下时，那么 Velocity 将会执行 id 命令，并显示执行结果。

1
2
3
4
5
6
7
8
9
10

#set($x='')
#set($rt=$x.class.forName('java.lang.Runtime'))
#set($chr=$x.class.forName('java.lang.Character'))
#set($str=$x.class.forName('java.lang.String'))
#set($ex=$rt.getRuntime().exec('id'))
$ex.waitFor()
#set($out=$ex.getInputStream())
#foreach($i in [1..$out.available()])
    $str.valueOf($chr.toChars($out.read()))
#end

所以某个应用以 Velocity 作为模版渲染引擎，如果要渲染的模版内容用户可控的话，那就可以构造恶意模版来执行任意命令。本次Solr漏洞就是这种情况！

Solr在查询数据结束后，会通过 wt 参数的值来确定数据返回的格式，可以是 XML 、 JSON 、 CSV , Velocity模版渲染 等等。本次漏洞正是出现在查询结果用 Velocity模版渲染 。

从代码层面看，Solr会根据 wt 值，创建对应的类型的 QueryResponseWriter 来将查询数据处理成对应的格式，最后将数据 write() 到客户端。

由于我们这里设置的是 wt=velocity ,故 QueryResponseWriter 类型为 VelocityResponseWriter 。我们在 solr-velocity-8.2.0.jar 包的 VelocityResponseWriter.write() 方法打断点，作为漏洞分析的开始位置。

首先Solr会先创建一个Velocity模版引擎对象 engine ，跟进 createEngine() 方法。

发现当设置 "params.resource.loader.enabled": "true" 时，属性 this.paramsResourceLoaderEnabled 的值为 true ，程序将创建一个参数资源加载器对象，也就是模版内容将从前端传来的参数中加载（PS:知识储备的案例是从文件加载）。

继续跟进 SolrParamResourceLoader 类的构造方法，解析了前端传来的所有参数，并对 v.template. 开头的参数进行处理。我们请求的参数为 ...&v.template=custom&v.template.custom=恶意模版内容 ,所以 put 进入 templates 模版 map 的 key 是 custom.vm , value 就是我们指定的 恶意模版内容 。

之后在获取模版对象时,将前端传入的参数 v.template 值拼接 .vm ，也就 custom.vm ，作为要渲染的模版名。而 custom.vm 正是我们上一步传入的恶意模版。

然后我们重新回到 write() 方法，不管 wrapResponse 变量为 true 还是 false ，恶意模版都被传入 merge() 进行合并渲染，至此漏洞触发。