Introdução: “XSS? Ainda?”
Em pleno 2025, ainda estamos falando de XSS? Sim, ainda estamos. Mesmo com o uso de frameworks modernos, WAFs inteligentes e uma infinidade de artigos explicando como mitigar essa ameaça, o Cross-Site Scripting (XSS) continua presente, sorrateiro, persistente e muitas vezes negligenciado.
O XSS é uma das primeiras vulnerabilidades abordadas em cursos introdutórios de segurança ofensiva e testes de invasão em aplicações web. Com um payload simples, instrutores demonstram como essa falha é trivial de ser explorada, evidenciando o perigo e a facilidade de sua exploração.
Mas o que é XSS, afinal? De acordo com a OWASP, ataques de Cross-Site Scripting são um tipo de injeção na qual scripts maliciosos são inseridos em sites vulneráveis. Esses ataques ocorrem quando um invasor usa uma aplicação web para enviar código malicioso, geralmente scripts executados no navegador, para outro usuário. As falhas que tornam esses ataques possíveis são bastante comuns e surgem sempre que uma aplicação web incorpora a entrada do usuário na saída gerada sem realizar a validação ou codificação apropriadas.
Também de acordo com a OWASP, o navegador da vítima não possui mecanismo para distinguir scripts legítimos de maliciosos. Assim, ao receber e executar o código, ele confia que ele veio de uma fonte segura. Como resultado, o invasor pode acessar cookies, tokens de sessão e outras informações confidenciais armazenadas pelo navegador, bem como reescrever o conteúdo da página ou redirecionar o usuário para sites maliciosos disfarçados de legítimos.
CVE-Hunters vs XSS
O grupo CVE-Hunters foi criado em novembro de 2024 como uma iniciativa conjunta entre alunos e um professor, com um objetivo claro: identificar vulnerabilidades (CVEs) em projetos de código aberto. A proposta era proporcionar aos alunos experiência prática na busca por falhas em ambientes reais, indo além de laboratórios controlados ou desafios de Capture The Flag (CTF).
Desde então, o grupo analisou uma ampla gama de projetos, desde pequenos sistemas comunitários até aplicações amplamente utilizadas nos setores público e educacional. Ao longo do caminho, um padrão se destacou: a frequência com que vulnerabilidades de Cross-Site Scripting (XSS) foram encontradas.
Essa recorrência levanta uma questão importante: os desenvolvedores pararam de tratar o XSS com a devida seriedade? Apesar de ser uma falha amplamente documentada e conhecida há anos, ela ainda aparece com frequência. Mesmo em organizações com processos de desenvolvimento maduros, vulnerabilidades de XSS continuam a aparecer devido à complexidade dos fluxos de entrada e saída, ao uso de bibliotecas legadas ou à falta de testes contextualizados.
Atualmente, o grupo tem 135 vulnerabilidades reportadas, 53 das quais já foram oficialmente registradas como CVEs. Do total de vulnerabilidades descobertas, 104 são do tipo XSS, o que representa uma proporção significativa e preocupante.
Foram identificadas 62 ocorrências do tipo armazenado e 42 do tipo refletido, revelando uma distribuição relativamente equilibrada.
Essas estatísticas por si só reforçam a ideia de que o XSS ainda é um problema real, frequentemente ignorado durante o desenvolvimento, e que continua a merecer atenção, tanto da comunidade técnica quanto dos desenvolvedores responsáveis por aplicativos em produção.
Experiência prática
Você pode estar pensando: "Ok, o grupo CVE-Hunters encontrou muitos XSS em projetos de código aberto, mas quem pode dizer que grandes empresas também são vulneráveis?"
Vamos fazer um experimento rápido com um dos XSS mais recentes divulgados durante a escrita deste artigo: CVE-2025-0133. Um XSS refletido nos produtos de gateway e portal GlobalProtect, recursos do PAN-OS da Palo Alto Networks, publicado em 14 de maio de 2025.
Com uma simples consulta no Shodan, podemos verificar a estimativa de uso deste produto no mundo.
No entanto isso não significa que todos estão vulneráveis. Vamos ao experimento para este artigo.
Primeiro, extraímos alguns resultados do Shodan, uma pequena amostragem do montante total:
|
|
Depois disso, podemos usar o Nuclei
para testar essa vulnerabilidade e automatizar o teste:
|
|
Template do nuclei utilizado para realizar o scan: CVE-2025-0133.
|
|
Obtivemos um número significativo de hosts vulneráveis. Em seguida, tentamos identificar, entre esses resultados, quaisquer hosts que tivessem um VDP público, para que pudéssemos notificá-los sobre a vulnerabilidade. Essa etapa é um pouco complexa de ser realizada manualmente, por isso utilizamos inteligência artificial para cruzar os domínios extraídos do Shodan
com informações disponíveis na internet sobre empresas que possuem programas de recompensa por bugs ou VDPs abertos.
Durante esta pesquisa, encontramos apenas dois domínios com VDPs públicos — um de uma grande empresa do setor privado e o outro de uma agência governamental. Ambos estão localizados nos Estados Unidos: um com um VDP hospedado no BugCrowd e o outro com um VDP privado, acessível por e-mail.
Relatamos ambas as vulnerabilidades às empresas de forma responsável.
É importante destacar que a amostra testada representa apenas uma fração dos sistemas expostos.
Mais números
Se você ainda não está convencido pela quantidade de XSS que temos por aí, podemos fazer outra pesquisa simples no GitHub Advisory Database, onde obtemos um retorno de mais de 31.611 ocorrências relacionadas a XSS.
Se ainda não está convencido da quantidade de XSS que temos por ai, podemos fazer mais uma pesquisa simples no GitHub Advisory Database onde temos um retorno de mais de 31.611 ocorrências relacionadas a XSS.
Uma busca no banco de dados de CVE (Common Vulnerabilities and Exposures) também revela um número significativo de vulnerabilidades registradas relacionadas ao XSS, demonstrando sua recorrência em diferentes sistemas, aplicações e contextos ao longo dos anos.
Além disso, uma busca realizada na plataforma HackerOne, amplamente reconhecida no ecossistema de Bug Bounty, resulta em um total de 2.225 relatórios públicos envolvendo vulnerabilidades de Cross-Site Scripting. Esses dados reforçam não apenas a prevalência do XSS, mas também o interesse contínuo da comunidade de segurança em explorá-lo e relatá-lo, mesmo em ambientes com altos padrões de segurança.
O que dá para fazer com um XSS além do alert(1)?
O famoso alert(1) costuma ser o primeiro exemplo usado para demonstrar uma falha de XSS. No entanto, os impactos reais dessa vulnerabilidade vão muito além de uma simples janela de alerta. Abaixo, listamos algumas ações maliciosas clássicas e conhecidas que podem ser realizadas por um invasor ao explorar uma falha de Cross-Site Scripting:
- Roubo de Cookie, (se o cookie não estiver protegido com o sinalizador HttpOnly);
- Sequestro de Sessão, assumindo a identidade da vítima em aplicativos autenticados;
- Keylogging, capturando tudo o que o usuário digita na página comprometida;
- Redirecionamentos Maliciosos para páginas falsas, com o objetivo de aplicar golpes;
- Execução de ações em nome do usuário, como enviar mensagens, alterar configurações ou excluir dados;
- Execução Remota de Código, embora rara e dependendo do contexto específico, pode ser possível obter acesso remoto a o sistema a partir de um XSS.
Esses exemplos mostram que, embora o XSS seja uma vulnerabilidade frequentemente subestimada, ele pode ter consequências graves, especialmente quando explorado em aplicativos com dados confidenciais ou com alto nível de privilégio para o usuário afetado.
Conclusão
O XSS não morreu; talvez tenha sido apenas ignorado diante de novas ameaças mais "glamourosas". Mas sua presença silenciosa continua a oferecer uma superfície de ataque explorável, muitas vezes com impacto crítico.
Apesar de frequentemente ser classificado como uma vulnerabilidade de gravidade média ou mesmo baixa, o XSS não deve ser subestimado. Seu impacto pode ser significativo, especialmente quando envolve roubo de cookies, sequestro de sessão ou redirecionamento para páginas maliciosas. E o que é mais perigoso: as proteções tradicionais nem sempre são suficientes para impedir que o usuário seja induzido a clicar naquele site de phishing que está usando uma URL legítima com uma vulnerabilidade XSS.
Afinal, o XSS geralmente depende de um único clique e, nesse cenário, o elo mais fraco geralmente é o próprio usuário. Não importa quão robusta seja sua estrutura ou quão bem configurada esteja sua WAF: se o invasor conseguir criar um link malicioso convincente, basta uma ação desatenta da vítima para que o ataque se concretize.
Enquanto nós confiamos em estruturas e WAFs, o invasor confia em nossa falta de cuidado e na curiosidade do usuário.
Apesar de muitas vezes ser classificado como uma vulnerabilidade de severidade média ou até baixa, o XSS não deve ser subestimado. Seu impacto pode ser significativo, especialmente quando envolve o roubo de cookies, sequestro de sessão ou redirecionamento para páginas maliciosas. E o mais perigoso: nem sempre as proteções tradicionais são suficientes para impedir que o usuário seja enganado e clique naquele phishing que está utilizando uma URL legítima com vulnerabilidade de XSS.
Afinal, o XSS frequentemente depende de um simples clique, e nesse cenário, o elo mais fraco costuma ser o próprio usuário. Não importa o quão robusto seja seu framework ou quão bem configurado esteja seu WAF: se o atacante conseguir criar um link malicioso convincente, basta uma ação desatenta da vítima para que o ataque se concretize.
Enquanto confiamos em frameworks e WAFs, o atacante confia no nosso descuido,e na curiosidade do usuário.
Escrito por
Colaboradora
Parceria
Esse post foi feito em parceria com Hacktiba para o Pulse 07.
Por: CVE-Hunters