Security Bounty Hunter
Use isso quando o objetivo é descoberta prática de vulnerabilidades para divulgação responsável ou submissão 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
- Triagem onde a pergunta é "isso realmente paga?" em vez de "isso é teoricamente inseguro?"
Como Funciona
Tende a favorecer caminhos de ataque acessíveis remotamente e controlados pelo usuário, descartando padrões que as plataformas rejeitam rotineiramente como informativos ou fora de 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 à rede interna, roubo de metadados da nuvem |
| Bypass de autenticação em middleware ou guardas de API | CWE-287 | acesso não autorizado a contas ou dados |
| Desserialização remota ou caminhos de upload para RCE | CWE-502 | execução de código |
| Injeção de SQL em endpoints acessíveis | CWE-89 | exfiltração de dados, bypass de autenticação, destruição de dados |
| Injeção de comando em manipuladores 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 acionado automaticamente | CWE-79 | roubo de sessão, comprometimento do admin |
Pule Estes
Estes geralmente são de baixo sinal ou fora do escopo do bounty, a menos que o programa diga o contrário:
pickle.loads,torch.loadou equivalente apenas local, sem caminho remotoeval()ouexec()em ferramentas apenas de linha de comandoshell=Trueem comandos totalmente hardcoded- Ausência de cabeçalhos de segurança por si só
- Reclamações genéricas de limitação de taxa sem impacto de exploração
- Self-XSS que exige que a vítima cole código manualmente
- Injeção em 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: manipuladores HTTP, uploads, jobs em segundo plano, webhooks, parsers e endpoints de integração.
- Execute ferramentas estáticas onde ajudarem, mas trate como apenas 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 explorabilidade e o impacto com o menor PoC seguro possível.
- Verifique duplicatas antes de redigir um relatório.
Exemplo de Loop de Triagem
semgrep --config=auto --severity=ERROR --severity=WARNING --json
Então filtre manualmente:
- descarte testes, demonstrações, fixtures, código vendido
- descarte caminhos apenas locais ou não acessíveis
- mantenha apenas achados com uma rota clara de rede ou controle do usuário
Estrutura do Relatório
## Descrição
[O que é a vulnerabilidade e por que ela importa]
## Código Vulnerável
[Caminho do arquivo, intervalo de linhas e um pequeno trecho]
## Prova de Conceito
[Solicitação ou script funcional mínimo]
## 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 não está já coberto por um advisory, CVE ou ticket aberto
- O alvo está realmente no escopo do programa de bounty