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

XSS em linguagem simples

O cross-site scripting acontece quando um atacante consegue que um site inclua um script malicioso numa página que outros utilizadores vão abrir. O browser confia no script porque vem de um domínio legítimo. A partir daí, o script corre com as permissões da vítima e acede a cookies, tokens de sessão, conteúdo da página ou elementos do DOM.

Uma analogia para quem não escreve código todos os dias. Imagina um post-it colado no quadro de avisos de uma empresa. Se ninguém estiver a vigiar o quadro, qualquer pessoa pode lá afixar instruções falsas que os colegas vão acabar a seguir. O XSS é a versão digital disso: conteúdo em que não se devia confiar, metido dentro de um contexto que parece de confiança.

Três tipos principais (mais alguns casos-limite)

Conhecer as variantes do XSS ajuda a identificar rapidamente uma vulnerabilidade. São três os tipos principais, mais um punhado de casos-limite que continuam a aparecer em campanhas reais.

Stored XSS. O script malicioso fica guardado no servidor (numa base de dados, num CMS ou equivalente) e é servido a todos os visitantes. Caixas de comentários e sistemas de tickets de suporte são os palcos clássicos. O impacto tende a ser grande, porque cada utilizador que lê a página dispara a payload.

Reflected XSS. O script malicioso é devolvido pelo servidor logo na resposta seguinte, tipicamente através de parâmetros de URL. A vítima carrega num link preparado, o servidor reflete o input dentro da página e a payload corre.

DOM-based XSS. A payload nunca chega ao servidor. Corre inteiramente dentro do browser, a manipular o DOM. O servidor pode ficar completamente às escuras, o que torna a deteção mais difícil e explica por que razão este tipo continua a aparecer nos relatórios de incidente.

O self-XSS (levar o utilizador a colar scripts na consola) e o XS-Search (abusar de formulários de pesquisa para inferir estados) também continuam a surgir em ataques atuais. As defesas sobrepõem-se às correções clássicas do XSS.

Como funciona um ataque XSS, passo a passo

Reconstruir uma cadeia de exploração típica deixa claro onde se podem colocar controlos para a quebrar.

1. 1

   Encontrar um ponto de entrada

   O atacante identifica um formulário, um parâmetro de URL ou um campo armazenado que devolve conteúdo sem uma sanitização digna desse nome.
2. 2

   Preparar a payload

   Escreve JavaScript para roubar cookies, alterar elementos do DOM, carregar malware ou desviar tráfego.
3. 3

   Fazer chegar a payload

   Através de um link preparado, de uma conta comprometida ou de conteúdo já guardado na plataforma.
4. 4

   Executar no browser da vítima

   O browser confia na payload porque chega pelo domínio legítimo.
5. 5

   Exfiltrar dados ou saltar para outro alvo

   Os scripts enviam o que roubaram para endpoints do atacante ou injetam mais malware.

O que os atacantes conseguem

O XSS já não se fica pelo defacement. As campanhas atuais usam-no para ataques de alto impacto, e há quatro resultados que se repetem com mais frequência.

Rapto de sessão. Roubam-se tokens de autenticação para fingir ser outro utilizador em portais bancários, painéis de administração e plataformas SaaS. A vítima nunca chega a aperceber-se do roubo.

Recolha de credenciais. Injetam-se formulários de login falsos, ou alteram-se os existentes, para apanhar nomes de utilizador e passwords dentro do próprio browser, antes de o formulário legítimo ser submetido.

Entrega de malware. Carregam-se scripts remotos que largam ransomware ou miners de cripto. É particularmente eficaz em ataques de supply chain, quando um script de terceiros tido como fiável acaba comprometido.

Manipulação social. Reescrevem-se conteúdos ou metem-se mensagens no chat para empurrar o utilizador para ações arriscadas ou transferências de dinheiro. Quando o site em que ele confia pede uma transferência, a transferência acaba por ser feita.

Cinco casos reais em setores diferentes

Estes incidentes (recolhidos de divulgações públicas e de reportagens da imprensa especializada) dão uma ideia da amplitude dos danos que o XSS pode causar.

Plataforma de media (2024). Um XSS na moderação de comentários deixou os atacantes a dar likes automáticos a canais de burla. O dano reputacional foi real: uma queda de 7 % nas métricas de confiança dos subscritores e uma semana inteira a limpar tudo.

