上周帮朋友紧急排查一个线上Flask项目，差点惊出一身冷汗：他写了个看似再正常不过的“个性化欢迎页”，代码只有短短几行：from flask import Flask, request, render_template_stringapp = Flask(__name__)@app.route("/hello")def hello(): name = request.args.get("name", "World") # 就是这行“拼接模板”的代码，埋下了高危漏洞 template = f"Hello {name}!" return render_template_string(template)
测试时一切正常，访问 /hello?name=张三 会返回 Hello 张三! ，直到安全扫描时发现：访问 /hello?name={{7*7}} ，页面居然返回了 Hello 49! —— 用户输入的表达式被服务器执行了。更可怕的还在后面：攻击者只需构造一个特殊的URL，就能直接读取服务器文件、执行系统命令，甚至接管整个服务器。这就是Web开发中最经典、也最容易被忽视的高危漏洞之一：Jinja2 服务器端模板注入（SSTI）。今天我们就把这个坑彻底讲透，从复现、原理到修复，帮你彻底避开这个能让公司“丢饭碗”的致命问题。
一、漏洞复现：从“简单表达式”到“接管服务器”只需5步
别觉得这是危言耸听，我们一步步来看，攻击者是如何利用这行简单代码的：访问 /hello?name={{7*7}} ，如果返回 Hello 49! ，说明Jinja2模板引擎执行了用户输入的表达式，漏洞确认存在。Jinja2中一切皆对象，攻击者可以通过Python的魔法方法，一步步摸到系统的核心：# 获取字符串的类/hello?name={{ ''.__class__ }}# 返回：Hello <class 'str'>!# 获取类的继承链（MRO），找到所有类的基类 object/hello?name={{ ''.__class__.__mro__ }}# 返回：Hello (<class 'str'>, <class 'object'>)!
拿到基类 object 后，攻击者可以查看Python运行时加载的所有类，从中寻找能执行命令的“危险类”：/hello?name={{ ''.__class__.__mro__[1].__subclasses__() }}
这会返回一个超长的类列表，里面藏着os._wrap_close、subprocess.Popen 这类能执行系统命令的类。
假设在子类列表中，os._wrap_close 的索引是132（不同Python版本索引不同，攻击者会自动遍历），那么：/hello?name={{ ''.__class__.__mro__[1].__subclasses__()[132].__init__.__globals__['os'].popen('whoami').read() }}
这行代码会直接执行系统命令 whoami ，返回当前服务器的运行用户。整个过程不超过5分钟，而这一切的起点，只是开发者图省事，用了 f-string 拼接用户输入和模板。
二、原理深挖：为什么一行简单代码会导致这么大的问题？
很多开发者会问：不就是拼接了个字符串吗？为什么会这么危险？Jinja2模板引擎的作用，是把「模板代码」和「用户数据」分开：- 模板代码（比如 Hello {{ name }}! ）是开发者写的，受信任；
- 用户数据（比如 name 参数）是外部输入的，不可信。
正常情况下，我们应该用 render_template("hello.html", name=name) ，把用户数据作为参数传给模板，模板引擎会自动把它当“纯文本”处理，不会执行。
但如果像开头那样，用 f-string 把用户输入直接拼进模板字符串里，就彻底混淆了边界：用户输入不再是“数据”，而是变成了“模板代码的一部分”，Jinja2会像执行开发者写的代码一样执行它。你可能会问：Jinja2没有安全机制吗？其实它默认有个沙箱，禁止直接调用 os 、 eval 这类危险模块。但Python的面向对象特性，给了攻击者绕过沙箱的路径：__class__ ：获取对象的类；
__mro__ ：获取类的继承链（Method Resolution Order），一直往上能摸到所有类的基类 object ；
__subclasses__() ：获取某个类的所有子类，Python运行时加载的所有类都在这里；
__init__.__globals__ ：获取类的初始化函数的全局变量，里面藏着 os 、 sys 等核心模块。
通过这一串魔法方法链，攻击者就能从一个普通的字符串，一步步摸到系统的核心模块，最终执行任意命令。
三、真实踩坑案例：比你想象的更普遍
别觉得这个漏洞离你很远，我见过太多真实的踩坑案例：某公司上线前，开发同事忘了把 app.debug = True 改成 False 。Flask的调试器会把错误页面渲染成Jinja2模板，里面包含 {{ request.environ }} 。攻击者故意触发500错误，然后在错误页里注入 {{ config.SECRET_KEY }} ，直接拿到了项目的密钥，进而伪造Session登录了管理员后台。某电商项目需要根据用户的会员等级，动态生成不同的促销文案。开发者为了省事，直接把用户的“会员等级描述”拼进了模板里，结果被攻击者利用，读取了数据库里的用户手机号和订单信息。
四、彻底修复：从“代码写法”到“生产配置”的5层防线
template = f"Hello {name}!"return render_template_string(template)
正确写法1：用独立的模板文件 创建 templates/hello.html ：from flask import render_templatereturn render_template("hello.html", name=name)
正确写法2：如果必须用 render_template_string ，把用户数据当参数传template = "Hello {{ name }}!"return render_template_string(template, name=name)
关键是：用户输入永远只能是“参数”，绝对不能成为“模板代码的一部分”。from jinja2.sandbox import SandboxedEnvironmentfrom flask import Flask, requestapp = Flask(__name__)# 强制使用沙箱环境app.jinja_env = SandboxedEnvironment()
对用户输入进行白名单校验，比如只允许字母、数字、下划线：import rename = request.args.get("name", "World")# 只允许安全字符if not re.match(r'^[a-zA-Z0-9_\u4e00-\u9fa5]+$', name): return "Invalid name", 400
app.debug = False# 同时，自定义错误页面，用静态HTML，不要用模板渲染@app.errorhandler(500)def internal_error(error): return "<h1>Server Error</h1>", 500
如果确实有“动态生成模板”的需求，可以用Jinja2的 parse() 方法把模板解析成抽象语法树（AST），检查里面有没有危险的节点：from jinja2 import Environmentenv = Environment()template_str = "Hello {{ name }}!"# 解析模板成ASTast = env.parse(template_str)# 检查AST中有没有危险的调用（比如 __class__、__subclasses__ 等）# 可以自己写规则，或者用现成的安全库
五、最后想说的话
- 对Python的魔法方法和Jinja2的原理不了解。
但它的后果又太严重了：轻则数据泄露，重则服务器被接管，公司业务停摆，甚至要承担法律责任。
希望今天这篇文章，能帮你彻底避开这个坑。如果你身边有写Python Web的朋友，不妨转发给他，多一个人知道，就少一个踩坑的可能。你在开发中还遇到过哪些“看似简单，后果严重”的坑？欢迎在评论区聊聊，我们一起避坑～
