Ataques XSS: a ameaça invisível no browser

Compreender o XSS

O XSS acontece quando dados não fiáveis são interpretados como conteúdo executável numa página web. O script corre na origem dessa página: pode interagir com o seu DOM e, muitas vezes, fazer pedidos ao site como o utilizador com sessão iniciada. A política da mesma origem continua a limitar o acesso a outros sites. Um cookie marcado HttpOnly não pode ser lido através de document.cookie, embora o script ainda possa agir numa página autenticada.

A definição SameSite regula sobretudo quando o navegador envia cookies em pedidos entre sites. Pode ajudar contra algumas formas de falsificação de pedidos, mas não elimina um script que já corre na página do próprio site. A referência da MDN sobre Set-Cookie distingue as funções de SameSite e HttpOnly.

Imagina o quadro de avisos de uma empresa. Um visitante deve poder afixar uma nota, mas não alterar as instruções ou os controlos do quadro. O XSS é o equivalente digital a tratar a nota como parte do próprio quadro. A fronteira falha quando os dados são colocados num contexto em que podem ser executados.

Três tipos principais e alguns casos próximos

Os três nomes indicam onde os dados não fiáveis entram e se tornam executáveis. Podem sobrepor-se: um servidor pode entregar dados que o código do navegador coloca depois numa operação perigosa do DOM.

XSS armazenado. A aplicação guarda conteúdo controlado pelo atacante, por exemplo num comentário, perfil ou pedido de apoio, e mostra-o depois a outras pessoas. A exposição depende de quem consegue ver esse conteúdo e de como é apresentado.

XSS refletido. O servidor inclui na resposta dados recebidos num pedido, muitas vezes num parâmetro de URL, sem os codificar de forma segura para o contexto de saída. Uma ligação preparada pelo atacante pode levar alguém até essa resposta.

XSS baseado no DOM. O código do navegador lê dados não fiáveis e entrega-os a uma operação perigosa do DOM, como innerHTML. Os dados podem vir de um URL, de uma resposta do servidor ou de outra fonte. O que define este tipo é a transformação insegura no navegador. Consulta o guia da OWASP sobre XSS baseado no DOM.

O self-XSS é diferente: o atacante convence a pessoa a executar código, por exemplo colando-o nas ferramentas de desenvolvimento. Os XS-Leaks permitem inferir informação entre origens a partir de efeitos observáveis; são outra classe de problema. Nenhum destes nomes deve esconder o problema central do XSS: dados não fiáveis tornam-se conteúdo ativo numa página de confiança.

Os passos de um ataque XSS

Um percurso típico mostra onde os controlos da aplicação podem interromper o ataque.

1. 1

   Encontrar uma entrada

   O atacante encontra um comentário, parâmetro de URL, mensagem ou outro valor que acaba por aparecer numa página.
2. 2

   Chegar a um contexto de saída inseguro

   A aplicação insere esse valor onde o navegador o pode interpretar como HTML ou script, em vez de texto.
3. 3

   Fazer chegar o conteúdo injetado

   O atacante leva alguém a abrir a página afetada, talvez através de uma ligação preparada ou de conteúdo partilhado.
4. 4

   Executar na página afetada

   Se o navegador executar o código injetado, este partilha a origem da página e pode interagir com conteúdo e interfaces disponíveis, sujeito aos limites do navegador e do site.
5. 5

   Abusar do acesso disponível

   Conforme a aplicação, o código pode alterar a página, ler dados expostos ou fazer pedidos com a sessão atual. O sucesso depende dos controlos do site.

O que o código injetado pode fazer

Os efeitos do XSS vão além das alterações visíveis numa página. O impacto depende da informação e das ações acessíveis na página afetada. Estes quatro resultados ilustram possibilidades, não uma ordem de frequência.

Ações na conta. O código injetado pode fazer pedidos a partir de uma página autenticada e ler tokens que a aplicação exponha ao JavaScript. Cookies HttpOnly impedem a leitura direta desses cookies, mas não bloqueiam, por si só, ações no mesmo site. Consulta o guia da MDN sobre cookies.

Recolha de credenciais. Um formulário alterado pode recolher uma palavra-passe ou outros dados à medida que a pessoa os escreve. Isso exige que introduza essa informação na página: o XSS não revela automaticamente uma palavra-passe guardada noutro lugar.

Manipulação da página. O código pode alterar ligações, instruções ou detalhes de uma operação que o utilizador vê. Pode também carregar outros recursos web dentro dos limites impostos pelo site. Para executar malware no dispositivo local, seria necessária uma etapa distinta, como explorar uma falha do navegador ou abrir um ficheiro descarregado.

Exposição de dados. Um script pode ler informação já presente na página e enviá-la para fora se os controlos de rede o permitirem. A política da mesma origem continua a restringir a leitura de sites não relacionados. Os dados sensíveis e as permissões do próprio site afetado são o risco.

Cinco cenários ilustrativos

Estes exemplos são hipotéticos, não relatos de incidentes reais. Cada um mostra um ponto em que importa verificar se dados não fiáveis podem passar a código.

Site de uma comunidade. A pré-visualização de um comentário apresenta HTML enviado por um utilizador como conteúdo ativo. Se uma pessoa da equipa de moderação a abrir com a sessão iniciada, o código injetado poderá agir na interface de moderação. É preciso apresentar o conteúdo de forma segura e rever esse fluxo com permissões elevadas.