Marketplace de ecommerce (2023). Um reflected XSS nos códigos de cupão atirava os compradores para páginas de checkout de phishing. Impacto: 4,1 milhões de dólares em cobranças fraudulentas até a equipa dar pelo padrão.

Portal de saúde (2022). Um stored XSS na mensageria com doentes roubava cookies de sessão e expunha resultados de análises. As consequências incluíram uma notificação HIPAA e um acordo de 1,2 milhões de dólares.

App bancária (2021). Um DOM-based XSS através de widgets injetava pedidos de transferência não autorizados. A resposta rápida do SOC evitou perdas, mas o incidente desencadeou uma auditoria regulatória que se arrastou durante meses.

CMS governamental (2020). Uma antiga falha XSS num CMS legacy permitiu o defacement de comunicações municipais sobre a COVID-19. O dano mediu-se em confiança pública perdida em plena crise, não em dólares.

Porque é que o XSS ainda funciona em 2025

Apesar das frameworks modernas, o XSS continua a aparecer todos os anos no OWASP Top 10. As razões são estruturais, não técnicas.

Codebases enormes continuam a apoiar-se em concatenação de strings e em templating ultrapassado. Os widgets de terceiros (pixels de marketing, chatbots, analytics) trazem uma superfície de ataque que a equipa de segurança não consegue controlar. Equipas de engenharia novas herdam padrões inseguros sem conhecerem os incidentes passados que deram forma àquele código. Os scanners automáticos deixam escapar payloads DOM-based porque analisam o output renderizado no servidor e não o DOM vivo, e os pentests manuais tendem a olhar para outro lado.

Proteção para o dia a dia

Não dá para fazer patch à internet, mas dá para limitar o estrago. Quatro hábitos cobrem a maior parte do risco real.

Abre os links em que não confias dentro do Browser.lol, assim nenhum script corre na tua máquina. Desativa as extensões de browser de que não precises, porque muitas alargam a superfície de ataque XSS. Mantém o browser atualizado: uma CSP (Content Security Policy) moderna bloqueia scripts inline e uma boa parte das técnicas antigas de XSS. Faz logout dos sites sensíveis quando não os estás a usar, porque cookies roubados perdem valor depressa assim que as sessões expiram.

Checklist para programadores e equipas de segurança

Se desenvolves ou manténs aplicações web, há cinco controlos que dão o melhor retorno.

Fazer escape do output consoante o contexto. Os contextos HTML, JavaScript, URL e CSS pedem regras de escaping diferentes. Uma única função genérica "sanitize" deixa quase sempre uma categoria de fora.

Apostar em frameworks com sanitização integrada. React, Vue e Angular reduzem a manipulação direta do DOM e fazem do caminho seguro o caminho por omissão.

Implementar uma Content Security Policy. Restringe as origens dos scripts e proíbe scripts inline sempre que puderes. A CSP é uma das defesas com melhor relação custo-benefício alguma vez integradas num browser.

Usar linters e SAST orientados à segurança. Os plugins de segurança do ESLint, o Semgrep e o SonarQube apanham padrões comuns cedo, quando as correções ainda saem baratas.

Marcar revisões de segurança regulares. Inclui laboratórios de payloads XSS na QA e no âmbito do bug bounty. Ao integrar o Browser.lol na QA, podes executar payloads de prova de conceito pouco fiáveis em segurança, sem pores em risco as máquinas dos programadores.

Conter o script, manter o risco debaixo de olho

O XSS não vai desaparecer. A superfície de ataque cresce sempre que se acrescenta um widget, um pixel de marketing ou uma integração de terceiros. Mas não estás de mãos vazias. Código escrito com disciplina evita as falhas, uma boa higiene do utilizador limita a exposição e os browsers virtuais garantem que, mesmo quando um script malicioso corre, ele nunca chega a tocar no teu hardware.

Trata cada site desconhecido como um possível vetor XSS. Navega a partir de um ambiente isolado, mantém credenciais e cookies bem compartimentados e pressiona as tuas equipas a atacar as causas na raiz. É assim que evitas que um script invisível se transforme num incidente de milhões.