O que Todo Dev Deve Saber sobre Burp Suite em Profundidade: Proxy, Scanner, Intruder e Repeater Já leu

Introdução ao Burp Suite: Ferramenta Fundamental em Segurança Ofensiva

O Burp Suite é uma plataforma de testes de penetração web construída em Java que se tornou o padrão da indústria para profissionais de segurança ofensiva. Sua arquitetura modular permite análise profunda de aplicações web através de diferentes perspectivas de ataque, desde reconhecimento passivo até exploração ativa de vulnerabilidades. Quando você domina o Burp Suite, não está apenas aprendendo uma ferramenta, mas desenvolvendo a capacidade de compreender como uma aplicação web funciona em camadas de protocolo, autenticação, validação e processamento de dados.

A ferramenta funciona como intermediária (proxy) entre seu navegador e o servidor web, capturando e permitindo manipulação de requisições HTTP/HTTPS em tempo real. Este artigo pressupõe que você já possui conhecimento básico de HTTP, requisições GET/POST e conceitos elementares de segurança web. Focaremos em profundidade nos quatro módulos mais críticos: Proxy, Scanner, Intruder e Repeater, explicando não apenas como usá-los, mas quando e por que utilizá-los em um engagement real.

Módulo Proxy: A Base de Toda Análise

Entendendo o Proxy como Intermediário

O módulo Proxy do Burp Suite atua como um man-in-the-middle controlado por você. Quando configurado corretamente, ele intercepta toda comunicação entre seu navegador e o servidor, permitindo visualizar exatamente o que é enviado e recebido. Este é o ponto de partida essencial porque você não pode testar o que não consegue ver. Diferentemente de ferramentas que apenas capturam logs, o Proxy permite modificação em tempo real, transformando qualquer requisição antes de ela chegar ao servidor.

A configuração básica envolve três etapas: gerar um certificado CA no Burp, instalar este certificado no navegador e configurar o navegador para usar o Burp como proxy HTTP/HTTPS. Sem completar estas etapas, você não conseguirá interceptar requisições HTTPS criptografadas. Na prática profissional, você frequentemente trabalha com múltiplos navegadores, ambientes isolados e até máquinas virtuais, então dominar essa configuração evita horas de frustração.

Configuração Prática do Proxy

Para configurar o Burp Suite corretamente:

1. Abra Burp → Proxy → Options → Proxy Listeners
2. Verifique se há um listener ativo em 127.0.0.1:8080 (padrão)
3. Acesse Burp → Settings → Tools → TLS Pass Through para aplicações que precisam de conexão direta

No navegador Firefox (recomendado para testes):

Configurações → Rede → Definições de proxy → Manual:
HTTP Proxy: 127.0.0.1
Porta: 8080

Instale o certificado CA:
1. Navegue até http://burp/cert
2. Baixe cacert.der
3. Em Preferências → Privacidade → Certificados → Importar
4. Selecione "Confiar em autoridades certificadoras para identificar sites"

Uma vez configurado, quando você abre uma página web, toda requisição é capturada na aba "HTTP history" do Proxy. Você verá GET requests, POST data, cookies, headers customizados—tudo. Esta visibilidade é crucial porque muitas vulnerabilidades existem justamente nos dados que o navegador normalmente oculta do usuário.

Interceptação e Manipulação em Tempo Real

O recurso "Intercept" permite pausar requisições antes de enviá-las. Imagine que você está testando um sistema de login: você digita credenciais, pressiona Enter, e a requisição é interceptada. Antes de enviá-la, você pode modificar o username, adicionar parâmetros, mudar headers ou até injetar payloads de teste. Esta é a base de praticamente qualquer teste manual efetivo.

Exemplo prático - Modificação de requisição POST:

POST /login HTTP/1.1
Host: alvo.com.br
Content-Type: application/x-www-form-urlencoded
Content-Length: 45

username=admin&password=teste&remember=false

# Você intercepta e modifica para:
username=admin' OR '1'='1&password=x&remember=true&admin=1

