flawopen.com/SSTI/Explicado
O que é injeção de template no servidor?
A injeção de template no servidor ocorre quando uma entrada não confiável é interpretada como código-fonte do template, em vez de ser passada como dado. O impacto depende do mecanismo, da configuração e dos recursos acessíveis: pode variar de avaliação de expressões a execução de código no servidor. Nem todo caso leva a execução de código.
# Python / Jinja2 template = f"Hello {name}!" return render_template_string(template) # Input: {{ 7*7 }} renders as "49" # This confirms expression evaluation; # impact still depends on engine access. // Java / Freemarker String tpl = "Welcome " + userName; new Template("t", tpl, cfg) .process(model, out);
# The template is a fixed string the # developer wrote. The user value is # passed in as a variable. return render_template( "greeting.html", name=name ) # Or with a literal template string: return render_template_string( "Hello {{ name }}!", name=name ) // Java equivalent: template from file, // user value in the model map.
A distinção essencial
Todo mecanismo de template recebe dois tipos de entrada: o template e os dados de contexto. O template é um programa; os dados são os valores lidos por esse programa. SSTI acontece quando a entrada do usuário passa da categoria de dados para a de código-fonte do template.
É o mesmo erro estrutural da injeção de SQL, em que dados são concatenados ao texto da consulta, e do Log4Shell, em que dados alcançavam um interpretador de expressões por meio de uma mensagem de log. A correção segue o mesmo princípio: mantenha o programa fixo e passe valores não confiáveis por um canal de parâmetros.
Quando o impacto pode incluir execução de código
Quando um mecanismo expõe objetos ou métodos poderosos ao template, um invasor pode alcançar recursos sensíveis da aplicação. A possibilidade de execução de código depende do mecanismo, da versão, da configuração, do sandbox e dos dados expostos. Outros impactos incluem divulgação de dados e esgotamento de recursos. Trate o código-fonte de templates controlado pelo usuário como lógica ativa; não confie apenas no sandbox sem limitar objetos acessíveis e recursos de renderização.
Como detectar
{{7*7}}
${7*7}
<%= 7*7 %>
#{7*7}
Se a resposta contiver 49 em vez do texto literal, a entrada está sendo avaliada como sintaxe de template. Essas pequenas expressões aritméticas ajudam a identificar a avaliação em um ambiente de teste autorizado; a sintaxe varia entre mecanismos e, sozinha, não identifica o mecanismo com segurança.
Perguntas frequentes
Não. A injeção de template no cliente é executada no navegador da vítima e pode ser uma variante de XSS. SSTI é avaliada no servidor, dentro do processo da aplicação. O impacto depende do mecanismo e dos recursos expostos; algumas configurações permitem execução de código no servidor, mas isso não é consequência automática de toda SSTI.
Não. O autoescape sanitiza os valores renderizados; não impede que um valor seja analisado como sintaxe de template. Ele ajuda contra XSS na saída, não contra injeção no código-fonte do template.
Trate código-fonte fornecido pelo usuário como lógica executável e, por padrão, não o processe no contexto principal da aplicação. Se o recurso for necessário, use um mecanismo para templates restritos, exponha apenas dados inertes mínimos e aplique limites de CPU, memória, tamanho da saída e tempo. Um sandbox reduz o acesso, mas não é uma fronteira de segurança completa.
Referências
- CWE-1336 — Improper Neutralization of Special Elements Used in a Template Engine
- PortSwigger Web Security Academy — server-side template injection
- OWASP Testing Guide — testing for SSTI
- Is Jinja2's render_template_string() safe?
- Are Freemarker and Velocity templates safe with user input?
- Jinja documentation — Sandbox security considerations