hunt-business-logic

⚠️ 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.

Porta de confirmação obrigatória 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 somente leitura e forneça apenas orientação defensiva. Prefira um sandbox, VM descartável ou laboratório controlado.

Alvos Principais (Crown Jewel Targets)

Vulnerabilidades de lógica de negócios pagam mais em plataformas onde transações financeiras, verificação de identidade e controles de acesso se cruzam com consequências do mundo real. Os alvos mais ricos são:

• Plataformas de e-commerce e pagamento (Valve/Steam, Shopify) — manipulação de fluxo de pagamento, produtos grátis, adulteração de preços
• Aplicativos de marketplace e economia gig (Airbnb, Uber) — bypass de identidade/verificação permitindo fraude ou interações inseguras
• SaaS com acesso em camadas (Mozilla Monitor) — bypass de verificação para desbloquear recursos de monitoramento sem permissão
• Aplicativos de consumo de alto tráfego (Snapchat, Yelp) — bypass de limite de taxa permitindo spam, enumeração ou abuso em escala

Tipos de ativos que pagam: fluxos de checkout, endpoints de assinatura, sistemas de callback/verificação, manipuladores de webhook, portais de funcionários/internos expostos à internet e qualquer endpoint que confie em dados fornecidos pelo cliente para tomar decisões de autorização.

Sinais da Superfície de Ataque

Padrões de URL para observar:

• /checkout, /order, /subscribe, /payment, /verify, /confirm, /callback
• /internal, /employee, /summit, /staff, /admin — páginas internas acidentalmente públicas
• /api/v*/payment, /api/v*/notify, /webhook — callbacks de provedores de pagamento
• Endpoints que aceitam cabeçalhos X-Forwarded-For, X-Real-IP, CF-Connecting-IP

Sinais de resposta/cabeçalho:

• Set-Cookie com estado de sessão não validado vinculado a dados de carrinho ou pedido
• Nomes de provedores de pagamento em respostas: Smart2Pay, Stripe, PayPal, Braintree
• Cadeias de redirecionamento através de páginas de pagamento de terceiros (oportunidade de dados em trânsito)
• 200 OK em endpoints de assinatura/verificação sem CAPTCHA ou token

Padrões de JS:

• URLs internos codificados em pacotes frontend (/employee/, /staff/, /internal/)
• Cálculo de preço no lado do cliente antes do envio ao servidor
• Lógica de verificação que verifica apenas no frontend (if (verified) { ... })
• fetch('/api/subscribe', { method: 'POST', body: ... }) sem token anti-CSRF ou token de limite de taxa

Sinais de stack de tecnologia:

• Lojas Shopify com páginas de canal em rascunho/não publicadas
• Aplicativos que usam limitação de taxa baseada em IP sem vinculação de sessão/conta
• Webhooks de pagamento sem validação de assinatura HMAC
• Fluxos de callback de SMS/telefone que não verificam a propriedade antes de habilitar recursos

Metodologia de Caça Passo a Passo

1. Mapeie todos os limites de autenticação. Faça um spider no alvo. Identifique páginas/endpoints que servem conteúdo autenticado (portais de funcionários, recursos premium, páginas de pedidos) e teste cada um sem autenticação. Procure por páginas internas indexadas em pacotes JS ou vinculadas de robots.txt/sitemap.xml.

2. Identifique todos os fluxos de verificação. Enumere: verificação de e-mail, verificação de telefone/SMS, verificação de pagamento, CAPTCHA, portões de idade. Para cada um, teste: o que acontece se você pular a etapa de verificação completamente? O que acontece se você reproduzir um token válido em uma conta diferente?

3. Teste os controles de limitação de taxa em todos os formulários. Para cada endpoint POST (assinar, fazer login, OTP, pesquisar), envie 50+ requisições rápidas. Varie: remova cookies, alterne cabeçalhos X-Forwarded-For / X-Real-IP, mude User-Agent. Verifique se o servidor usa o IP dos cabeçalhos em vez do IP da conexão.

4. Intercepte e modifique fluxos de pagamento. Use o Burp Suite para interceptar todas as requisições entre seu navegador, o aplicativo e o provedor de pagamento. Identifique onde os campos de preço, moeda, ID do pedido ou status são definidos. Tente modificar os valores para R$0,01 ou a moeda para uma moeda de baixo valor. Procure por endpoints de POST-back/webhook que aceitam confirmação de pagamento — teste se eles validam HMAC/assinatura.

…