# Isto testa SQL injection e parâmetros ocultos simultaneamente

A aba "Proxy" possui dois modos críticos: "Intercept is on" para capturar requisições específicas e "Intercept is off" para apenas registrar tráfego. Profissionais frequentemente começam com intercept desligado, navegam o aplicativo normalmente e capturam uma linha de base do comportamento. Depois, ligam intercept seletivamente quando querem modificar requisições específicas. Este é um padrão de trabalho muito mais eficiente que interceptar absolutamente tudo desde o início.

Módulo Scanner: Automatização Inteligente de Detecção

Filosofia e Limitações do Scanner Automático

O Scanner do Burp Suite realiza testes automáticos procurando por vulnerabilidades conhecidas através de injeção de payloads, análise de respostas e reconhecimento de padrões. É importante entender desde o início que scanners automáticos não substituem testes manuais—eles aumentam a produtividade encontrando vulnerabilidades óbvias enquanto você se concentra em lógica de negócio, fluxos complexos e vulnerabilidades contextuais. Um scanner nunca descobrirá um broken access control que existe em um fluxo específico de autorização porque scanners não "entendem" lógica de negócio.

A qualidade das descobertas do Scanner está diretamente ligada a quanto da aplicação ele consegue explorar durante a análise. Se você o aponta para uma página de login sem estar autenticado, ele testará apenas parâmetros públicos. Se você autenticar primeiro e capturar cookies válidos, o Scanner consegue navegar por áreas protegidas e testar muito mais superfícies de ataque. Este é um conceito crítico: preparar o ambiente para o Scanner é tão importante quanto executá-lo.

Configuração e Execução do Scanner

Existem dois modos no Scanner: "Active Scan" e "Passive Scan". O Passive Scan analisa requisições que você capturou sem enviar payloads adicionais, procurando por padrões em respostas existentes. É completamente seguro e rápido. O Active Scan, por outro lado, injeta payloads reais de teste para verificar se o servidor é vulnerável—é mais invasivo e pode disparar sistemas de detecção.

Para iniciar um Active Scan sobre uma requisição específica:

1. Capture a requisição desejada no Proxy
2. Clique com botão direito na requisição → "Do active scan"
3. Configure o Scan Configuration:
   - Audit Scope: Define quais testes executar
   - Request Headers: Se a aplicação usa headers customizados
   - Crawl Optimization: Quanto explorar vs. Quanto testar
4. Inicie o scan

Um exemplo prático—você está testando um formulário de busca em /search?q=termo. O Scanner:

POST /search?q=termo HTTP/1.1

# Scanner testa automaticamente:
/search?q=' (SQL injection)
/search?q=<script>alert(1)</script> (XSS)
/search?q=../../../etc/passwd (Path traversal)
/search?q=${7*7} (Template injection)
/search?q=union select null-- (SQL injection avançado)

Para cada teste, analisa a resposta procurando por sinais de vulnerabilidade: tempo de resposta anormalmente longo (SQL time-based), tags script refletidas (XSS), arquivo encontrado (Path traversal), ou cálculo executado (Template injection).

Interpretação Correta de Resultados

O Scanner retorna resultados com níveis de severidade: High, Medium, Low e Information. Nem todo resultado é um falso positivo, mas muitos são. Uma XSS refletida que requer JavaScript ativo e está dentro de um atributo de aspas duplas pode não ser explorada realistically. Um SQLi time-based detectado em um parâmetro que só aceita números inteiros é provavelmente um falso positivo. Você precisa verificar manualmente cada descoberta.

Ao revisar resultados, procure por:

• Vulnerability details: Descrição técnica do que foi encontrado
• Request: Exatamente qual requisição detectou a vulnerabilidade
• Response: Qual foi a resposta que indicou a vulnerabilidade
• Evidence: Você consegue reproduzir manualmente?

Profissionais raros confiam 100% em resultados de Scanner. A prática padrão é: Scanner encontra potencial → Você verifica manualmente com Repeater ou Intruder → Você confirma se é exploração real → Você documenta no relatório.

