Construindo sua metodologia

Uma abordagem sistemática para encontrar vulnerabilidades de forma consistente

O que você vai descobrir

Habilidades que você vai dominar

🔧 Sua checklist de testes (com explicações)

Use isso para cada funcionalidade que você testar. Cada item é explicado para que você entenda o que está procurando:

# CHECKLIST DE TESTES FUNDAMENTAIS

[ ] Authentication Bypass
    # Você consegue acessar páginas protegidas sem fazer login?
    # Tente remover tokens de auth, manipular cookies
    # O que acontece se você visitar /admin diretamente?

[ ] IDOR/BOLA (mudar IDs em todos os parâmetros)
    # IDOR = Insecure Direct Object Reference
    # BOLA = Broken Object Level Authorization (termo de API)
    # Ambos significam a mesma coisa: mudar IDs para acessar
    # dados de outros usuários (pedidos, perfis, documentos)

[ ] Authorization (acessar dados de outros usuários)
    # Diferente de autenticação - você está logado
    # mas consegue fazer coisas que não deveria?
    # Usuário A acessando dados privados do Usuário B

[ ] XSS (reflected, stored, DOM)
    # Você consegue injetar JavaScript que executa?
    # Reflected: Em parâmetros de URL, aparece na resposta
    # Stored: No banco de dados, afeta outros usuários
    # DOM: JS do lado do cliente manipula sua entrada de forma insegura

[ ] SQL Injection
    # Queries de banco de dados construídas com sua entrada
    # Teste: ' OR 1=1-- , sleep(5), payloads baseados em erro
    # Sinais: Erros de banco de dados, atrasos, comportamento diferente

[ ] CSRF (ações que mudam estado)
    # Cross-Site Request Forgery
    # Você consegue enganar um usuário logado para tomar ações?
    # Tokens CSRF ausentes em mudança de senha, email, etc.

[ ] Open Redirect
    # Parâmetro de URL controla para onde usuários vão
    # /redirect?url=https://evil.com
    # Útil para phishing, roubo de token OAuth

[ ] Information Disclosure
    # Dados sensíveis expostos: chaves de API, IPs internos
    # Endpoints de debug, mensagens de erro verbosas, pastas .git
    # Verificar /robots.txt, /sitemap.xml para caminhos ocultos

[ ] Rate Limiting (em funções sensíveis)
    # Sem limite em tentativas de login = brute force possível
    # Sem limite em reset de senha = enumeração de contas
    # Sem limite em verificação de OTP = bypass de 2FA

[ ] Business Logic Flaws
    # Vulnerabilidades específicas da aplicação
    # Comprar quantidades negativas, pular etapas no checkout
    # Aplicar códigos de desconto múltiplas vezes

Salve isso: Marque cada caixa para cada funcionalidade. Consistência encontra bugs que testes aleatórios perdem.

Por que a metodologia funciona

Duas abordagens de teste

Testes baseados em funcionalidades

Escolha uma funcionalidade, teste cada tipo de vulnerabilidade nela antes de seguir em frente. Essa abordagem ajuda você a entender a aplicação profundamente.

# TESTES BASEADOS EM FUNCIONALIDADES
# Exemplo: Funcionalidade de perfil de usuário

PASSO 1: Mapear todos os endpoints relacionados a perfis
  GET  /api/users/me          # Seu próprio perfil
  GET  /api/users/{id}        # Perfil de qualquer usuário
  PUT  /api/users/me          # Atualizar seu perfil
  POST /api/users/me/avatar   # Upload de foto de perfil
  GET  /api/users/me/settings # Configurações da conta

PASSO 2: Executar sua checklist nesta funcionalidade
  [x] IDOR: Consigo GET /api/users/OUTRO_ID_USUARIO?
  [x] IDOR: Consigo PUT para /api/users/OUTRO_ID_USUARIO?
  [x] XSS: Injetar payloads nos campos nome, bio, localização
  [x] Mass Assignment: Adicionar "role": "admin" na requisição PUT
  [x] File Upload: O que acontece com .php, .svg, arquivos enormes?
  [x] Info Disclosure: A resposta inclui campos sensíveis?

PASSO 3: Mover para a próxima funcionalidade
  Agora testar: pagamentos, mensagens, configurações, etc.

POR QUE FUNCIONA:
- Entendimento profundo de uma área antes de seguir em frente
- Encontra bugs complexos que abrangem múltiplos endpoints
- Constrói modelo mental de como a funcionalidade funciona

Testes baseados em vulnerabilidades

Escolha um tipo de vulnerabilidade, teste cada funcionalidade para ela. Essa abordagem é eficiente para cobertura sistemática.

# TESTES BASEADOS EM VULNERABILIDADES
# Exemplo: Testando IDOR em toda a aplicação

PASSO 1: Encontrar todos os endpoints com IDs
  /api/orders/{id}
  /api/documents/{id}
  /api/invoices/{id}
  /api/users/{id}/data
  /api/messages/{id}
  /api/projects/{id}

