🎯 Por que isso importa

Algumas vulnerabilidades estão em todo lugar se você souber onde procurar. Essas "vitórias rápidas" são acessíveis a novos caçadores, pagam recompensas reais e constroem sua reputação. Foque aqui primeiro antes de partir para cadeias de ataques complexas - você aprenderá as aplicações enquanto ganha dinheiro.

🔍 O que você vai aprender

• IDOR/BOLA - acessando dados de outros usuários (e por que acontece)
• Open redirects - onde eles importam e como demonstrar impacto
• Divulgação de informações - o que realmente paga recompensas
• Subdomain takeover - reivindicando recursos abandonados
• Como encadear bugs de baixa severidade em maior impacto

🚀 Sua primeira vitória

Ao final deste capítulo, você conhecerá as vulnerabilidades mais propensas a render sua primeira recompensa - e entenderá POR QUE elas existem para encontrá-las consistentemente.

"Sua primeira recompensa não precisa ser um P1. Comece com o que é encontrável."

O que é IDOR e por que existe?

IDOR (Insecure Direct Object Reference) — também chamado BOLA (Broken Object Level Authorization) em segurança de API — ocorre quando uma aplicação expõe referências a objetos internos (como IDs de banco de dados) e falha em verificar se o usuário tem permissão para acessá-los.

Por que acontece: Desenvolvedores constroem funcionalidades como "ver meu perfil" ou "baixar minha fatura". O código verifica "o usuário está logado?" mas esquece de verificar "este usuário É DONO deste recurso?" É um erro fácil:

# CÓDIGO VULNERÁVEL (exemplo simplificado)
def get_invoice(request, invoice_id):
    # Verificação: Usuário está logado? ✓
    if not request.user.is_authenticated:
        return "Por favor faça login"

    # Verificação faltando: Este usuário é dono desta fatura? ✗
    invoice = Invoice.objects.get(id=invoice_id)
    return invoice.data  # Retorna QUALQUER fatura para QUALQUER usuário logado

# CÓDIGO SEGURO (como deveria ser)
def get_invoice(request, invoice_id):
    if not request.user.is_authenticated:
        return "Por favor faça login"

    # Verificação: Esta fatura pertence a este usuário? ✓
    invoice = Invoice.objects.get(id=invoice_id, owner=request.user)
    return invoice.data  # Retorna apenas faturas do próprio usuário

Por que é tão comum: A lógica de autorização tem que ser implementada para cada endpoint. Perca um, e você tem um IDOR. Em grandes aplicações com centenas de endpoints, desenvolvedores inevitavelmente perdem alguns. IDOR está consistentemente no OWASP Top 10 porque é fácil de criar e fácil de encontrar.

O que é e por que importa?

Open Redirect — Uma aplicação aceita uma URL controlada pelo usuário e redireciona para ela sem validação. Por si só, isso parece inofensivo, mas permite ataques reais:

• Phishing: Enviar vítimas para banco-confiavel.com/login?redirect=site-malicioso.com. Eles veem o domínio confiável, clicam, e caem em uma página de login falsa que rouba credenciais.
• Roubo de tokens OAuth: Se o redirecionamento acontece durante login OAuth, atacantes podem roubar tokens de autenticação redirecionando para seu servidor.
• Bypass de controles de segurança: Algumas ferramentas de segurança colocam o domínio confiável em whitelist mas não validam parâmetros de redirecionamento.

Por que programas aceitam: Nem todos os programas pagam por open redirects. Muitos exigem impacto demonstrado (encadeado com roubo OAuth, usado em cenário real de phishing). Sempre verifique a política do programa - alguns excluem explicitamente "redirecionamentos não validados" sem encadeamento.

Dica para demonstrar impacto: Muitos programas rejeitam open redirects sem prova de impacto. No seu relatório, explique o ataque específico: "Um atacante poderia usar este redirecionamento para roubar tokens OAuth durante o fluxo de login, levando a tomada de conta." Ou demonstre um cenário de phishing com capturas de tela.

O que paga vs o que não paga

Nem toda divulgação de informações é igual. Programas se importam com informações que podem ser usadas para ataques adicionais ou prejudicam diretamente os usuários:

Paga bem (Alto impacto):

• Chaves de API com acesso de escrita — Chaves AWS, chaves Stripe, credenciais de nuvem
• Credenciais de banco de dados — Mesmo que você não consiga conectar, a exposição é crítica
• PII de usuários — Emails, endereços, números de telefone vazados
• Código fonte — Especialmente se contém segredos hardcoded
• Tokens de autenticação interna — Segredos JWT, chaves de assinatura de sessão