Módulo Intruder: Testes Parametrizados em Escala

Conceito de Fuzzing Posicionado

O Intruder é essencialmente uma ferramenta de fuzzing (envio de dados variados) com controle fino sobre quais partes da requisição são modificadas. Enquanto o Scanner testa vulnerabilidades conhecidas com payloads pré-definidos, o Intruder permite testar hipóteses customizadas: "E se eu testar mil senhas diferentes?" ou "E se cada parâmetro receber este conjunto de valores XSS?" Isto é especialmente poderoso para:

• Testes de força bruta de credenciais
• Enumeração de parâmetros (descobrir quais campos existem)
• Fuzzing de entrada (testar múltiplos tipos de dados)
• Bypass de validação (testar padrões de validação fraca)
• Teste de lógica de negócio com valores variados

O Intruder funciona através de "payloads"—listas ou geradores de dados que serão inseridos em posições específicas da requisição. Você marca com § os pontos de variação, define quantas requisições serão enviadas e em qual padrão.

Configuração Prática e Attack Types

Para usar o Intruder:

1. Capture a requisição no Proxy
2. Clique direito → "Send to Intruder"
3. Na aba Positions, marque com § os campos variáveis
4. Selecione o Attack Type apropriado
5. Configure Payloads (dados para testar)
6. Inicie o ataque

Os principais Attack Types são:

Sniper: Um único payload set, testado em cada posição marcada sequencialmente. Use para teste simples.

Requisição: username=§admin§&password=§test§

Com payload [user1, user2, user3]:

1. username=user1&password=test
2. username=admin&password=user1
3. username=admin&password=user2
4. username=admin&password=user3

Battering Ram: Um único payload set, mas insere o mesmo valor em todas as posições simultaneamente.

Requisição: username=§admin§&password=§test§

Com payload [crack, attack, exploit]:

1. username=crack&password=crack
2. username=attack&password=attack
3. username=exploit&password=exploit

Pitchfork: Múltiplos payload sets, sincronizados por posição. Uso mais avançado e realista.

Requisição: username=§user§&password=§pass§

Payload 1: [admin, user, guest]
Payload 2: [admin123, user123, guest123]

1. username=admin&password=admin123
2. username=user&password=user123
3. username=guest&password=guest123

Cluster Bomb: Teste todas as combinações possíveis entre múltiplos payload sets. Cuidado—cresce exponencialmente!

Requisição: username=§user§&password=§pass§

Payload 1: [admin, user] (2 valores)
Payload 2: [123, 456, 789] (3 valores)

Resultado: 2 × 3 = 6 combinações diferentes

Exemplo Real de Fuzzing de Parâmetro

Imagine um endpoint /api/user/§id§ onde você quer descobrir quais IDs de usuário existem:

GET /api/user/1 HTTP/1.1
Host: alvo.com.br
Authorization: Bearer token_valido

# Marcar como: GET /api/user/§1§

Payload Set: números de 1 a 1000 (Intruder oferece geradores)
Attack Type: Sniper

Resultados esperados:
/api/user/1  → 200 OK (usuário existe)
/api/user/2  → 200 OK (usuário existe)
/api/user/3  → 404 Not Found (não existe)
/api/user/4  → 403 Forbidden (existe mas você não tem acesso)

Ao executar, você procura por padrões nas respostas: status code diferente, tamanho de resposta variável, tempo de resposta anomal. O Intruder mostra uma tabela com todas as respostas, permitindo ordenar e filtrar. Isto revela rapidamente quais IDs são válidos versus inválidos, quebrando a enumeração de recurso.

Módulo Repeater: Testes Manuais Precisos

Por Que o Repeater É Indispensável

