SSTI

SSTI ，服务器端模板注入（Server-Side Template Injection）。当前使用的一些框架，比如Python的Flask，PHP的ThinkPHP，JAVA的Spring等一般都采用成熟的的MVC的模式，用户的输入先进入Controller控制器，然后根据请求类型和请求的指令发送给对应Model业务模型进行业务逻辑判断，数据库存取，最后把结果返回给View视图层，经过模板渲染展示给用户。

漏洞成因就是服务端在接收用户的恶意输入后，未经任何处理就将其作为 Web 应用模板内容的一部分，模板引擎在进行目标编译渲染的过程中，执行了用户插入的可以破坏模板的语句，因而可能导致了敏感信息泄露、代码执行、GetShell 等问题。其影响范围主要取决于模版引擎的复杂性。

案例分享

某网站是一个多功能平台，用户可以创建自定义子域名、管理客户、生成发票、发送电子邮件，甚至设置销售产品。

它的功能远不止表面看起来那么简单，就像一个集成了迷你电子商务和 CRM 的小型平台。有趣的是，白帽小哥之前在该平台上曾发现过 XSS 漏洞。

在发现 XSS 后，白帽小哥决定深入挖掘，于是小哥花了很多时间进行了彻底侦察：枚举端点、检查常见配置错误等。

当导航到设置页面时，一切都变了，那里有一个选项可以创建自定义电子邮件模板，用于向客户发送个性化消息。

吸引白帽小哥注意的是预先填充的标签如 {{fname}} 和 {{email}} ，这些标签看起来很可疑，像极了“模板变量”。

为了检验，小哥创建了一个新的电子邮件模板，并将其中一个标签替换成了一个简单的数学表达式： {{7*7}} 。

保存后，转到“客户”部分，选择新的模板，并发送了一封测试邮件。

在邮件预览中出现了：“49”！经典的服务器端模板注入（SSTI）漏洞！

从注入到命令执行

SSTI 很强大，但能否能够将其升级为远程代码执行呢？利用 Payloads 字典（见文末链接） 是测试各种模板引擎的不错选择。

经过一番尝试和错误，白帽小哥发现了一个可以正常工作的Payload，它显示了网站底层使用了 PHP：

{php}echo id;{/php}

为了能够读取敏感文件，小哥制作了以下的Payload：

{{['cat\x20/etc/passwd']|filter('system')}}

成功读取passwd文件，小哥也有了 RCE 的完整PoC，为了避免任何意外发生，小哥严格遵循白帽规则，停止了更为深入的利用。

在经历了漫长的四周等待后，白帽小哥最终获得1000美元的赏金奖励。

心得体会

• 不要急于探索所有功能，尤其是涉及用户输入的模板等功能。

• SSTI 可能隐藏在明处，尤其是在可定制区域

• 像 payloadbox 这样的仓库能够节省大量手动制作的时间

• 利用 AI 可以处理无聊的部分（撰写漏洞报告），让你更专注于寻找漏洞

SSTI Payloads 字典：https://github.com/payloadbox/ssti-payloads

原文：https://medium.com/meetcyber/how-a-simple-ssti-turned-into-1-000-and-rce-2ee5b1d20474