Evitando duplicatas & N/A
Maximizando sua taxa de aceitação e minimizando esforço desperdiçado
O que você vai descobrir
🎯 Por que isso importa
Nada é mais frustrante do que passar horas em um bug só para receber "Duplicate" ou "Not Applicable". Entender por que relatórios são rejeitados ajuda você a caçar de forma mais inteligente. Os caçadores mais eficazes têm alto sinal (relatórios válidos) e baixo ruído (duplicatas/N/A).
🔍 O que você vai aprender
- Por que relatórios são marcados como duplicate
- Por que relatórios são marcados como N/A
- Estratégias para reduzir taxa de rejeição
- Quando caçar em programas novos vs estabelecidos
- Aprender com rejeições
🚀 Sua primeira vitória
Em 20 minutos, você terá estratégias para maximizar sua taxa de relatórios válidos.
Habilidades que você vai dominar
Seleção estratégica
Escolha programas onde você pode competir efetivamente
Avaliação de qualidade
Avalie descobertas antes de submeter
Análise de rejeição
Aprenda com feedback para melhorar relatórios futuros
Otimização de sinal
Construa uma forte relação válido/total de relatórios
Entendendo termos chave
Signal
Sua relação de relatórios aceitos (válidos) sobre o total submetido. Alto sinal significa que a maioria dos seus relatórios são válidos, não duplicatas ou N/A. Plataformas usam sinal para decidir convites de programas privados. Mire em 70%+ de sinal.
Duplicate
Alguém reportou a mesma vulnerabilidade antes de você. O primeiro a reportar recebe o crédito; relatórios subsequentes são marcados como duplicate. Duplicatas diminuem seu sinal mas são inevitáveis - o objetivo é minimizá-las.
N/A (Not Applicable)
O relatório não se qualifica como vulnerabilidade de segurança válida. Razões incluem: fora do escopo, sem impacto real, comportamento intencional, ou risco conhecido/aceito. N/A prejudica o sinal mais que duplicatas porque sugere incompreensão.
Valid/Resolved
O relatório foi aceito como problema de segurança legítimo. Pode ser triaged (confirmado), resolved (corrigido), ou awarded (pago). Relatórios válidos constroem seu sinal e reputação, levando a convites de programas privados.
🔧 Checklist pré-submissão
Pergunte a si mesmo essas questões antes de clicar em submeter:
# VERIFICAÇÃO DE ESCOPO
[ ] Este asset está explicitamente listado no escopo?
# Se o escopo diz "app.company.com" mas você encontrou o bug
# em "api.company.com", verifique se api também está no escopo
[ ] Este tipo de vulnerabilidade é aceito?
# Alguns programas excluem certos tipos de vulnerabilidades
# Verifique a seção "Exclusions" ou "Out of Scope"
# VERIFICAÇÃO DE IMPACTO
[ ] Eu demonstrei impacto de segurança real?
# "Header faltando" sozinho não é suficiente
# Mostre o que um atacante pode FAZER com isso
[ ] Consigo reproduzir isso de forma confiável?
# Se você não consegue reproduzir duas vezes, não submeta
[ ] Uma equipe de segurança razoável se importaria com isso?
# Pense da perspectiva deles - vale a pena corrigir?
# VERIFICAÇÃO DE QUALIDADE
[ ] Isso é uma CVE conhecida em uma dependência que eles controlam?
# "Seu servidor roda Apache 2.4.49" não é útil
# a menos que você possa explorar
[ ] A exploração requer interação de usuário irreal?
# "Usuário deve colar este payload de 500 caracteres" não vai funcionar
# Se QUALQUER resposta é "não" ou "incerto" - reconsidere submeter.Lembre-se: Um relatório válido vale mais que dez rejeitados. Proteja seu sinal.
Entendendo rejeições
"Cada rejeição é dado. Aprenda o porquê e adapte sua estratégia."
Por que relatórios são marcados duplicate
# RAZÕES COMUNS PARA DUPLICATAS
1. Programas populares atraem centenas de caçadores
# Os programas mais famosos (Google, Meta) têm milhares
# de pessoas testando. Bugs fáceis são encontrados imediatamente.
2. Bugs óbvios encontrados rapidamente após lançamento
# Quando um programa lança, caçadores experientes pulam nele
# e encontram bugs de superfície em horas.
3. Testando vulnerabilidades comuns em endpoints óbvios
# /login, /reset-password, /api/user - todo mundo testa isso
# O XSS na caixa de busca principal? Já foi encontrado.
4. Não ir fundo o suficiente na aplicação
# Testes de superfície encontram bugs de superfície (que outros encontraram)
# Testes profundos encontram bugs únicos que ainda estão lá.
# COMO REDUZIR DUPLICATAS
✓ Caçe em programas mais novos ou menos populares
# Novos programas não foram vasculhados ainda
# Plataformas menores (Intigriti) têm menos competição
✓ Teste funcionalidades menos óbvias
# Painéis admin, funcionalidades premium, casos extremos
# Funcionalidades que requerem configuração para testar
✓ Vá mais fundo em autenticação e lógica de negócio
# Esses bugs requerem entender a aplicação
# Automação não consegue encontrá-los, então há menos competição
✓ Não confie apenas em scanners automatizados
# Todo mundo roda os mesmos scanners
# Descobertas de scanner = alta taxa de duplicata
✓ Especialize-se em um nicho
# Apps mobile, APIs, stacks tecnológicos específicos
# Menos caçadores = menos duplicatasPor que relatórios são marcados N/A
# FORA DO ESCOPO
Testando *.company.com quando escopo diz apenas app.company.com
# Solução: Leia o escopo cuidadosamente antes de testar
Serviços de terceiros que a empresa não controla
# Zendesk, Intercom, serviços de analytics - não é código deles
# Solução: Verifique se o asset é realmente da empresa
Ambientes de staging/desenvolvimento explicitamente excluídos
# Frequentemente listados como fora do escopo por uma razão
# SEM IMPACTO REAL
Self-XSS (só afeta a pessoa que digita)
# Você não pode explorar ninguém mais - não é uma vulnerabilidade
Headers de segurança faltando sem exploit demonstrado
# "X-Frame-Options faltando" sozinho não é um bug
# Precisa mostrar clickjacking explorável em uma página sensível
Ataques teóricos sem prova
# "Um atacante poderia potencialmente..." - mostre o que você PODE fazer
# COMPORTAMENTO INTENCIONAL
"Bug" é na verdade uma funcionalidade documentada
# O que parece errado pode ser por design
# Verifique documentação antes de reportar
Rate limiting que parece fraco para você
# Se há ALGUM rate limiting, eles provavelmente consideraram
# Precisa mostrar bypass real, não "eu acho que deveria ser menor"
# RISCO CONHECIDO/ACEITO
Empresa está ciente e escolheu aceitar o risco
# Decisão de negócio deixar como está
# Nada que você possa fazer sobre issoEstratégias para aumentar aceitação
Seleção estratégica de alvo
# ESTRATÉGIAS BASEADAS EM TIMING
Novos programas (primeiros 30 dias)
Por quê: Menos competição, mais bugs não descobertos
Como: Filtre por data de lançamento, verifique seções "Novo"
Observe: Anúncios de plataforma para novos programas
Programas com atualizações recentes de escopo
Por quê: Novos assets = novo terreno de caça
Como: Siga programas, verifique anúncios
Observe: Notificações "Escopo expandido para incluir..."
Aplicações recentemente atualizadas
Por quê: Novo código = novos bugs
Como: Verifique blogs de empresas, changelogs, atualizações de app store
Observe: Anúncios de funcionalidades, atualizações de versão
# ESTRATÉGIAS BASEADAS EM PLATAFORMA
Plataformas menos populares
Por quê: Pool menor de pesquisadores = menos competição
Opções: Intigriti, YesWeHack, Synack
Tradeoff: Menos programas, mas menos lotado
Indústrias com menos hackers
Por quê: Saúde, finanças, varejo - menos "sexy" mas lucrativo
Bônus: Frequentemente têm práticas de segurança mais fracas
Nota: Pode requerer entendimento de compliance (HIPAA, etc.)Abordagem de teste
# VÁ ALÉM DO ÓBVIO
Teste apps mobile em vez de só web
Por quê: Menos caçadores testam mobile, mais descobertas únicas
Como: Configure proxy, intercepte tráfego do app, teste APIs
Foque em novas funcionalidades (verifique changelogs)
Por quê: Novo código não foi testado tão minuciosamente
Como: Siga blogs de engenharia de empresas, atualizações de app
Lógica de negócio ao invés de vulnerabilidades técnicas
Por quê: Scanners não conseguem encontrar, requer pensamento humano
Exemplos: Manipulação de preço, bypass de workflow, problemas de permissão
Testes de API (frequentemente negligenciado)
Por quê: APIs expõem funcionalidade sem proteções de UI
Como: Mapeie todos os endpoints, teste autorização em cada um
# TIMING DAS SUAS SUBMISSÕES
Reporte rapidamente quando encontrar algo sólido
Por quê: Cada hora de atraso aumenta risco de duplicata
Dica: Não espere pelo relatório "perfeito" se o bug é claro
Balance velocidade com qualidade
Por quê: Relatórios apressados são rejeitados por falta de detalhe
Dica: Inclua passos de reprodução e impacto, mesmo que breveAprendendo com rejeições
Análise de padrões de duplicatas
Se você está recebendo duplicatas em bugs óbvios (XSS na busca, IDOR em endpoints principais), você está testando muito amplamente e competindo com todo mundo. Solução: Vá mais fundo em menos alvos. Aprenda uma aplicação de dentro para fora. Teste funcionalidades que requerem configuração, contas premium ou estados específicos. Especialize-se em uma área que outros evitam.
Análise de padrões N/A
Leia razões de rejeição cuidadosamente. Foi escopo? Impacto? Comportamento intencional? Cada N/A ensina algo sobre o que conta como vulnerabilidade válida. Rastreie suas rejeições: Se você continua recebendo N/A por "headers faltando", pare de reportar headers faltando sem exploit demonstrado. Ajuste seu entendimento baseado no feedback.
Melhoria contínua
Mantenha um log de rejeições. Note a razão para cada duplicate/N/A. Procure padrões após 10-20 rejeições. Você tem consistentemente problemas de escopo? Problemas de impacto? Testa os mesmos tipos de bugs que todo mundo testa? Use esses dados para ajustar sua estratégia sistematicamente.
Perguntas frequentes
Devo contestar um duplicate/N/A?
Apenas se você genuinamente acredita que há um mal-entendido. Forneça evidência adicional educadamente: "Gostaria de clarificar o impacto..." Não argumente agressivamente - danifica sua reputação e desperdiça tempo de todos. A maioria das rejeições está correta. Aceite-as graciosamente e aprenda com o feedback.
Qual é uma boa taxa de aceitação?
Top caçadores miram em 70%+ relatórios válidos. Se você está abaixo de 50%, está submetendo muitos relatórios de baixa qualidade. Qualidade sobre quantidade - menos relatórios, melhor validados são mais efetivos para sua reputação, seus ganhos e seu aprendizado. Um P2 sólido vale mais que cinco relatórios N/A.
Como verifico se um bug pode ser duplicata antes de submeter?
Você não pode saber definitivamente, mas pode estimar: É um bug óbvio em um endpoint principal? Foi encontrado por um scanner comum? O programa está rodando há anos? Se sim para todas, risco de duplicata é alto. Considere se vale investir tempo em um relatório melhor ou seguir em frente. Quanto mais única sua abordagem de teste, menor sua taxa de duplicata.
Vale a pena caçar em programas muito populares?
Sim, mas com uma estratégia diferente. Programas populares pagam bem e têm escopo amplo, mas bugs de superfície já foram. Sucesso requer testes profundos: entender sua stack tecnológica específica, encontrar bugs em lógica de negócio, testar casos extremos que outros perdem. Se você está disposto a investir o tempo para aprender uma aplicação profundamente, programas populares podem ser lucrativos.
🎯 Você pode maximizar aceitação!
Seleção estratégica de alvo, verificações pré-submissão minuciosas e aprendizado com feedback - você agora tem as ferramentas para minimizar esforço desperdiçado e maximizar descobertas válidas. Lembre-se: sinal importa mais que volume.
Pronto para automatizar e escalar sua caça