Loja online. Um termo de pesquisa é inserido numa resposta HTML sem codificação adequada ao contexto. Quem seguir um URL preparado para o ataque poderá ver uma ligação alterada para a página de pagamento. O domínio legítimo, por si só, não prova que a ligação apresentada seja segura.

Portal de doentes. Uma mensagem guardada aparece no browser de um profissional de saúde. Mesmo com cookies HttpOnly, o código injetado poderá ler informação já presente nessa página ou enviar pedidos permitidos àquele profissional. Os controlos de acesso e a apresentação segura do conteúdo são ambos necessários.

Painel financeiro. Código do lado do cliente lê um fragmento do URL e escreve-o na página através de innerHTML. Uma ligação maliciosa poderá alterar o que um cliente vê. A validação e a confirmação no servidor poderão impedir uma transferência não autorizada, mas a falha no DOM continua a exigir correção.

Site de informação pública. Um modelo antigo de CMS trata um título como HTML fiável. Uma pessoa com permissões de edição, ou com uma conta comprometida, poderá alterar orientações públicas. Os modelos antigos e as permissões de quem os alimenta merecem tanta atenção como os componentes novos.

Porque continua a haver XSS

As frameworks modernas codificam muitos valores de forma segura por omissão. Ainda assim, HTML inserido diretamente, APIs do DOM inseguras, atalhos em modelos e código de terceiros podem contornar essas proteções. A OWASP trata a injeção, incluindo XSS, como um risco para aplicações web. O seu guia de prevenção de XSS explica porque nenhuma medida cobre todos os contextos.

As aplicações grandes misturam modelos antigos, componentes modernos, texto formatado enviado por utilizadores e scripts de outros fornecedores. A correção depende da origem e do destino dos dados: texto HTML, atributos, URLs, blocos de script e pontos de inserção no DOM exigem cuidados diferentes. As ferramentas automáticas ajudam, mas testes limitados às respostas do servidor podem falhar transformações feitas no browser. Inclui testes no browser e revisão do código nos percursos que tratam dados não fiáveis.

Passos práticos para quem usa o site

Não podes corrigir uma vulnerabilidade num site que não controlas, mas podes limitar os dados e permissões que expões. Estes passos reduzem alguns riscos sem garantir proteção contra XSS.

Confirma o endereço do site antes de introduzires credenciais ou aprovares ações sensíveis. Mantém o browser atualizado e remove as extensões de que não precisas. Usa contas ou perfis de browser separados para tarefas com níveis de confiança diferentes. Se suspeitares de um ataque, termina a sessão e verifica a atividade da conta num dispositivo fiável. Cada serviço decide se essa saída termina também as outras sessões. O Browser.lol pode executar o código do site num browser remoto, mas um ataque XSS pode continuar a afetar a sessão da conta e o que escreves ou aprovas nela. O visualizador, a área de transferência e os downloads também ligam a sessão ao teu dispositivo.

Lista de verificação para desenvolvimento e segurança

A prevenção começa na aplicação. Testa estas cinco medidas nos contextos que a tua aplicação realmente utiliza.

Codificar a saída para o contexto certo. Texto HTML, atributos, URLs, JavaScript e CSS exigem tratamentos diferentes. Usa APIs de texto para texto simples e uma ferramenta de sanitização mantida quando for necessário aceitar HTML formatado.

Usar conscientemente as proteções da framework. React, Vue e Angular podem codificar valores apresentados na página. As funções de HTML direto e as alterações diretas ao DOM contornam parte dessa proteção. Revê essas exceções com atenção.

Configurar uma CSP restritiva. Uma Content Security Policy bem concebida, baseada em nonces ou hashes, pode limitar a execução de scripts depois de uma injeção. É uma defesa adicional, não substitui a codificação nem a sanitização. Consulta o guia da OWASP sobre CSP.

Rever o percurso dos dados e os pontos de inserção inseguros. A análise estática pode assinalar padrões arriscados, como atribuições não verificadas a innerHTML. Junta-lhe testes das páginas apresentadas e dos percursos de dados tratados no lado do cliente.

Rever os fluxos com permissões elevadas. Testa onde a equipa vê conteúdo enviado por utilizadores, onde é permitido texto formatado e onde uma página pode desencadear ações sensíveis. Testar num browser remoto pode reduzir a exposição local ao código da página, mas não torna inofensiva uma prova de conceito. Usa contas de teste e evita segredos reais.

Impedir que os dados se tornem código

O XSS resulta de uma falha na fronteira entre dados e conteúdo executável. A codificação adequada ao contexto, as APIs seguras do DOM, o tratamento cuidadoso de HTML formatado e uma CSP restritiva reduzem a probabilidade de dados não fiáveis se tornarem código. As definições dos cookies e as verificações no servidor podem limitar algumas consequências, mas nenhuma medida resolve todos os casos de XSS.

Um browser remoto muda o local onde o código do site é executado. Não corrige o site vulnerável nem protege a conta de ações feitas na sessão remota. Mantém as contas sensíveis separadas, confirma as ações de maior impacto e corrige na origem o percurso que transforma dados em código. Estas medidas complementam-se porque respondem a partes diferentes do risco.