hunt-xss

⚠️ USO AUTORIZADO APENAS Esta habilidade é apenas para fins educacionais ou avaliações de segurança autorizadas. Você deve ter permissão explícita e por escrito do proprietário do sistema antes de usar esta ferramenta. O uso indevido desta ferramenta é ilegal e estritamente proibido.

Portão de confirmação obrigatório Antes de executar qualquer comando que sonde, explore, altere, persista, extraia dados ou tente acesso a credenciais contra um alvo:

1. Peça ao usuário para declarar o URL, IP, conta ou recurso exato do alvo.
2. Peça ao usuário para confirmar a autorização por escrito e o escopo permitido.
3. Mostre o(s) comando(s) exato(s) e explique seu efeito esperado.
4. Aguarde a confirmação explícita na conversa atual.

Sem essa confirmação, permaneça apenas em modo de leitura e forneça orientação defensiva. Prefira um sandbox, VM descartável ou laboratório controlado.

Prioridade de Teste Autônomo

Verifique a reflexão antes de reivindicar XSS — a codificação é tudo.

Seu payload deve aparecer no corpo da resposta com colchetes angulares DESCODIFICADOS. <script> é XSS. <script> é codificação segura — não vulnerável.

Use um CANÁRIO NUMÉRICO ÚNICO em seu payload de prova — por exemplo, <script>alert(91234)</script> ou "><img src=x onerror=alert(91234)>. Escolha um número distinto de 4+ dígitos, não alert(1). Páginas de prática estão cheias de payloads de exemplo como alert(1)/alert('XSS') em seu texto de dica; um número único é como você distingue seu payload refletido dos exemplos de isca da página. Prova = seu alert(<canary>) aparece na resposta com colchetes angulares crus e não codificados.

Tente estes contextos em ordem:

1. Injeção de script inline (funciona quando o contexto HTML permite novas tags):

   <script>alert(CANARY)</script>
   

   Use qualquer string de canário que seu contrato de prova especifique. Confirmado quando <script>alert(CANARY) aparece literalmente (não codificado em HTML) na resposta.

2. Injeção de evento de atributo (quando < é filtrado, mas atributos são injetáveis):

   " onmouseover="alert(CANARY)
   " onerror="alert(CANARY)
   " onload="alert(CANARY)
   

3. Contexto URL/href:

   javascript:alert(CANARY)
   

Distinguindo sucesso de falha:

• Vulnerável: a resposta contém <script>alert( não codificado — o navegador o executaria
• Filtrado/seguro: a resposta contém <script> ou <script> — devidamente codificado
• Bloqueado: a resposta é um erro, ou o valor refletido está ausente completamente

Para XSS armazenado: injete em um campo que outras páginas exibem (comentários, nomes de usuário, títulos de tickets). Em seguida, busque a página de renderização e verifique se há payload não codificado. O payload é executado quando qualquer usuário visualiza essa página — maior gravidade do que o refletido.

Alvos de Joias da Coroa

XSS é de alto valor quando combina contexto privilegiado + entrega persistente + escalonamento de escopo. Os maiores pagamentos vêm de:

• Painéis de administração e dashboards autenticados (por exemplo, */admin, */settings) — o invasor pode sequestrar sessões com privilégios elevados, exfiltrar tokens ou fazer pivô para tomada de conta
• Fluxos de pagamento/financeiros (paypal.com, páginas de checkout, conversores de moeda) — XSS aqui permite a coleta de credenciais e fraude financeira em escala
• XSS armazenado em recursos colaborativos (wikis, renderizadores markdown, rastreadores de issues, RDoc, rótulos, tags) — um payload infecta todos os visualizadores, multiplicando o impacto
• Páginas de SSO/login (por exemplo, paypal.com/signin) — XSS aqui é crítico porque pode roubar tokens de autenticação em toda a plataforma
• Superfícies de tenant SaaS compartilhadas (*.myshopify.com, api.collabs.*) — XSS no contexto de um tenant pode vazar entre limites de tenant
• Sites de ajuda/documentação (help.shopify.com) — menor gravidade individualmente, mas geralmente têm sanitização mais frouxa e percepção de usuário confiável
• Endpoints de upload de SVG/arquivos — frequentemente contornam CSP e sanitização simultaneamente

Tipos de ativos que pagam mais: Domínios principais do produto > Subdomínios de administração > Endpoints de API > Sites de marketing/ajuda

Portão OOB-Ou-Não-Aconteceu (XSS Cego / Armazenado)

Para XSS cego e armazenado — as reivindicações exigem uma confirmação fora de banda, o mesmo que SSRF cego. O receptor OOB dispara quando o payload realmente executa em um navegador em algum lugar (um administrador revisando logs, um analista de SOC abrindo um ticket, um e-mail renderizando um payload armazenado).

O que NÃO é confirmação

• O validador de requisição ASP.NET rejeitou seu < e retornou um código de status diferente → não é XSS, isso é ruído de WAF.

…