Pode pagar (Impacto médio):

• Endereços IP internos — Úteis para ataques adicionais
• Endpoints de debug — Se expõem dados sensíveis
• Stack traces com caminhos sensíveis — Revelam estrutura interna

Geralmente não paga (Impacto baixo/nenhum):

• Números de versão de software sozinhos (sem vulnerabilidades conhecidas)
• Mensagens de erro genéricas
• Endereços de email que já são públicos
• "Você está usando nginx" sem impacto de segurança

Como funciona o subdomain takeover

Subdomain takeover acontece quando:

1. Uma empresa configura blog.empresa.com apontando para Heroku, GitHub Pages ou similar
2. Eles param de usar o serviço e deletam o app, mas esquecem de remover o registro DNS
3. O subdomínio ainda aponta para o serviço, mas ninguém reivindicou aquele recurso
4. Um atacante cria uma conta no serviço e reivindica aquele nome de recurso
5. Agora o atacante controla o conteúdo em blog.empresa.com!

Impacto: Atacantes podem servir páginas de phishing, roubar cookies (se o subdomínio é confiado pelo domínio pai), hospedar malware e danificar reputação - tudo parecendo vir da empresa legítima.

🏆 $500 por IDOR em endpoint de fatura

O caçador notou URLs como /api/invoices/12345 ao baixar sua própria fatura. Ele mudou o ID para 12346 e recebeu a fatura de outro cliente - completa com nome, endereço e histórico de compras.

Técnica: Mudou um número na URL. Precisou de duas contas de teste e 5 minutos de teste. A vulnerabilidade era trivial de encontrar mas tinha impacto real na privacidade dos clientes.

🏆 $300 por chave de API Stripe exposta

Procurando em bundles JavaScript, o caçador encontrou uma chave de API Stripe começando com sk_live_. A chave tinha permissões de escrita - um atacante poderia ter criado cobranças fraudulentas ou acessado dados de pagamento dos clientes.

Técnica: Devtools do navegador → Sources → Buscar "sk_live". A chave estava hardcoded em um bundle webpack. Levou 10 minutos para encontrar.

🏆 $1.000 por open redirect no fluxo OAuth

O login OAuth tinha um parâmetro redirect_uri que aceitava qualquer URL. O caçador demonstrou que um atacante poderia criar um link que, após login bem-sucedido, redirecionaria o usuário (e seu token de autenticação) para um servidor controlado pelo atacante.

Técnica: Identificou fluxo OAuth, testou parâmetro redirect_uri com domínio externo. A cadeia de open redirect → roubo de token → tomada de conta elevou isso de P4 para P2.

Isso parece direto demais. Realmente paga?

Sim. IDOR é consistentemente a vulnerabilidade de API #1 porque está em todo lugar. Desenvolvedores têm que implementar verificações de autorização para cada endpoint - perca um e você tem um IDOR. Bugs diretos com impacto real pagam dinheiro real. Não complique sua abordagem - comece procurando por problemas óbvios. Conforme ganha experiência, você desenvolverá um olho para variações mais sutis.

E se eu só conseguir encontrar bugs de baixa severidade?

Bugs de baixa severidade ainda pagam, ainda constroem sua reputação, e ensinam como a aplicação funciona. Muitos caçadores encadeiam múltiplos bugs de baixa severidade para criar maior impacto. Um open redirect sozinho pode ser P4, mas encadeie com roubo de token OAuth e se torna P2. Encontrar P4s é como você aprende a encontrar P1s.

Como sei se um IDOR está no escopo?

Use duas contas que você controla - nunca acesse dados pertencentes a usuários reais. Seu teste deve ser: "A Conta A consegue acessar os dados da Conta B?" onde ambas as contas são suas. Se você encontrar um IDOR, reporte imediatamente. Não enumere dados de outros usuários ou baixe nada além do necessário para provar que o bug existe.

Meu relatório de open redirect foi fechado como "informativo". Por quê?

Muitos programas não pagam por open redirects sem impacto demonstrado. No seu relatório, explique o cenário de ataque: phishing, roubo de token OAuth ou bypass de controles de segurança. Se é usado em um fluxo OAuth, enfatize o potencial de roubo de token. Alguns programas ainda não vão aceitar - verifique a política deles antes de investir tempo.