vladko312/research_successful_errorsWhitepaper introducing Error-Based and Boolean Error-Based Blind techniques for SSTI and Code Injection, with universal payloads for six programming languages and integration into SSTImap.
[!NOTE] 这是基于我在发布 SSTImap 1.3.1 版本之前所展示的结果撰写的白皮书第二版。 进一步的改进将在稍后的时间以该研究 1.2 版本的形式适应此格式。
某些类别的漏洞乍一看可能非常著名且相当明显。似乎所有可能的技术都已为人所知，因此只有针对不常见情况的 payload 才可能被发现。 服务器端模板注入（SSTI）和代码注入通常被认为是这些众所周知的类别。
有时，对于这些漏洞会遇到新的、名称自解释的技术。许多研究人员可能也认为这些技术是众所周知的，甚至记得使用过它们， 但实际上，该技术可能仅作为一个普遍理解的名称存在，而没有相关研究、描述或通用 payload。 它可能在某些非常特定 case 的 payload 中被提及过几次， 但不会进行测试，并且该技术的真正潜力可能多年来一直未被发现。
本研究引入了两种针对代码注入和 SSTI 的技术：基于错误（Error-Based） 和 布尔错误型盲注（Boolean Error-Based Blind）。 我将为六种编程语言（Python、PHP、Java、Ruby、NodeJS 和 Elixir）提供代码注入和 SSTI 的 payload。 此外，我还将提供通用检测 payload，能够快速检测甚至盲注。
我将提供从发现早期线索到最终结论的完整研究时间线。 我还会探讨为本研究未提及的编程语言和模板创建新 payload 的过程。
在本研究中，我将展示新技术实际应用的示例，并分享进一步研究的潜在领域。 所有提供的 payload 均可用于检测和利用真实应用程序中的漏洞。 此外，所有提供的 payload 都已添加到开源工具 SSTImap 中，这使得将本研究结果应用于实际目标变得更加容易。
当动态网站使用模板引擎进行服务器端渲染，且不可信的用户输入在模板被模板引擎处理之前插入到模板中时，就会出现服务器端模板注入漏洞。 恶意行为者可以插入有效的模板语法，该语法将在页面渲染期间被模板引擎处理。 许多模板引擎提供某种形式的代码执行功能，这通常会导致目标服务器上的远程代码执行（RCE）。 本研究重点关注在利用时提供此类功能的模板引擎。
SSTI 漏洞自 2015 年起就已被知晓，在此期间，发现了许多用于信息泄露、过滤器绕过和沙箱逃逸的 payload。 尽管如此，大多数 payload 要么直接渲染结果在页面上，要么关注代码执行本身的事实，忽略该代码产生的结果。
另一种众所周知的 SSTI 技术是基于时间的盲注，它涉及向执行的 shell 命令添加延迟。 该技术允许确定注入代码执行的成功与否，但需要猜测 OS 命令执行的 payload， 这使得在未知模板引擎中检测盲 SSTI 更加困难。
SSTI 漏洞类别以及这两种已知的利用技术均由 James Kettle 于 2015 年发现。 这些技术在他的研究 “服务器端模板注入：面向现代 Web 应用的 RCE” [^1] 中有非常详细的描述。 在接下来的十年中，没有记录新的利用技术。 2023 年才发现一种检测技术，该技术使用多语言 payload 同时测试多个模板引擎。 该技术由 Maximilian Hildebrand 发现，并在他的研究 “改进大规模模板注入扫描中模板引擎的检测和识别” [^2] 中进行了描述。 该技术专注于使用最少的请求数量确定模板引擎，但仅适用于简单的注入上下文。
大多数基于解释型编程语言（如 PHP、NodeJS 和 Python）的模板引擎直接允许评估相应编程语言的表达式。 这种能力使我们能够通过将 payload 包装在正确的模板标签格式中，使用更广泛的代码注入漏洞类别的 payload。
代码注入也可能在没有 SSTI 的情况下发生，当不可信用户输入可以到达 eval() 或类似危险函数时。
通常认为代码注入的利用只是在相应语言中进行编程，
因此技术和 payload 仅针对特定的漏洞示例进行记录，这需要针对目标应用程序定制代码。
缺乏更通用的代码注入和 SSTI 检测技术导致黑盒扫描盲代码和模板注入效率低下。
在本研究中，将提供两种新技术用于代码注入和 SSTI，以及六种编程语言的 payload 和通用检测 payload。 所提供的技术将扩展盲 SSTI 利用的能力，以及允许在不猜测注入代码编程语言的情况下进行盲代码注入和 SSTI 扫描。
本研究提供的 payload 旨在用于实际渗透测试真实 Web 应用程序。 所有提供的 payload 也已整合到开源工具 SSTImap [^3] 的模块中，用于检测 SSTI 和代码注入。 对两种新技术以及相应 payload 的支持已在版本 1.3.0 中添加。 本研究中提供的用于新技术实际应用的较少通用、更具体的 payload 已合并到额外的 SSTImap 模块中，这些模块可以在“extra”模块的专用存储库中找到。[^4]
在为 SSTImap 模块开发 payload 的过程中，我遇到了一些限制和发现，这些成为导致本研究中技术的线索。 我遇到了不同的 SSTI 和代码注入场景，在这些场景中，无法使用现有技术从注入代码中获取输出。 在遇到此类限制时，我测试了各种获得输出的想法，这最终导致发现了本研究中记录的两种新技术。
第一个提示潜在限制的线索是在我为 Dust.JS 模板引擎更新 payload 时遇到的。 该引擎被认为是过时的，似乎已被遗弃，而代码执行仅在 2015 年旧版本的 dustjs-helpers 中才可能实现。 该引擎的 SSTImap 模块继承自 Tplmap [^5] 代码库，改进它是一个低优先级任务，但该模块在简单的无逻辑模板引擎情况下会导致大量误报。
为了解决这个问题，我改进了 payload，但模板引擎及其 payload 引起了我的注意。
代码注入可以在 if 块的条件内进行，该条件直接传递给 eval()。[^6]
结果不会显示在页面上，因此即使对于反射型 SSTI，也认为 RCE 总是盲的。
在那个时候，研究一个过时的模板引擎来创建新 payload 在我的优先级列表中非常低，所以我决定不研究任何潜在获取输出的方法。
我在为 Twig 模板引擎的新版本开发 payload 时遇到了第二个线索。 早期版本的 payload 已修复，所以我决定创建一个包含更新 payload 的新模块。 在寻找更现代的 Twig 利用方法时，我发现了 CVE-2022-23614，该漏洞允许使用现代版本的常见 payload 之一绕过沙箱。[^7]
对于新的 SSTImap 模块，我决定使用能够实现该沙箱绕过利用的 payload，因为它也适用于几乎所有可通过现代 payload 利用的 Twig 版本。
沙箱绕过可以通过将包含 PHP 函数名字符串作为参数传递给 |sort 过滤器来实现，
从而导致模板使用两个数组元素作为参数调用该函数。
与 Dust.JS 的情况类似，函数的输出在内部用作条件（这次是用于排序数组），因此它不会传回模板上下文。
这种限制不会阻碍利用，因为 PHP 中的 system() 函数直接将 OS 命令执行的结果输出到 Web 页面上，这允许我们绕过模板引擎获取输出。
我很好奇是否有可能在模板引擎内部获取输出，以便作为某些绕过或新 SSTI 利用技术的潜在应用。 但创建新的 Twig 模块并不需要这样做，所以我决定不投入任何时间开发用于在模板内获取注入结果的新 payload。
Node.JS 模块 JSONPath Plus 版本 10.3.0 之前的 CVE-2025-1302 漏洞允许通过访问 jsonpath 扩展条件语法中的函数构造函数来注入任意 JavaScript 代码。[^8] 我决定为 CVE-2025-1302 创建一个新的额外 SSTImap 模块，用于在服务器端 jsonpath 注入的情况下的自动检测和利用。
与 Dust.JS 类似，代码注入只能在条件内进行，因此没有直接的方法获取输出并将其渲染到页面上。 尽管如此，我决定研究提取输出的可能性，这最终导致了我发现第三个线索，该线索暗示了可能最终导致本研究发现的潜力。
JSONPath Plus 模块用于访问 JSON 对象内的数据。
在许多解释型编程语言（如 JavaScript）中，这些对象通常隐式地作为指针运作，以限制资源消耗。
同时，JSONPath Plus 模块允许使用 @root 语法访问正在被搜索的对象。
我发现了一种方法，可以将该对象传递给条件内的注入代码，从而允许将输出保存在对象属性中，然后使用注入的 jsonpath 语法访问它们。
这种方法远非获取输出的通用方式，因为它严重限制了反射型代码注入场景中可用的注入上下文。 我研究了其他潜在的提取输出的方法，例如原型污染，但我无法发现更通用的技术。 尽管如此，这次我能够从条件中提取输出。
与之前所有在 payload 开发期间遇到限制的情况不同，导致本研究的最后一个线索是在探索真实世界应用程序时发现的。 我当时正在测试一个用于 Discord 的无代码机器人构建器，该构建器允许用户自定义消息模板。 用于该目的的模板引擎本身并不评估任何代码，但它有一个专门用于评估数学表达式的标签。
通过检查该标签返回的不同错误消息，我确定这些表达式是使用名为 expr-eval 的 Node.JS 模块评估的。
该模块通过访问允许任意属性访问的对象构造函数来实现 RCE（CVE-2025-13204）。
我修改了 payload 以避免破坏模板标签的语法，但我只得到了 NaN，而不是代码执行结果。
看起来 expr-eval 的结果被模板引擎转换为数字，这阻止了代码执行输出的反射。 然而，只有在评估成功的情况下，结果才会被转换为数字。 在发生错误的情况下，模板会用错误的完整文本替换标签，有时该文本包含我代码的一部分。
我决定研究通过那些错误消息部分提取代码执行结果的可能性。 存在一种技术允许通过特定触发的错误消息提取 SQL 查询。[^9] 我假设对于代码注入和 SSTI 也存在类似的技术。
我尝试搜索 “基于错误的 SSTI” 以及此类 SSTI 和代码注入技术的其他潜在名称， 然而我只能找到来自 2023 年单一研究论文的基于错误的多语言 payload，以及一种通过查看错误消息来确定模板引擎的技术。 唯一一个甚至与我寻找的相似的结果是研究者 Nicolas Verdier 创建的针对 Freemarker 模板的单个 payload。[^10]
该 payload 允许在盲注入情况下通过条件触发错误来确定代码执行的成功与否。 SQL 注入中存在类似的技术，这证实了我的假设，即类似的技术可能适用于代码注入和 SSTI。
我意识到我正在寻找的技术此前并未被记录，因此我决定进行这项研究，以开发所需的 payload。 此外，我决定将该技术添加到我的开源工具 SSTImap 中。
