Security Bounty Hunter
Use isto quando o objetivo é a descoberta prática de vulnerabilidades para divulgação responsável ou submissão em programas de recompensa, e não uma revisão ampla de boas práticas.
Quando Usar
- Escaneando um repositório em busca de vulnerabilidades exploráveis
- Preparando uma submissão para Huntr, HackerOne ou similar
- Triage onde a pergunta é "isso realmente paga?" em vez de "isso é teoricamente inseguro?"
Como Funciona
Pendendo para caminhos de ataque remotamente acessíveis e controlados pelo usuário, descartando padrões que as plataformas rejeitam rotineiramente como informativos ou fora do escopo.
Padrões no Escopo
Estes são os tipos de problemas que consistentemente importam:
| Padrão | CWE | Impacto Típico |
|---|---|---|
| SSRF através de URLs controladas pelo usuário | CWE-918 | Acesso a rede interna, roubo de metadados da nuvem |
| Bypass de autenticação em middleware ou guardiões de API | CWE-287 | Acesso não autorizado a contas ou dados |
| Desserialização remota ou caminhos upload-to-RCE | CWE-502 | Execução de código |
| Injeção SQL em endpoints acessíveis | CWE-89 | Exfiltração de dados, bypass de autenticação, destruição de dados |
| Injeção de comando em handlers de requisição | CWE-78 | Execução de código |
| Path traversal em caminhos de serviço de arquivos | CWE-22 | Leitura ou escrita arbitrária de arquivos |
| XSS de disparo automático | CWE-79 | Roubo de sessão, comprometimento de administrador |
Pule Estes
Estes geralmente são de baixo sinal ou fora do escopo de bounty, a menos que o programa diga o contrário:
pickle.loads,torch.loadou equivalentes locais sem caminho remotoeval()ouexec()em ferramentas somente CLIshell=Trueem comandos totalmente hardcoded- Cabeçalhos de segurança ausentes por si só
- Reclamações genéricas de limitação de taxa sem impacto de exploração
- XSS autoaplicável que exige que a vítima cole código manualmente
- Injeção CI/CD que não faz parte do escopo do programa alvo
- Código de demonstração, exemplo ou apenas de teste
Fluxo de Trabalho
- Verifique o escopo primeiro: regras do programa, SECURITY.md, canal de divulgação e exclusões.
- Encontre pontos de entrada reais: handlers HTTP, uploads, jobs em background, webhooks, parsers e endpoints de integração.
- Execute ferramentas estáticas onde for útil, mas trate apenas como entrada de triagem.
- Leia o caminho real do código de ponta a ponta.
- Prove que o controle do usuário alcança um sink significativo.
- Confirme a explotabilidade e o impacto com o menor PoC seguro possível.
- Verifique duplicatas antes de redigir um relatório.
Exemplo de Loop de Triage
semgrep --config=auto --severity=ERROR --severity=WARNING --json
Em seguida, filtre manualmente:
- descarte testes, demonstrações, fixtures, código fornecido por terceiros
- descarte caminhos locais ou não acessíveis
- mantenha apenas descobertas com uma rota clara de rede ou controle do usuário
Estrutura do Relatório
## Descrição
[O que é a vulnerabilidade e por que é importante]
## Código Vulnerável
[Caminho do arquivo, intervalo de linhas e um pequeno trecho]
## Prova de Conceito
[Solicitação ou script mínimo funcional]
## Impacto
[O que o atacante pode alcançar]
## Versão Afetada
[Versão, commit ou alvo de implantação testado]
Portão de Qualidade
Antes de submeter:
- O caminho do código é acessível a partir de um usuário real ou limite de rede
- A entrada é genuinamente controlada pelo usuário
- O sink é significativo e explorável
- O PoC funciona
- O problema já não está coberto por um advisory, CVE ou ticket aberto
- O alvo está realmente no escopo do programa de recompensa