Como a injeção de modelo do lado do servidor funciona nos bastidores
Uma injeção de modelo do lado do servidor ocorre quando a entrada do usuário é incorporada diretamente em um mecanismo de criação de modelos e avaliada sem a devida higienização ou isolamento. Isso cria uma vulnerabilidade SSTI que permite que um invasor injete cargas SSTI especialmente criadas (por exemplo, {{7*7}} em Jinja2), que o mecanismo avaliará, permitindo tudo, desde a divulgação de dados até a execução arbitrária de código no contexto do servidor. Como diferentes mecanismos de template expõem diferentes objetos e APIs, os payloads SSTI variam de acordo com a plataforma, mas compartilham o mesmo perigo: permitem que entradas não confiáveis escapem do fluxo de renderização esperado e sejam executadas no tempo de execução do aplicativo, muitas vezes levando à execução remota completa de código ou à movimentação lateral se não forem controlados.
Exemplo de vulnerabilidade mínima em Jinja2
from flask import request, render_template_string
@app.route("/hello")
def hello():
name = request.args.get("name", "world")
# ❌ Vulnerable: directly rendering user input
return render_template_string("Hello " + name)
Se um usuário enviar ?nome={{7*7}}, o aplicativo irá avaliá-lo, retornando Olá 49. Essa é uma vulnerabilidade típica do SSTI.
Exemplo de vulnerabilidade mínima em Twig
// ❌ Vulnerable Twig usage
$template = $twig->createTemplate("Welcome " . $_GET['user']);
echo $template->render([]);
Um invasor pode injetar cargas SSTI como {{7*7}} para provar a execução do código. O perigo: uma simples injeção pode evoluir para leitura de arquivos, execução de comandos do sistema operacional ou aprofundamento na infraestrutura.
Explorações do mundo real: cargas úteis SSTI que acionam execução remota de código
Uma vez que existe uma vulnerabilidade SSTI, os invasores tentam passar da matemática de prova de conceito para a matemática completa RCE. Diferentes mecanismos de modelo lidam com cargas úteis de forma diferente.
Cargas úteis do Jinja2
- {{7*7}} → execução aritmética
- {{config.items()}} → vaza configurações do servidor.
- {{ ”.__class__.__mro__[2].__subclasses__() }} → caminho para RCE
Cargas úteis de velocidade
- #definir($x=”7″)${x} → bypass de injeção
- #set($a=$class.inspect(“java.lang.Runtime”)) → acesso direto ao tempo de execução
Cargas úteis Twig
- {{7*7}} → aritmética
- {{app.request.server.all}} → variáveis de ambiente
- {{_self.env.registerUndefinedFilterCallback(‘system’)}} → execução de código
Essas cargas úteis SSTI demonstram como a mesma vulnerabilidade em diferentes mecanismos leva a diferentes explorar caminhos, mas elas são sempre perigosas.
Onde a injeção de modelo do lado do servidor se esconde CI/CD-Aplicações orientadas
A injeção de modelo do lado do servidor não é apenas um risco de aplicativo da web; ela aparece em moderno CI/CD pipelines demasiado. Os esconderijos típicos incluem:
- Gráficos de leme no Kubernetes, onde os valores do modelo são renderizados dinamicamente
- Modelos de e-mail que concatenam entradas controladas pelo usuário
- Dashboards onde strings de consulta ou dados de configuração são injetados em modelos
- Scripts DevOps que geram HTML/Markdown usando mecanismos de modelagem.
Exemplo:
# ❌ Insecure Helm values with user input
configMap:
appMessage: "{{ .Values.message }}"
If.Valores.mensagem vem de uma entrada não confiável, ele introduz uma injeção de modelo do lado do servidor em sua implantação pipeline si.
Prevenção de SSTI com padrões de modelo mais seguros e análise estática
Mitigar vulnerabilidades de SSTI requer melhores padrões de codificação e detecção precoce.
Padrões seguros
- ❌ Não use string_modelo_de_renderização ou equivalente
- ✅ Use arquivos de modelo predefinidos e passe variáveis higienizadas
- ✅ Mecanismos de modelo de sandbox quando disponíveis
- ✅ Validar e escapar da entrada do usuário antes da renderização
Manuseio de cookies inseguro vs. seguro (risco de entrada relacionado)
# ❌ Insecure: session cookie without flags
response.set_cookie("session", token)
# ✅ Secure: session cookie hardened
response.set_cookie("session", token, httponly=True, secure=True, samesite="Strict")
Mini Checklist para Desenvolvedores
- Nunca renderize a entrada bruta do usuário diretamente
- Use modelos em sandbox quando suportados
- Sanitize e valide todas as variáveis do modelo
- Evite avaliadores de modelos personalizados
- Código de digitalização para string_modelo_de_renderização ou padrões de concatenação de strings
Análise estática e os linters podem sinalizar construções arriscadas antes que elas cheguem à produção.
Incorporando verificações SSTI no DevSecOps Pipelines
Detectar a injeção de modelo do lado do servidor precocemente é mais barato e seguro do que corrigi-la posteriormente. As equipes de DevSecOps devem incorporar verificações em pipelines:
- Commit hooks: rejeitar commits com funções perigosas (string_modelo_de_renderização)
- Analisadores estáticos: verificar o risco de injeção de modelo do lado do servidor no código de modelo
- Validação de dependência: sinalizar mecanismos de modelo desatualizados com vulnerabilidades SSTI conhecidas
- Pipeline portões: o bloco é mesclado até que as verificações SSTI sejam aprovadas
Ao tornar a detecção de carga útil SSTI parte de CI/CD, você impede que código explorável seja enviado.
Não deixe que a injeção de modelo do lado do servidor entre em sua pilha
Uma única injeção de modelo do lado do servidor pode evoluir de truques matemáticos ({{7*7}}) para execução remota completa de código. Vulnerabilidades SSTI aparecem não apenas em aplicativos da web, mas também em CI/CD pipelines, gráficos Helm e modelos de e-mail.
Principais takeaways
- Nunca renderize a entrada bruta do usuário em modelos
- Validar e higienizar todas as variáveis dinâmicas
- Diferentes motores (Jinja2, Velocity, Twig) têm diferentes cargas SSTI, mas todos podem ser transformados em armas
- Use análise estática e portas de falha rápida em pipelines
- Audite os modelos em sua pilha regularmente
Ferramentas como Xygeni ajudar as equipes a detectar o uso inseguro de modelos, bloquear vulnerabilidades SSI e aplicar práticas seguras em pipelines e dependências. No DevSecOps, tratar as cargas úteis do SSTI como um risco de nível superior é essencial porque uma única injeção em seu pipeline ou aplicativo pode comprometer todo o seu ambiente.
