形成原理SSTI模板

哎哟喂，SSTI模板注入到底是个啥？一文带你摸透它的“小心思”

前言：那天，我被一个“花括号”整懵了

兄弟们,姐妹们，咱就是说，搞网络安全这行当，有时候真不是被什么高深莫测的0day漏洞给难住的，我至今还记得，刚入行那会儿，第一次在某个网站的URL参数里看到 {{7*7}} 这玩意儿，页面居然“乖巧”地回显了 49，我当时那个心情啊，就跟见了鬼一样——这尼玛不是直接把计算器怼人脸上了吗？

哈哈,开个玩笑，但说真的，SSTI（Server-Side Template Injection，服务端模板注入） 这玩意儿，确实挺“阴险”的，它不像SQL注入那么“直来直去”，也不像XSS那样“满大街都是”，它更像一个躲在暗处的“小机灵鬼”，专门欺负那些把用户输入不当回事的开发者，咱们就来唠唠，这个烦人的SSTI模板注入，它的“小心思”到底是咋形成的，原理是啥。

先搞懂它住在哪儿：模板引擎的“家”

你想啊,现在做网站，谁还傻乎乎地手写一堆HTML字符串拼数据？太low了对不对？咱们讲究的是“前后端分离”，“模板渲染”，啥意思呢？就是后端写个模板，Hello, {{ username }}!，然后往里面塞数据，这里的就是模板的“家”，是给动态数据留的位置。

可问题来了,模板引擎（比如Jinja2、Twig、Freemarker之类的）为了追求“灵活”，不光允许你放变量，还允许你在里面写一些“小逻辑”，甚至是调用一些功能函数，这本是件好事，方便开发者嘛，但如果开发哥哥姐姐们把用户输入的参数，直接拼进了这个“家”里，连个“门禁系统”都不装，那坏人就乐了：你不让我进，我偏要进去转转，甚至把你家“家具”都搬走。

形成原理大揭秘：一场“信任”的错付

来来来,重点来了，SSTI的形成原理，说白了就是一句话：服务端对用户输入的内容，错误地当成了“模板代码”来执行，嘿，你说气不气人？就好比你请了个管家（模板引擎），管家特别听客人的话（用户输入），客人说“把保险柜打开”，管家还真就屁颠屁颠去把门给你趟开了，这能怪谁？只能怪管家（开发者）太“实诚”，没分辨出哪些是真命令，哪些是瞎起哄。

完整链条大概是这样的：

识别输入点：比如URL参数 ?name=xxx，或者搜索框，甚至某个隐藏字段。
直接拼接：后端代码写成 render_template_string("Hello, " + name) 或者 Template("Hello, {{" + name + "}}")，哎，这是最原始的“裸奔”写法。
触发渲染：当参数值里包含 {{ 恶意代码 }} 时，模板引擎就会乖乖地把里面的表达式去执行，如果只是 {{7*7}} 算个乘法，那还算温柔，要命的是，攻击者会尝试 {{ config.__class__.__init__.__globals__['os'].popen('whoami').read() }} 这种链式调用，直接命令执行！
拿到权限：一旦能执行系统命令，那这台服务器不就等于“拱手让人”了吗？瞬间能读取数据库、反弹Shell，为所欲为。

为啥它这么难防？语气里带着“气”

说实话,我每次看代码审计报告看到这种漏洞，真的是又气又好笑，气的是开发者粗心大意，笑的是这漏洞利用起来“花样百出”，像在解一道涉及魔法方法的“数学题”。

你发现没有,SSTI之所以能成，核心在于“代码”与“数据”的边界被击穿了，我们总说“输入过滤”，但很多模板引擎的语法极其复杂，你根本过滤不完，今天你过滤了 class，明天它用 __getattribute__ 绕过了；你过滤了，它用 .get() 替代了，这就是一场“猫鼠游戏”，而SSTI的根子，就在于错误地把冯·诺依曼体系中的“指令”当成了“数据”来解析。

怎么收拾它？给你支两招

哎呀,说了这么多，咱不能光说不练呀，想防住这个“小妖精”，其实也不难，核心就一个字：“别信”。

第一招（最笨但最有效）：能不拼接就不拼接，能用 render_template('xxx.html', name=name) 分开传参，就千万别用 render_template_string 去拼，让模板引擎把用户输入只当作“值”，而不是“结构”。
第二招（上硬家伙）：“沙箱”隔离，很多高级框架（比如Flask的Jinja2）其实提供了沙箱环境，禁止访问危险对象，但你要搞清楚，沙箱不是保险箱，经常有“逃逸”漏洞（比如利用 __globals__ 找FIFO）。最稳妥的，还是对输入做严格的“白名单”校验，限制只能输入字母数字和少量符号。