Escolhendo seu primeiro programa de bug bounty

O programa que você escolhe decide se o seu primeiro mês rende ou se escorre em alvos que você não pode testar. Este post é sobre ler bem um escopo, com um modelo de IA fazendo a primeira passada e você dando a palavra final. Ele segue o loop e alimenta a montagem do toolkit.

#O que é um programa

Um programa de bug bounty é uma oferta pública. Uma organização nomeia os alvos que quer ver testados, define as regras para testá-los e fixa recompensas por relatórios válidos. A política é o contrato. Tudo o que você faz fica dentro do que ela lista, e um relatório que sai disso é fechado por melhor que seja o bug. Alguns sites também publicam um arquivo security.txt em /.well-known/security.txt com um contato e um link de política, que diz para onde vão os relatórios.

#Dentro e fora do escopo

Toda política divide o mundo em alvos que você pode testar e alvos que não pode. O escopo costuma ser um conjunto de domínios, domínios com wildcard, apps mobile ou APIs. Fora do escopo é o resto, e muitas vezes inclui serviços de terceiros que a organização usa mas não é dona. A lista do que está fora importa mais que a do que está dentro para quem começa, porque é ali que os acidentes acontecem. Um wildcard como *.example.com ainda pode excluir hosts específicos, então leia as duas listas juntas.

#As regras que fecham relatórios

Além das listas de alvos, uma política define regras de engajamento: limites de rate, se scan automatizado é permitido, quais classes de bug não pagam e o que você pode fazer com qualquer dado que alcançar. Classes comuns fora do escopo para iniciantes são self-XSS, cabeçalhos de segurança ausentes sem exploit, e relatórios de scanners automáticos sem prova manual. As regras de engajamento do bug bounty explicam isso por inteiro.

#Leia um escopo com o modelo, depois confira

Cole a política em um chat e peça três listas: alvos no escopo, alvos fora do escopo e regras que fariam um relatório ser fechado. O modelo é bom nesse trabalho de leitura. Ele também é capaz de deixar cair um host ou inventar uma regra, então você lê a política você mesmo depois e corrige as listas dele. O ponto do modelo aqui é velocidade em uma tarefa chata, não um veredito em que você confia de olhos fechados.

Sinal	Mais fácil para começar	Começo mais difícil
Tamanho do escopo	Poucos domínios claros	Grande propriedade com wildcard
Maturidade	Programa novo, menos hunters	Programa maduro, já garimpado
Regras	Scan permitido, classes claras	Rate limit apertado, muitas exclusões
Alvos	Um web app que você roda local também	Hardware ou apps só nativos

#Escolha um alvo que você consiga testar de verdade

Um programa pode listar dez alvos sendo que só dois servem para a sua habilidade. Como iniciante, escolha uma aplicação web que você também consiga estudar na sua própria máquina, para aprender o comportamento dela sem mandar tráfego ao alvo ao vivo a cada pergunta. Se o programa oferece um build self-hosted ou de demonstração, rode esse local e guarde o host ao vivo para confirmar um bug. Isso mantém baixa a sua contagem de requests no alvo real, o que respeita as regras de rate e deixa um registro mais limpo.

#Registre o escopo antes de tocar nele

Anote o escopo em algum lugar que suas ferramentas possam conferir, não só na sua memória. A CLI da NotHoly guarda o escopo de uma rodada com notholy engage, e lê o alvo de cada comando antes dele rodar, de modo que um host fora do escopo pede uma segunda confirmação. O post do toolkit monta isso. Registrar o escopo transforma uma regra que você tem que lembrar em uma checagem que o terminal faz por você.

#Escolhendo a plataforma

Programas vivem em plataformas de bounty e em páginas de empresa achadas por security.txt ou por uma página /security. Programas públicos aceitam qualquer um. Os privados vêm por convite depois que você constrói um histórico. Comece público, leia algumas políticas com o modelo para pegar o jeito de como elas diferem, e fique em um programa tempo suficiente para aprender bem a aplicação dele.

#A seguir nesta trilha

Com um programa e um alvo em mãos, monte o toolkit e o terminal. Mantenha o OWASP Web Security Testing Guide e os termos da disclose.io por perto como referência do que é um teste de boa-fé.