O Repeater é a ferramenta mais subestimada do Burp Suite porque sua simplicidade esconde seu poder. Ele faz uma coisa: permite enviar uma requisição HTTP exatamente como você quer, quantas vezes você quiser, visualizando a resposta completa. Isto parece óbvio, mas é precisamente isto que você precisa para validação manual, debugging de descobertas do Scanner e testes de lógica complexa onde parametrização automática é inadequada.

A razão pela qual você usa Repeater em vez de apenas digitar curl é porque você está dentro do Burp Suite, mantendo contexto—cookies válidos já estão ali, histórico de requisições anteriores está disponível, você pode facilmente acessar dados capturados de outras abas. Repeater transforma Burp de uma ferramenta de captura em um ambiente de desenvolvimento para exploração.

Workflow Essencial com Repeater

O padrão de trabalho profissional é: você captura uma requisição interessante no Proxy, a envia para Repeater, a modifica, a envia, observa a resposta, itera. Este ciclo é muito mais rápido que recarregar o navegador ou construir requisições manuais.

Fluxo prático:

1. No Proxy, clique direito em uma requisição → Send to Repeater
2. Na aba Repeater, a requisição aparece no painel esquerdo:

POST /transfer HTTP/1.1
Host: bank.local
Content-Type: application/json
Authorization: Bearer eyJ0eXAi...

{
  "from_account": "1001",
  "to_account": "2002", 
  "amount": 100.00
}

3. Você modifica o amount para 1000000.00 e clica "Send"
4. A resposta aparece no painel direito:

HTTP/1.1 403 Forbidden
Content-Type: application/json

{"error": "Transfer limit exceeded", "limit": 5000}

5. Você tenta com 5000, envia, observa: 200 OK, transferência aceita
6. Documentas: broken access control ou lógica de validação inadequada

Um exemplo mais técnico—você testa XXE (XML External Entity) injection:

POST /xml/upload HTTP/1.1
Host: alvo.com.br
Content-Type: application/xml

<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<request>
  <action>&xxe;</action>
</request>

# Repeater permite enviar isto e imediatamente ver se o arquivo foi lido
# Você não precisa reconfigurar o navegador ou curl, apenas modificar XML

Recursos Avançados do Repeater

Tabs Múltiplas: Você pode ter várias requisições em Repeater simultaneamente, útil para comparar diferentes endpoints ou payloads.

Request/Response View Options: Procure por botões que permitem visualizar as respostas em HTML renderizado, formatado em JSON, ou bruto. Isto ajuda a entender respostas complexas.

Compare Responses: Selecione duas respostas e clique "Compare"—Burp destaca as diferenças lado a lado. Isto revela o que mudou entre duas solicitações, fundamental para entender validação ou lógica de autorização.

Exemplo:

Requisição 1: GET /admin → Response (vazia ou acesso negado)
Requisição 2: GET /admin (com cookie de admin) → Response (painel completo)

Diferenças visíveis:
- Tamanho da resposta: 150 bytes vs 15000 bytes
- Status code: 403 vs 200
- Headers: diferentes valores de Set-Cookie

Uma capacidade frequentemente ignorada é Render tabs—em Repeater, existe uma aba separada que renderiza a resposta HTML. Se você está testando XSS, ao invés de ler HTML bruto, você vê o DOM renderizado e pode testar interações.

Práticas Profissionais Integradas

Fluxo de Teste Completo: Integração dos Módulos

Um engagement real não usa estes módulos isoladamente. O fluxo padrão é:

1. Reconnaissance (Proxy): Você navega a aplicação com Intercept desligado, capturando todas as requisições e entendendo como funciona.

2. Passive Analysis (Proxy + Scanner Passive): Você executa Passive Scan sobre o histórico capturado, procurando problemas óbvios como headers de segurança faltando ou versões de servidor expostas.

3. Active Scanning Direcionado (Scanner): Você inicia Active Scan em pontos críticos: formulários de entrada, endpoints de autenticação, funcionalidades que manipulam dados.

4. Validação Manual (Repeater): Para cada descoberta do Scanner, você replica manualmente em Repeater, confirmando se é verdadeiro positivo e entendendo a raiz da vulnerabilidade.