PASSO 2: Testar IDOR em cada um sistematicamente
  Requisitos:
  - Criar 2 contas (Conta A e Conta B)
  - Criar recursos em ambas as contas

  Testar cada endpoint:
  - A Conta A consegue acessar os pedidos da Conta B?
  - A Conta A consegue modificar os documentos da Conta B?
  - Testar métodos GET, PUT, PATCH, DELETE
  - Verificar tanto IDs numéricos quanto UUIDs

PASSO 3: Mover para o próximo tipo de vulnerabilidade
  Agora testar: XSS em todo lugar, depois CSRF em todo lugar, etc.

POR QUE FUNCIONA:
- Eficiente para uma classe de vulnerabilidade específica
- Você entra no "modo caça IDOR" - reconhecimento de padrões
- Fácil de rastrear: "Testei todos os IDOR, movendo para XSS"

Áreas de alto impacto para priorizar

Nem todas as funcionalidades são iguais. Essas áreas têm a maior probabilidade de vulnerabilidades críticas e os maiores pagamentos:

# ORDEM DE TESTES PRIORIZADA (maior impacto primeiro)

1. Fluxos de autenticação/login
   Por quê: Tomada de conta = Severidade crítica
   Testar: Reset de senha, OAuth, gerenciamento de sessão

2. Funcionalidade de reset de senha
   Por quê: Frequentemente tem vazamento de token, enumeração, bypass
   Testar: Token na URL, tokens fracos, sem rate limiting

3. Funcionalidades de pagamento/financeiras
   Por quê: Impacto financeiro direto, sempre alta severidade
   Testar: Manipulação de preço, IDOR em transações

4. Painéis de admin/configurações
   Por quê: Potencial de escalação de privilégios
   Testar: Usuários normais conseguem acessar endpoints de admin?

5. Funções de upload de arquivo
   Por quê: Pode levar a RCE, stored XSS, path traversal
   Testar: Bypass de extensão, manipulação de content-type

6. Endpoints de API com IDs de usuário
   Por quê: Mina de ouro de IDOR - desenvolvedores esquecem verificações de auth
   Testar: Cada endpoint que recebe um parâmetro ID

7. Funcionalidades de export/download
   Por quê: Frequentemente vazam dados sensíveis, potencial de SSRF
   Testar: Quais dados estão incluídos? Você consegue exportar dados de outros?

8. Sistemas de convite/compartilhamento
   Por quê: Complexidade de controle de acesso = bugs
   Testar: Você consegue escalar permissões compartilhadas?

9. Integrações OAuth
   Por quê: Vazamento de token, problemas de vinculação de conta
   Testar: Manipulação de redirect_uri, parâmetro state

10. Funcionalidades recém-lançadas
    Por quê: Menos testadas, maior densidade de bugs
    Onde: Verificar changelogs, posts de blog, atualizações do app

Rastreando seu progresso

Boas anotações separam caçadores eficazes de todos os outros. Quando você retorna a um alvo meses depois, suas anotações dizem exatamente o que você fez e o que resta.

Template de anotações

# Alvo: company.com
# Data de início: 2024-01-15
# Última atualização: 2024-01-22

## Stack técnica (descoberta durante recon)
- Backend: Ruby on Rails (header X-Powered-By)
- Banco de dados: PostgreSQL (mensagens de erro)
- Frontend: React (padrões no código fonte)
- CDN: Cloudflare

## Funcionalidades testadas
- [x] Registro de usuário
- [x] Login/autenticação
- [x] Reset de senha
- [ ] Perfis de usuário
- [ ] Sistema de pagamento
- [ ] Endpoints da API v2 (recém-descobertos)

## Descobertas interessantes (ainda não reportadas)
- Página de perfil retorna email em JSON mesmo para outros usuários
- Token de reset de senha aparece na URL (vazamento potencial via Referer)
- Endpoint de debug em /api/debug retorna stack traces
- Rate limiting contornado com header X-Forwarded-For

## Bugs reportados
- #12345: IDOR em /api/orders/{id} (P2) - $500 - Resolvido
- #12346: Stored XSS no campo bio (P3) - Aguardando triagem

## Para investigar
- [ ] Verificar se tokens de reset de senha são advinháveis
- [ ] Testar upload de arquivo em fotos de perfil
- [ ] Enumerar endpoints /api/v2/ (encontrados no JS)
- [ ] Verificar painel de admin em /internal/ (referenciado em comentário HTML)

## Notas
- Empresa usa Stripe para pagamentos - escopo limitado lá
- App mobile usa a mesma API - testar via proxy

Perguntas frequentes

🎯 Você tem uma metodologia!

Você agora tem uma abordagem estruturada para testes: uma checklist abrangente com explicações, duas estratégias de teste, orientação de priorização e um sistema de rastreamento. Metodologia consistente produz resultados consistentes.

Pronto para aprender vulnerabilidades de vitória rápida