As vulnerabilidades já vistas são o pão com manteiga do teste web. Agora subimos ao nível que separa o pentester web júnior do sênior — e que aparece em provas como a OSWE e nos relatórios de bug bounty mais bem pagos. Esta aula cobre três classes avançadas: XXE (injeção em XML), SSTI (injeção em templates) e desserialização insegura. Todas compartilham, no fundo, a mesma raiz das injeções que você já domina — entrada não confiável sendo processada perigosamente — mas em contextos mais sutis e poderosos. Pratique nos labs avançados do PortSwigger.

XXE: entidade externa lendo arquivo

Comece pela XXE (XML External Entity Injection). Muitas aplicações processam dados em formato XML (em APIs, uploads, configurações). O XML tem um recurso chamado "entidades", que permite definir referências reutilizáveis dentro do documento — e, crucialmente, "entidades externas", que podem referenciar recursos fora do documento, como arquivos locais ou URLs. Se o processador de XML da aplicação está configurado para resolver essas entidades externas (o padrão inseguro em muitos parsers antigos), um atacante que envia XML malicioso pode definir uma entidade externa que aponta para um arquivo do servidor (/etc/passwd) ou uma URL interna — fazendo a aplicação ler e retornar esse recurso. O impacto: leitura de arquivos sensíveis do servidor (como a LFI), e — poderosamente — SSRF (aula CSRF e SSRF: falsificando requisições no cliente e no servidor), porque a entidade externa pode apontar para recursos de rede internos, inclusive o metadata service da nuvem. A XXE é uma injeção que explora um recurso legítimo do XML (entidades externas) que quase nunca deveria estar habilitado.

SSTI: injeção no motor de template

Em seguida, o SSTI (Server-Side Template Injection). Aplicações usam "template engines" para gerar páginas dinâmicas — templates com espaços reservados que são preenchidos com dados (ex.: "Olá, {{nome}}"). O SSTI ocorre quando a aplicação insere entrada do usuário diretamente no template que será processado pelo motor, em vez de tratá-la como dado a ser inserido. Como os template engines frequentemente permitem expressões e lógica (para renderização dinâmica), injetar sintaxe de template pode levar à execução de código. Você detecta o SSTI enviando uma expressão que o template avaliaria — por exemplo, se você insere {{7*7}} num campo e a página exibe 49 (em vez do texto literal), o motor de template avaliou sua entrada: SSTI confirmado. A partir daí, dependendo do motor, escala-se de expressões matemáticas para leitura de dados e, frequentemente, execução de código no servidor. O SSTI é insidioso porque parece um XSS (injeção em página) mas executa no servidor, não no navegador — muito mais grave.

Desserialização insegura

A terceira, e talvez a mais complexa, é a desserialização insegura. Aplicações frequentemente "serializam" objetos (convertem estruturas de dados em memória num formato que pode ser armazenado ou transmitido — uma string, bytes) e depois os "desserializam" (reconstroem o objeto a partir desse formato). O problema surge quando a aplicação desserializa dados controlados pelo usuário sem validá-los. Em certas linguagens, o processo de desserialização pode ser manipulado para executar código durante a reconstrução do objeto — o atacante cria um objeto serializado malicioso ("gadget chain") que, ao ser desserializado, dispara uma cadeia de operações que resulta em execução de código. Ferramentas como o ysoserial (para Java) geram esses payloads. A desserialização insegura é notoriamente perigosa porque frequentemente leva a execução remota de código, e é sutil — a vulnerabilidade está no ato de reconstruir um objeto a partir de dados não confiáveis, algo que não parece perigoso à primeira vista.

Três variações do padrão de injeção