5. Testes Parametrizados (Intruder): Para vulnerabilidades confirmadas, você usa Intruder para escalar descobertas—se um parâmetro é vulnerável, você testa quantos outros parâmetros compartilham a mesma fraqueza.

6. Exploração Final (Repeater + Intruder combinados): Para vulnerabilidades críticas (SQL injection, command injection), você constrói exploração final em Repeater, refinando até conseguir acesso completo.

Exemplo concreto—você encontrou uma possível SQLi:

Scanner reporta: Possible SQL injection in /search?q=

Repeater (validação):
GET /search?q=test' HTTP/1.1
→ Observa erro SQL exposto, confirma SQLi

Intruder (quantificação):
Testa parametros similares:
/search?q=§injection§
/filter?name=§injection§
/api/product/query?term=§injection§
→ Descobre que 3 endpoints vulneráveis compartilham a mesma fraqueza

Repeater (exploração):
POST /search?q=1' UNION SELECT username, password FROM users--
→ Extrai credenciais da tabela

Otimizações e Dicas de Produtividade

Scope Configuration: Configure um "Scope" em Burp que define exatamente quais hosts você está testando. Isto reduz ruído no histórico e melhora performance. Target → Scope → Add items com .*alvo\.com\.br.*.

Repeater Chaining: Capture respostas de uma requisição que fornece dados para outra. Por exemplo, uma requisição retorna um token que você precisa copiar para outra requisição. Repeater permite visualizar isto lado a lado e copiar valores diretamente.

Payload Lists: Para Intruder, crie arquivos de payload customizados. A ferramenta vem com listas padrão, mas para um teste específico (enumeração de uma API interna, por exemplo), você deve usar dados reais da organização que refletem sua estrutura de IDs, nomes de usuários, etc.

Match and Replace: Configure regras em Proxy → Options → Match and Replace para adicionar headers ou modificar requisições globalmente. Útil quando testando com tokens que expiram—configure uma regra que substitui tokens antigos automaticamente.

Exemplo de Match and Replace:

Match: Authorization: Bearer .*
Replace: Authorization: Bearer [token_novo]

Isto substitui o token em TODA requisição automaticamente,
economizando horas de configuração manual

Conclusão

Os quatro módulos do Burp Suite—Proxy, Scanner, Intruder e Repeater—formam um ecossistema completo para testes de penetração web quando usados corretamente. O Proxy é a base onde toda a visibilidade ocorre, o Scanner aumenta sua cobertura testando vulnerabilidades conhecidas automaticamente, o Intruder amplifica testes parametrizados em escala, e o Repeater fornece controle manual fino para validação e exploração.

O domínio real vem de entender quando usar cada ferramenta: não inicie Scanner sem antes navegar e entender a aplicação via Proxy; não confie cegamente em resultados do Scanner sem validar em Repeater; e não use Intruder indiscriminadamente sem ter hipóteses claras sobre o que está testando. A maioria dos profissionais iniciantes gasta tempo tentando fazer Scanner encontrar tudo, enquanto profissionais experientes sabem que os 20% de testes mais valiosos vêm de análise manual criativa com Repeater depois que Scanner eliminou os óbvios.

O diferencial entre um testador junior e um senior não é conhecer mais vulnerabilidades—é saber usar a ferramenta de forma tão fluida que pode iterar rapidamente, testar hipóteses complexas sem desperdício, e transformar descobertas automáticas em exploração real que demonstra impacto de negócio.

Referências

1. Documentação Oficial Burp Suite — https://portswigger.net/burp/documentation
2. OWASP Testing Guide — https://owasp.org/www-project-web-security-testing-guide/
3. PortSwigger Web Security Academy — https://portswigger.net/web-security (cursos práticos interativos)
4. The Web Application Hacker's Handbook — Stuttard, D. & Pinto, M. (referência clássica sobre testes web)
5. HackTricks - Burp Suite — https://book.hacktricks.xyz/pentesting-web/burp-suite