一直对模板注入漏洞懵懵懂懂，直到最近在某gayhub上瞎逛碰到一个cms，再一番操作之后找到了一个前台getshell的漏洞。由于相关要求，这里隐去这个cms的全称，就分享漏洞发掘的思路。
我们全局搜索eval(可以发现有一个地方使用了eval，可以大胆猜测这个模板引擎是使用eval去实现。我们跟进ii_eval()函数。
可以见到函数的$strers可控，我们继续跟进ii_eval()看谁对他进行了调用。
全局搜索发现就只有一个地方对他进行了调用那就是ii_creplace()函数
我们跟进ii_creplace()可以看到，$strers可控但是他必须传入一个与({\$=(.[^\}]*)})这个正则匹配的字符串才能传入到iieval(),这里我们就可以得知要想执行代码必须符合类似下面的格式：
{$=phpinfo()}
那么我们继续跟进ii_creplace()函数看谁对他进行了调用，找了很多但是都对函数中的$进行了转义，但是在passport\address\common\incfiles\manage_config.inc.php中的xxx_cms_admin_manage_list()并未做任何过滤。我们继续跟进。
我们发现\passport\address\manage.php对passport\address\common\incfiles\manage_config.inc.php进行了包含并调用了xx_cms_admin_manage_action(),而它调用了xx_cms_admin_manage_list(),那么很明显我们只需将符合{\$=(.[^\}]*)}正则的payload传入即可导致getshell.
那么从哪传入呢，我们直接把xxx_cms_admin_manage_list()中的sql语句打印出来即可知道。
很明显是从用户地址处传入。那么我们先注册个用户添加用户地址传入我们payload
{$=phpinfo()}
再次刷新页面已经显示phpinfo，说明getshell成功。
其实纵观代码，这个cms的开发人员是有考虑过代码注入的问题，但是其对传入的内容并没有做全局过滤，而是每个点做过滤。这样难免会造成遗漏过滤的情况，当然这个cms的sql注入防护也是采取每个变量前套上一个转义函数，但是在后续的版本开发中难免也会有开发人员遗漏，这里不做深究了。
看完文章有没有想要自己尝试一下呢！登录合天网安实验室，get同款实验。Flask服务端模板注入漏洞：http://www.hetianlab.com/expc.do?ec=ECID87ed-2223-40e5-8083-f5c55d69af28 通过实验了解服务端模板注入漏洞的危害与利用。