O ponto conceitual que une as três, e que consolida o Bloco XII: todas são, no fundo, variações do padrão de injeção que você já domina — entrada não confiável sendo interpretada como algo com poder (entidades XML, expressões de template, objetos serializados) em vez de tratada como dado inerte. A XXE é injeção em XML; o SSTI é injeção em template; a desserialização é injeção via reconstrução de objeto. Uma vez que você internalizou o padrão fundamental (aula Command Injection: do navegador ao sistema operacional — dado virando instrução), essas classes avançadas deixam de ser magias separadas e se revelam como o mesmo princípio aplicado a contextos mais sofisticados. É exatamente por isso que o curso insistiu em entender o princípio da injeção, não decorar cada ataque: com o princípio, você reconhece a injeção em contextos que nunca viu antes — e é isso que torna alguém um pentester web sênior.

Desligar entidade externa e tratar como dado

Do lado defensivo, cada uma tem sua contramedida, mas o princípio é comum. Contra XXE: desabilitar o processamento de entidades externas no parser XML (a configuração segura que quase toda aplicação deveria usar — resolve a XXE na raiz). Contra SSTI: nunca inserir entrada do usuário na estrutura do template; tratá-la sempre como dado passado ao template, não como parte dele (o equivalente às prepared statements, aplicado a templates). Contra desserialização insegura: evitar desserializar dados não confiáveis; se necessário, usar formatos de dados que não permitem execução (como JSON simples em vez de serialização nativa da linguagem), validar integridade com assinaturas, e usar allowlists de classes permitidas. A lição unificadora do bloco inteiro: a segurança web é, em grande parte, a disciplina de manter a fronteira entre dado e instrução/código — em toda forma que essa fronteira apareça, do SQL ao XML ao template ao objeto serializado. A segunda parte da web avançada traz classes que exploram como servidores e navegadores interpretam requisições e estado.

Fontes e leituras recomendadas

Exercícios

  1. O que é XXE, qual recurso do XML ela explora, e quais dois impactos principais ela pode ter?

    ✓ Resposta:

    XXE (XML External Entity) explora o recurso de entidades externas do XML, que permite referenciar recursos fora do documento. Se o parser resolve entidades externas, o atacante define uma que aponta para um arquivo local ou URL interna. Impactos principais: leitura de arquivos sensíveis do servidor e SSRF (acesso a recursos internos, inclusive metadata da nuvem).

  2. Como se detecta um SSTI, e por que ele é mais grave que um XSS apesar de parecido?

    ✓ Resposta:

    Detecta-se enviando uma expressão que o template avaliaria — ex.: {{7*7}}; se a página exibe 49 em vez do texto literal, o motor avaliou a entrada, confirmando SSTI. É mais grave que XSS porque, embora pareça uma injeção em página, executa no servidor (levando frequentemente a execução de código no servidor), não apenas no navegador da vítima.

  3. Explique a raiz da desserialização insegura e por que ela é sutil.

    ✓ Resposta:

    A raiz é a aplicação desserializar (reconstruir objetos a partir de) dados controlados pelo usuário sem validá-los; em certas linguagens, a reconstrução pode ser manipulada (via gadget chains) para executar código. É sutil porque o ato de reconstruir um objeto a partir de dados não parece perigoso à primeira vista, mas carrega poder de execução.

  4. Qual o padrão único que une XXE, SSTI e desserialização às injeções que você já conhecia?

    ✓ Resposta:

    Todas são variações do padrão de injeção: entrada não confiável interpretada como algo com poder (entidades XML, expressões de template, objetos serializados) em vez de tratada como dado inerte. É o mesmo princípio "dado virando instrução" aplicado a contextos mais sofisticados.

  5. Cite a contramedida de raiz para XXE e para SSTI, mostrando como cada uma preserva a fronteira dado/instrução.

    ✓ Resposta:

    Para XXE: desabilitar o processamento de entidades externas no parser — a entrada XML deixa de poder referenciar recursos, permanecendo dado inerte. Para SSTI: nunca inserir a entrada na estrutura do template, passando-a sempre como dado ao template (não como parte dele) — mantendo a entrada como valor a exibir, não como código a avaliar. Ambas restauram a fronteira entre dado e instrução.