O que é Cross-site scripting (XSS)?

De acordo com o Open Web Application Security Project (OWASP), ataques XSS se enquadram em uma de três categorias: XSS refletido, XSS armazenado e XSS baseado em Document Object Model (DOM). Eles são detalhados abaixo.

Um ataque XSS refletido ocorre quando um hacker entrega um script malicioso a uma aplicação web vulnerável, que o servidor então retorna na resposta HTTP. O navegador da vítima executa o script malicioso como parte da resposta HTTP, comprometendo o usuário legítimo e enviando informações privadas de volta ao hacker.

Ataques XSS refletidos normalmente têm como alvo mensagens de erro ou páginas de resultados de busca, pois é fácil enviar um e-mail malicioso com um link que muitos usuários clicarão. Quando o usuário clica no link, o servidor recebe a solicitação contendo o script malicioso e, como ele não é armazenado, responde enviando o código de volta ao usuário. Quando entradas do usuário não são devidamente validadas e sanitizadas, ou quando dados são duplicados de forma insegura a partir de uma solicitação, existe risco de vulnerabilidades XSS refletidas.

A primeira linha de defesa contra ataques XSS é filtrar conteúdo e verificar entradas do usuário. É possível usar salvaguardas e blocklists de scripts para rejeitar padrões de dados arriscados.

Além disso, é possível implementar uma Política de Segurança de Conteúdo (CSP) rigorosa para ajudar a identificar a origem de scripts inline, reduzindo o risco de ataques XSS refletidos. Uma CSP forte oferece controle sobre scripts e sobre os locais da página web de onde eles podem ser carregados e executados.

Em um ataque XSS armazenado, um script malicioso é salvo na entrada para o servidor-alvo. Diferentemente do XSS refletido, que é executado no servidor, um ataque XSS armazenado é executado no navegador do usuário. Atacantes então usam aplicações HTML modernas, normalmente empregando bancos de dados HTML, para armazenar permanentemente scripts nocivos no navegador.

Em um ataque XSS armazenado, o script é salvo e executado no servidor toda vez que o usuário acessa o site afetado. É fácil para um atacante atingir um grande número de vítimas, e o resultado é persistente. Ataques XSS armazenados também podem ocorrer quando usuários não confiáveis tentam extrair dados do software sem adotar quaisquer precauções de sanitização ou validação.

Ataques XSS armazenados buscam refletir um script malicioso para um usuário, portanto a maneira mais fácil de evitá-los é sanitizar dados do usuário e tratar entradas cuidadosamente — e a melhor forma de fazer isso é usando binding apropriado de parâmetros.

É possível sanitizar dados com um sistema de template de escape automático ou codificação HTML. Deve-se codificar dados destinados à saída para impedir que o servidor os interprete como conteúdo ativo. Isso significa que a aplicação tratará caracteres especiais em seus dados salvos como conteúdo de tag HTML, em vez de HTML simples.  

O binding de parâmetros (data) reduz vetores de injeção, mas também pode passar variáveis como valores adicionais fora da funcionalidade normal da função. Também é possível usar cabeçalhos de resposta apropriados para evitar ataques, normalmente apenas adicionando algumas linhas de código.

Outra técnica para impedir ataques XSS em tempo real é empregar segurança dinâmica que busque ativamente tentativas de exploração. Ao bloquear padrões conhecidos, é possível impedir que atacantes explorem brechas existentes.

Por fim, é possível usar Web Application Firewalls (WAFs) para detecção e mitigação de ataques XSS em tempo real.

A interface DOM permite o processamento e a manipulação de conteúdos de páginas web por meio da leitura e modificação de documentos HTML e XML. Ataques XSS baseados em DOM introduzem alterações maliciosas no conteúdo DOM do navegador da vítima, fazendo com que o código do lado do cliente seja executado de forma não intencional.

Ataques XSS baseados em DOM, diferentemente dos ataques refletidos e armazenados, não armazenam o script malicioso nem o entregam ao servidor. Nesse ataque, a vulnerabilidade está apenas no navegador da vítima. Como eles são mais difíceis de entender do que outras categorias, vulnerabilidades baseadas em DOM são incomuns, sofisticadas e difíceis de mitigar. Além disso, scanners automatizados de vulnerabilidades e web application firewalls não conseguem identificá-los facilmente.

É possível usar as mesmas técnicas de prevenção do caso dos outros dois, mas é necessário ter cuidado extra para sanitizar o código do lado do cliente. Duas técnicas eficazes são evitar que fontes não controladas alterem funções JavaScript potencialmente perigosas (conhecidas como sinks) ou permitir apenas conteúdo confiável usando uma safelist. Com essas precauções, strings que poderiam colocar o DOM em risco não serão enviadas para sinks. Também é possível sanitizar os dados usando funcionalidades nativas do navegador, reduzindo o risco de problemas relacionados a alterações do parser.

Uma nova defesa contra esse tipo de ataque é o uso de tipos confiáveis (trusted types). Esse é um mecanismo de segurança do navegador que garante que todas as partes arriscadas do DOM só possam ser usadas por dados que tenham passado por uma política predefinida. Ele impede que strings arbitrárias sejam passadas para sinks potencialmente perigosos, ajudando o navegador a diferenciar entre código e dados — removendo a principal fonte de vulnerabilidade.