A injeção de HTML ocorre quando um atacante consegue inserir tags HTML arbitrárias em uma página web, o que pode levar a ataques de XSS ou à manipulação da estrutura da página. Embora seja menos grave que a injeção de scripts, a injeção de HTML ainda pode viabilizar vários ataques, incluindo falsificação de conteúdo e ataques baseados em estilos. A prevenção exige validação adequada das entradas e codificação das saídas.
A injeção de HTML é uma falha em que uma aplicação insere uma entrada controlada pelo invasor em uma página sem codificá-la, permitindo que o invasor adicione ou altere marcação HTML, tags, atributos e estrutura. É a categoria mais ampla da qual o cross-site scripting é o caso mais severo: se a marcação injetada puder incluir um script executável ou um manipulador de eventos, ela vira XSS, mas se a filtragem bloquear scripts enquanto ainda permite outras tags, resta ao invasor a injeção de HTML pura. Mesmo sem executar código, um invasor pode injetar links, formulários, imagens, iframes e estilos. A causa raiz é a mesma, dados não confiáveis chegando à saída HTML sem escape, seja a fonte um parâmetro de URL, um campo de formulário ou conteúdo armazenado.
Embora muitas vezes classificada como menos grave que a injeção de scripts, a injeção de HTML está longe de ser inofensiva. Um invasor pode enxertar um formulário de login falso convincente em uma página confiável e enviar as credenciais para o próprio servidor, uma forma de phishing na página que ainda exibe o domínio real na barra de endereço. O conteúdo injetado pode desfigurar a página, inserir textos enganosos ou imagens ofensivas, sobrepor elementos para sequestrar cliques, ou trazer recursos externos. Marcação pendente e imagens injetadas também podem vazar partes da página ou tokens anti-CSRF para um invasor. E como filtros que removem tags de script mas permitem outra marcação são comuns, a injeção de HTML frequentemente se torna o degrau que depois é escalado a um XSS completo.
A correção espelha a defesa contra XSS: nunca coloque entrada não confiável em uma página como marcação bruta. Codifique a saída para o contexto HTML, de modo que as tags sejam renderizadas como texto visível, valide a entrada e, quando precisar aceitar conteúdo rico, passe-o por um sanitizador de allowlist estrita que remova tags desconhecidas, manipuladores de eventos e atributos perigosos. Uma Content Security Policy limita o dano de recursos injetados. A cside opera em uma camada diferente, monitorando os scripts de terceiros que uma página carrega: seu método Script analisa cada payload, consegue bloquear comportamentos maliciosos em tempo real e mantém registros forenses que atendem à PCI DSS 6.4.3 e 11.6.1. Ela complementa, em vez de substituir, a codificação e a sanitização nos seus próprios templates.
Elas se sobrepõem, mas não são idênticas. Ambas partem de entrada sem escape chegando à página. O XSS especificamente executa JavaScript do invasor, enquanto a injeção de HTML abrange qualquer marcação injetada, incluindo casos em que os scripts são filtrados mas outras tags ainda são renderizadas. Todo XSS é uma forma de injeção de HTML, mas nem toda injeção de HTML chega à execução de scripts.
Sim. Sem nenhum script, um invasor pode injetar um formulário de login falso para phishing na página, desfigurar conteúdo, embutir links ou imagens enganosos, ou usar marcação pendente e CSS para exfiltrar dados como tokens anti-CSRF. A falsificação de conteúdo em um domínio confiável é convincente justamente porque a URL é genuína.
We answer client-side security questions every day. Bring yours.