Burp Suite: O Arsenal Completo do Web Pentester

Burp Suite: O Arsenal Completo do Web Pentester

Se existe uma ferramenta que define o web pentesting moderno, é o Burp Suite. Criado pela PortSwigger Web Security (fundada por Dafydd Stuttard, o “PortSwigger”), o Burp é o proxy interceptor de referência da indústria — presente em praticamente todo engagement de teste de intrusão web, bug bounty e auditoria de segurança. A versão Community é gratuita e já cobre a maior parte do que um pentester precisa no dia a dia. As versões Professional e Enterprise adicionam automação, scanner ativo e funcionalidades corporativas que justificam o investimento para equipes dedicadas.

Para o exame CEH v13, o Burp Suite aparece como ferramenta recomendada em múltiplos domínios: web application hacking, session hijacking, XSS, SQL injection e enumeration. Entender cada módulo — Proxy, Repeater, Intruder, Decoder, Comparer, Scanner — e saber encadear um workflow completo é diferencial na prova e na vida real.

O objetivo deste artigo é cobrir o Burp Suite de ponta a ponta: da instalação ao hands-on de um pentest completo, passando por cada ferramenta interna, extensões essenciais e a comparação com o principal concorrente open-source.

1. O que é Burp Suite

O Burp Suite é uma plataforma integrada de segurança web que funciona como um proxy HTTP/HTTPS posicionado entre o navegador e o servidor de destino. Todo o tráfego web passa pelo Burp, que pode interceptar, modificar, analisar e automatizar requests e responses. A arquitetura modular permite usar cada ferramenta isoladamente ou combiná-las em workflows complexos.

O Burp roda em Java (requer JRE 11+) e está disponível para Windows, macOS e Linux. No Kali Linux, já vem pré-instalado — basta abrir o menu Applications → Web Application Analysis → burpsuite. Para outras distribuições, o download é feito diretamente do site da PortSwigger.

Versões disponíveis

• Community Edition (gratuita): Proxy, Repeater, Intruder, Decoder, Comparer, Sequencer, Site Map, Target básico. Limitações: não tem Scanner ativo, não salva projetos entre sessões nativamente, intruder com throttle restrito. Ideal para aprendizado e testes pontuais.
• Professional ($449/ano): Tudo da Community mais Scanner ativo e passivo, extensões avançadas, geração de relatórios, save/load de projetos, throttle configurável no Intruder, session handling avançado e Target tools completas. O padrão da indústria para pentesters profissionais e bounty hunters.
• Enterprise (sob consulta): Tudo da Professional mais API para CI/CD, integração com Jira/GitHub, gestão de usuários, scans agendados e compliance reporting. Voltado para equipes de security em empresas grandes.

Como funciona: o modelo Man-in-the-Middle

O Burp Suite atua como um proxy MITM (Man-in-the-Middle). Quando configurado no navegador, todo o tráfego HTTP/HTTPS passa por ele antes de chegar ao servidor e vice-versa. Isso permite:

• Interceptar requests no caminho e modificá-los antes que cheguem ao servidor.
• Inspecionar responses do servidor antes que cheguem ao navegador.
• Repetir requests com variações para testar comportamentos.
• Automatizar ataques com payloads definidos pelo operador.
• Mapear a estrutura completa de uma aplicação web.

Para HTTPS, o Burp gera um certificado CA próprio (PortSwigger CA) que deve ser instalado no navegador para que o tráfego criptografado possa ser descriptografado e inspecionado. Sem esse certificado, o navegador vai exibir avisos de conexão insegura para todo site HTTPS.

2. Proxy: O Coração do Burp

O Proxy é o módulo central do Burp Suite — é por ele que todo o tráfego flui e é onde a interceptação acontece. Quando o Proxy está ativo, ele escuta na porta 8080 (padrão) e aguarda conexões do navegador.

Configuração do navegador

Para usar o Burp, é preciso configurar o navegador para usar o proxy:

# Firefox → Settings → Network Settings → Manual proxy configuration
HTTP Proxy:  127.0.0.1
Port:        8080

# Marcar "Also use this proxy for HTTPS"
# Marcar "Do not use proxy for localhost, 127.0.0.1"

Alternativa prática: usar o FoxyProxy (extensão do Firefox/Chrome) para alternar rapidamente entre proxy direto e via Burp, evitando ter que reconfigurar manualmente a cada sessão.

Instalação do CA Certificate

Após configurar o proxy, acesse http://burp no navegador. O Burp vai exibir uma página com o link para download do certificado CA. Passos:

1. Acesse http://burp (ou http://127.0.0.1:8080)
2. Clique em "CA Certificate" para baixar o arquivo .der
3. Firefox → Settings → Privacy & Security → View Certificates
4. Importar o certificado baixado
5. Marcar "Trust this CA to identify websites"
6. Confirmar

Esse passo é essencial. Sem o certificado instalado, o Burp não consegue descriptografar tráfego HTTPS e o Proxy fica praticamente inútil para sites modernos (que são quase todos HTTPS).

Intercept

A aba Intercept é onde a mágica acontece. Quando a interceptação está ligada (botão “Intercept is on”), cada request HTTP que o navegador envia é pausado antes de chegar ao servidor. Você pode:

• Forward: enviar o request como está para o servidor.
• Drop: descartar o request — o navegador recebe timeout ou erro.
• Modificar e enviar: editar qualquer parte do request (headers, body, URL, cookies) antes de fazer Forward.
• Action menu: enviar para outros módulos (Repeater, Intruder), decode/encode, mudar método HTTP, e mais.

O mesmo se aplica às responses — o Burp pode interceptar a resposta do servidor antes que chegue ao navegador, permitindo observar ou modificar o conteúdo retornado.

Interception Rules

Para evitar que o Burp pare tudo (o que é irritante em navegação normal), é possível configurar regras de interceptação que determinam quais requests devem ser capturados:

# Exemplos de regras úteis:
- Interceptar apenas requests para o target (ex: *.exemplo.com)
- Interceptar apenas POST requests
- Interceptar apenas requests com certo header ou cookie
- Interceptar apenas requests que contenham parâmetros específicos

# No Burp: Proxy → Options → Intercept Server Requests → Add rule
# URL pattern: .*\.exemplo\.com.*
# Automatically intercept: checked

HTTP History

A aba HTTP History registra todo o tráfego que passa pelo proxy, mesmo quando a interceptação está desligada. Cada entrada mostra método, URL, status code, tamanho, e tempo de resposta. É útil para revisitar requests anteriores sem precisar reexecutar a ação no navegador.

Filtros úteis no HTTP History:

• Filtrar por domínio ou path para isolar o alvo.
• Filtrar por método (POST para formulários, PUT/PATCH/DELETE para APIs).
• Filtrar por status code (4xx para erros de autorização, 5xx para erros de servidor).
• Filtrar por mimetype (application/json para APIs, text/html para páginas).

WebSockets

O Proxy também suporta WebSocket connections. Quando o navegador estabelece uma conexão WebSocket através do proxy, o Burp mostra as mensagens enviadas e recebidas em tempo real, permitindo interceptar e modificar mensagens individuais. Isso é essencial para testar aplicações que usam WebSocket para comunicação em tempo real (chat, notificações, streaming de dados).

3. Repeater: Teste Manual Iterativo

O Repeater é a ferramenta de pentest manual por excelência. Permite pegar um request capturado pelo Proxy (ou qualquer request), modificá-lo e reenviá-lo quantas vezes quiser, observando a resposta em cada tentativa.

Workflow padrão

1. Capturar request no Proxy (Intercept)
2. Clicar com o botão direito → Send to Repeater
   (ou Ctrl+R com o request selecionado no HTTP History)
3. No Repeater, modificar o request:
   - Alterar parâmetros
   - Modificar headers
   - Trocar método HTTP
   - Injetar payloads
4. Clicar em "Send"
5. Analisar a response na aba à direita
6. Repetir com variações

Tabs de comparação

O Repeater suporta múltiplas tabs — cada request fica em uma tab separada. Isso permite comparar respostas lado a lado: tab 1 com o request original, tab 2 com um payload modificado, tab 3 com outro. O painel de response inclui visualizações em Raw, Headers, Hex, e Render (HTML renderizado).

Casos de uso clássicos

• Testar payloads de XSS: copiar um request GET com parâmetro de busca, injetar <script>alert(1)</script>, enviar, verificar se o script é refletido na resposta.
• Testar authorization: logado como user A, copiar o request que acessa dados, mudar o ID no path de /api/user/101 para /api/user/102, verificar se retorna dados do outro usuário (IDOR).
• Testar manipulação de cookies/tokens: alterar valores de session cookies, JWT claims, ou API keys para testar validação no servidor.
• Testar method tampering: mudar um POST para PUT ou DELETE, ou um GET para POST, para verificar se o servidor valida o método HTTP corretamente.

# Exemplo: testando IDOR no Repeater
# Request original (user 1000 acessando próprio perfil):
GET /api/v1/profile HTTP/1.1
Cookie: session=abc123def456

# Modificado para acessar perfil de outro usuário:
GET /api/v1/users/1001/profile HTTP/1.1
Cookie: session=abc123def456  # mesma session!

# Se retornar dados do user 1001 → IDOR confirmado

4. Intruder: Ataques Automatizados

O Intruder é a ferramenta de automação de ataques do Burp. Permite enviar um request múltiplas vezes com variações sistemáticas em posições definidas, usando payloads configuráveis. É a ferramenta que transforma um teste manual em uma verificação em escala.

Tipos de ataque

A escolha do tipo de ataque define como os payloads são distribuídos pelas posições de ataque:

• Sniper: um único payload set, aplicado a uma posição de cada vez (sequencialmente). Ideal para testar um payload em múltiplos parâmetros — ex: testar SQL injection em cada campo de um formulário separadamente.
• Battering Ram: um único payload set, aplicado a todas as posições simultaneamente com o mesmo valor. Útil quando o mesmo payload precisa ir em múltiplos campos — ex: testar um username/password idêntico em ambos os campos.
• Pitchfork: múltiplos payload sets (até 8), aplicados às posições em par (payload 1 na posição 1, payload 2 na posição 2, etc.). As listas devem ter o mesmo tamanho. Perfeito para credential stuffing com listas emparelhadas de username/password.
• Cluster Bomb: múltiplos payload sets, testados em todas as combinações possíveis. Payload 1 × Payload 2 × … × Payload N. Cuidado com a explosão combinatória — 100 × 100 = 10.000 requests. Ideal para fuzzing exaustivo quando não se sabe a relação entre parâmetros.

Positions (marcadores de ataque)

No Intruder, as posições de ataque são marcadas com § (o símbolo de section). Você pode posicionar o cursor em qualquer ponto do request e clicar no botão “§” para marcar/desmarcar. Tudo que estiver entre dois marcadores será substituído pelo payload durante o ataque.

# Exemplo de positions para brute-force de login:
POST /login HTTP/1.1
Content-Type: application/x-www-form-urlencoded

username=§admin§&password=§§  ← posição 1: usernames, posição 2: passwords

# Attack type: Pitchfork (listas emparelhadas)
# Payload set 1 (usernames): admin, root, test, administrator
# Payload set 2 (passwords): admin123, password, 123456, toor

Tipos de Payload

• Simple list: lista de strings definidas manualmente ou carregadas de arquivo. O mais comum — wordlists de usernames, passwords, parâmetros.
• Runtime file: payloads lidos de arquivo em tempo de execução. Útil para wordlists muito grandes que não cabem em memória.
• Numbers: gera sequências numéricas com range, step e formato configuráveis. Ex: 1-1000 para fuzzing de IDs.
• Brute forcer: gera todas as combinações possíveis de caracteres com comprimento e charset definidos. Cuidado: cresce exponencialmente.
• Null payloads: não modifica a posição — envia o request original. Útil para medir tempos de resposta baseline ou testar race conditions com throttling.
• Character frobber: faz mutações bit a bit em cada caractere da posição. Útil para fuzzing de encoding e caracteres especiais.

Casos de uso práticos

# 1. Brute-force de login
# Positions: username + password
# Attack type: Pitchfork
# Payload 1: usernames.txt
# Payload 2: rockyou.txt (ou subset)
# Grep-Match: "Welcome" ou "Dashboard" (indicador de sucesso)

# 2. Fuzzing de parâmetros (parameter enumeration)
GET /api/v1/users/§§/profile
# Attack type: Sniper
# Payload: 1-500 (Numbers)
# Comparar responses: 200 = válido, 404 = inexistente, 403 = sem permissão

# 3. Testando IDOR em massa
GET /api/invoices/§§
Cookie: session=victim_session
# Attack type: Sniper
# Payload: 1000-2000 (IDs de faturas de outros usuários)
# Verificar quais retornam 200 vs 403/404

# 4. Fuzzing de headers
§GET§ /api/dashboard HTTP/1.1
X-Custom-Header: §§
# Attack type: Cluster Bomb
# Payload 1: GET, POST, PUT, DELETE, OPTIONS, PATCH
# Payload 2: payloads de header injection

Grep-Match e Grep-Extract

Após o ataque, o Intruder exibe uma tabela com todas as respostas. Para identificar resultados interessantes em centenas ou milhares de requests, use:

• Grep-Match: destaca requests cuja response contém uma string específica. Ex: "success":true, flag{, Welcome back.
• Grep-Extract: extrai dados específicos de cada response para uma coluna na tabela. Ex: extrair o valor de "role": "..." para comparar permissões entre diferentes IDs.

5. Decoder: Codificação e Decodificação

O Decoder é a ferramenta de encode/decode do Burp — essencial para trabalhar com payloads que passam por múltiplas camadas de codificação, algo extremamente comum em web exploitation.

Encode/Decode suportados

• URL encoding: %3Cscript%3E → <script>
• HTML encoding: <script> → <script>
• Base64: YWRtaW46cGFzc3dvcmQ= → admin:password
• Hex: 61646d696e → admin
• Gzip/Zlib: descompressão de dados compactados
• Hashes: decode (identificação) de MD5, SHA-1, SHA-256 — não “descriptografa” (hashes são one-way), mas identifica e formata

Workflow típico

# 1. Copiar um cookie codificado do Proxy:
# session=eyJ1c2VyIjoiYWRtaW4iLCJyb2xlIjoiZ3Vlc3QifQ==

# 2. Colar no Decoder → Smart Decode
# Primeiro decode: Base64 → {"user":"admin","role":"guest"}

# 3. Modificar o JSON:
# {"user":"admin","role":"admin"}

# 4. Encode de volta: Base64 → eyJ1c2VyIjoiYWRtaW4iLCJyb2xlIjoiYWRtaW4ifQ==

# 5. Substituir o cookie no Repeater e testar

O Smart Decode detecta automaticamente o tipo de codificação e aplica o decode correto. Quando há múltiplas camadas (URL-encoded Base64, por exemplo), ele descodifica uma camada por vez — basta clicar novamente.

Por que isso importa

Muitas vulnerabilidades exigem payloads codificados de forma específica. Um XSS pode precisar de URL encoding para bypass de WAF, um JWT manipulado precisa de Base64 encoding correto, e headers personalizados frequentemente usam HTML entities. Sem dominar o Decoder, o pentester fica cego diante de payloads complexos.

6. Comparer: Diff Visual de Requests/Responses

O Comparer permite comparar dois items (requests ou responses) lado a lado, com diff visual highlighting das diferenças. Parece simples, mas é incrivelmente poderoso para certos cenários de teste.

Casos de uso

• Blind injection detection: enviar um request com payload verdadeiro (1=1) e outro com payload falso (1=2), comparar as responses. Qualquer diferença indica que o input está afetando a lógica do backend — sinal de vulnerabilidade.
• Access control testing: comparar a response de um endpoint acessado como admin vs como user comum. Diferenças nos dados retornados (sem mudança de status code) podem indicar IDOR sutil.
• WAF bypass: comparar responses de payloads que foram bloqueados vs os que passaram, para entender o padrão de filtragem e encontrar bypasses.
• Encoding fuzzing: comparar como o servidor responde ao mesmo payload com diferentes codificações (raw, URL-encoded, double-encoded, HTML-encoded).

Como usar

# 1. No Proxy ou Repeater, selecionar um request/response
# 2. Clicar com o botão direito → Send to Comparer
# 3. Repetir para o segundo item
# 4. No Comparer, clicar em "Compare" (setas entre os painéis)
# 5. Diferenças são highlighteadas em amarelo/verde

# Dica: usar o Comparer via código do Burp (Ctrl+B) é mais rápido
# que navegar até a aba

7. Scanner: Análise Automatizada (Pro)

O Scanner é a principal feature que diferencia a versão Professional da Community. É um scanner de vulnerabilidades automatizado que realiza testes passivos e ativos na aplicação alvo.

Passive Scan

O passive scan analisa o tráfego que já passa pelo Burp sem enviar requests adicionais. Ele examina responses procurando padrões que indiquem vulnerabilidades:

• Headers de segurança ausentes (Content-Security-Policy, X-Frame-Options)
• Informações sensíveis em responses (emails, IPs internos, stack traces)
• Formulários com autocomplete em campos sensíveis
• Cookies sem flags Secure/HttpOnly
• SSL/TLS misconfigurations

O passive scan roda continuamente em background e não gera tráfego adicional — seguro para usar em produção.

Active Scan

O active scan envia payloads de teste ativos para encontrar vulnerabilidades. É mais agressivo e modifica dados no servidor — nunca use em produção sem autorização explícita.

O que o active scan detecta:

• XSS (Reflected e Stored): injeção de scripts em parâmetros
• SQL Injection: injeção de queries em parâmetros e headers
• Path Traversal: acesso a arquivos fora do diretório esperado
• OS Command Injection: execução de comandos no servidor
• SSRF (Server-Side Request Forgery): o servidor faz requests para URLs controladas pelo atacante
• XXE (XML External Entity): injeção em parsers XML
• File Upload vulnerabilities: upload de arquivos maliciosos bypassando validações

Relatórios

Após o scan, o Burp gera relatórios detalhados com cada vulnerabilidade encontrada, classificada por severidade (Critical, High, Medium, Low, Information), com descrição, evidência, proof of concept e recomendações de remediação. Os relatórios podem ser exportados em HTML ou PDF para entrega ao cliente.

8. Extensões: Expandindo o Arsenal

O Burp Suite suporta extensões via BApp Store (a “app store” do Burp) ou extensões customizadas em Java, Python (Jython) ou Ruby (JRuby). As extensões podem adicionar novas funcionalidades, modificar o comportamento de módulos existentes ou integrar com ferramentas externas.

Extensões essenciais

• Autorize: testing de authorization. Permite fazer o mesmo request como dois usuários diferentes (admin e guest) e comparar as responses automaticamente. Identifica IDOR e privilege escalation sem esforço manual.
• Logger++: logging avançado de requests/responses. Substitui o HTTP History padrão com filtros mais poderosos, highlighting baseado em regex, e exportação para arquivo.
• Turbo Intruder: motor de fuzzing ultrarrápido que bypassa as limitações de velocidade do Intruder padrão. Usa conexões HTTP/2 e threading avançado — pode enviar dezenas de milhares de requests por segundo.
• HackBar: toolbar de encoding/decoding rápida diretamente na interface. Encode/decode de Base64, URL, HTML, e hash calculation sem precisar abrir o Decoder separadamente.
• JSON Beautifier: formata JSON automaticamente nas responses. Indispensável quando se trabalha com APIs REST que retornam JSON comprimido em uma linha só.
• Wappalyzer: identificação de tecnologias web (frameworks, CMS, libraries, servidores) baseada em headers e conteúdo. Mostra a stack tecnológica do alvo diretamente no Burp.
• CO2 (Collaborator Offline): alternativa offline ao Burp Collaborator para detecção de OOB (out-of-band) vulnerabilities. Útil quando o Collaborator cloud não é viável.
• Software Vulnerability Scanner: identifica versões de software nos headers e respostas, cruzando com bases de dados de CVEs conhecidos.

Como instalar

# Via BApp Store (dentro do Burp):
# 1. Extender → BApp Store
# 2. Buscar pela extensão desejada
# 3. Clicar em "Install"
# 4. Reiniciar o Burp se necessário

# Via arquivo .jar externo:
# 1. Extender → Extensions → Add
# 2. Selecionar o arquivo .jar
# 3. Extension type: Java (ou Python/Ruby)
# 4. Next → Finish

9. Site Map: Mapeamento da Aplicação

O Site Map constrói automaticamente uma representação visual e hierárquica de toda a aplicação web que passa pelo Burp. Cada request é categorizado por domínio, diretório e arquivo, formando uma árvore navegável.

Funcionalidades

• Árvore hierárquica: navegação por domínio → path → arquivo. Mostra a estrutura completa da aplicação sem precisar clicar em cada link manualmente.
• Filtros: filtrar por status code (ex: mostrar apenas 200 e 500), por tipo (JS, CSS, imagens, JSON), por parâmetros (request parameterized), ou por anotações (comentários adicionados pelo pentester).
• Anotações: marcar items com comentários e cores (high/medium/low/interesting) para organizar os achados durante o pentest.
• Selection de scope: selecionar um subconjunto do Site Map como target para Scanner ou Intruder.

Spidering (crawling)

O Burp inclui um spider (crawler) que navega automaticamente pela aplicação, seguindo links e descobrindo conteúdo. No entanto, o spider básico da Community tem limitações — não executa JavaScript, não lida com SPAs (Single Page Applications) e pode ficar preso em loops. Para aplicações modernas baseadas em frameworks como React/Vue/Angular, o ideal é usar o Browser-powered scanning (disponível no Professional) que usa um browser real para o crawling.

# Workflow de mapeamento:
# 1. Configurar proxy no navegador
# 2. Navegar manualmente pela aplicação (login, navegação, formulários)
# 3. O Site Map popula automaticamente com tudo o que foi acessado
# 4. Usar o Spider para descobrir links/rotas não acessados manualmente
# 5. Revisar o Site Map para identificar:
#    - Endpoints com parâmetros (candidatos a fuzzing)
#    - Diretórios com listagem habilitada
#    - Arquivos sensíveis (backup, config, .git, .env)
#    - APIs não documentadas

10. Target: Escopo e Configuração

O módulo Target é onde se define o escopo do pentest — o que está dentro (in-scope) e o que está fora (out-of-scope). Isso é crucial tanto para organização do trabalho quanto para segurança (evitar acidentalmente testar sistemas fora do escopo).

Definindo o Scope

# Target → Site map → selecionar o domínio raiz
# Clicar com o botão direito → "Include in scope"

# Exemplo de escopo para uma aplicação:
# Include: https://app.exemplo.com/*
# Exclude: https://app.exemplo.com/static/*
# Exclude: https://cdn.exemplo.com/*
# Exclude: https://app.exemplo.com/api/v1/logout  (endpoints sensíveis)

# O Burp vai mostrar um indicador visual (ícone de target) ao lado
# de cada request que está no escopo

Session Handling

O Target module permite configurar session handling rules que automatizam tarefas relacionadas a sessão:

• Macro: gravar uma sequência de requests (ex: login) e executá-la automaticamente quando a sessão expirar.
• Cookie jar: gerenciar cookies automaticamente entre requests.
• Token handling: extrair CSRF tokens de responses e incluí-los automaticamente em requests subsequentes.

Match and Replace Rules

Permite definir regras automáticas de substituição no tráfego:

# Exemplos úteis:
# Substituir User-Agent em todos os requests:
# Match: User-Agent: .*
# Replace: User-Agent: PentestBot/1.0

# Remover header de segurança para testar comportamento sem ele:
# Match: X-Frame-Options: .*
# Replace: (vazio)

# Forçar HTTP/2:
# Match em nível de protocolo

TLS Settings

Em Target → TLS, é possível configurar opções de criptografia: versões mínimas de TLS, cipher suites, e certificados client para autenticação mTLS. Útil para testar configurações TLS fracas ou quando o alvo requer client certificates.

11. Hands-On: Web Pentest Completo com Burp Suite

Vamos simular um pentest completo usando uma aplicação vulnerável de exemplo (como DVWA, WebGoat, ou PortSwigger Web Security Academy). O objetivo é demonstrar o workflow real de um pentester usando Burp Suite de ponta a ponta.

Passo 1 — Configuração

# 1. Iniciar Burp Suite (Kali: Applications → Web Application Analysis → burpsuite)
# 2. Configurar browser proxy: 127.0.0.1:8080
# 3. Instalar CA certificate em http://burp
# 4. Verificar interceptação: acessar qualquer site HTTP → deve aparecer no Proxy
# 5. Desabilitar interceptação (Intercept is off) para o mapeamento inicial
#    (vamos ligar apenas quando necessário)

Passo 2 — Mapeamento da Aplicação

# 1. Navegar pela aplicação alvo:
#    - Página de login
#    - Dashboard
#    - Páginas de perfil, configurações
#    - Formulários de busca
#    - APIs (verificar na aba Network do browser devtools)
#
# 2. Verificar o Site Map — deve mostrar a árvore completa
#
# 3. Identificar endpoints interessantes:
#    - POST /login (autenticação)
#    - GET /search?q= (busca — candidato a XSS/SQLi)
#    - GET /api/users/{id} (candidato a IDOR)
#    - POST /api/users (criação de usuário)
#    - GET /admin (painel administrativo)
#
# 4. Marcar os endpoints com anotações no Site Map

Passo 3 — Teste de Login (Brute-Force com Intruder)

# 1. No browser, tentar login com admin/admin
# 2. O Burp captura o POST /login
# 3. Enviar para o Intruder (Ctrl+I)
# 4. Marcar positions:
#    POST /login HTTP/1.1
#    Content-Type: application/x-www-form-urlencoded
#
#    username=§admin§&password=§admin§
#
# 5. Attack type: Pitchfork
# 6. Payload set 1: admin, root, test, administrator, user
# 7. Payload set 2: admin, password, 123456, admin123, root, toor
# 8. Iniciar o ataque
# 9. Verificar resultados: procurar responses com status 200 ou
#    com "Welcome" / "Dashboard" via Grep-Match
#
# 10. Resultado esperado: admin/password → login successful

Passo 4 — Encontrar XSS (Proxy + Repeater)

# 1. Navegar para a página de busca
# 2. Pesquisar algo — "test"
# 3. No Proxy, capturar o GET /search?q=test
# 4. Enviar para o Repeater (Ctrl+R)
# 5. Testar payloads:
#    - /search?q=<script>alert(1)</script>
#    - /search?q="><img src=x onerror=alert(1)>
#    - /search?q=<svg onload=alert(1)>
#
# 6. Verificar se o payload é refletido SEM encoding na response
#    → se sim, XSS refletido confirmado
#
# 7. Testar bypass de encoding:
#    - /search?q=%3Cscript%3Ealert(1)%3C/script%3E
#    - /search?q=<ScRiPt>alert(1)</ScRiPt>
#    - /search?q=<img/src=x/onerror=alert(1)>

Passo 5 — Testar IDOR (Repeater)

# 1. Logado como user comum (user_id=1000)
# 2. Acessar próprio perfil: GET /api/users/1000
# 3. Enviar para o Repeater
# 4. Modificar: GET /api/users/1001
# 5. Enviar — se retornar dados do user 1001, IDOR confirmado
# 6. Automatizar com Intruder:
#    - Position: /api/users/§§
#    - Payload: Numbers 1000-1100
#    - Verificar quantos IDs retornam 200
# 7. Resultado: 47 out of 100 IDs acessíveis → vulnerabilidade crítica

Passo 6 — Gerar Relatório

# Se estiver usando a versão Professional:
# 1. Target → Site map → selecionar o escopo
# 2. Issues (vulnerabilities encontradas) → relatório automático
# 3. Exportar em HTML/PDF
#
# Se estiver usando a versão Community:
# 1. Documentar manualmente cada finding:
#    - Vulnerabilidade (ex: IDOR em /api/users/{id})
#    - Severidade (Critical/High/Medium/Low)
#    - Proof of Concept (request + response)
#    - Impacto (o que o atacante pode fazer)
#    - Remediação (como corrigir)
# 2. Organizar em documento estruturado

12. Burp Suite vs OWASP ZAP

O OWASP ZAP (Zed Attack Proxy) é o principal concorrente do Burp Suite — e o único que oferece um conjunto comparável de funcionalidades como software livre (GPLv2). A comparação entre os dois é inevitável e útil para decidir qual ferramenta usar em cada cenário.

Quando usar cada um

• Burp Suite Pro: pentests profissionais, bug bounty sério, auditorias para clientes que esperam relatórios detalhados. É o padrão da indústria — se você trabalha com web security, vai precisar dele.
• Burp Suite Community: aprendizado, laboratórios (Web Security Academy), testes rápidos e pontuais. Limitado mas funcional.
• OWASP ZAP: quando o orçamento é zero (startups, projetos pessoais, educação), quando se precisa de CI/CD integration open-source, ou quando compliance exige ferramenta open-source. Também excelente para automatização via API e linha de comando.

Na prática, muitos pentesters profissionais usam ambos: Burp Pro para o trabalho manual e scanner, ZAP para automação em pipelines de CI/CD. Conhecer os dois é a melhor posição.

Dicas de Ouro para o CEH e para a Vida Real

• Foque no workflow, não na ferramenta. O CEH quer saber que você entende o processo de pentest web: mapear → interceptar → testar → automatizar → relatar. O Burp é só o veículo.
• DOM Invader (novo no Burp): ferramenta integrada para encontrar DOM-based XSS — um tipo de XSS que acontece no browser, sem ir para o servidor. Aprender a usá-lo é diferencial.
• Use o Web Security Academy. Os laboratórios gratuitos da PortSwigger são o melhor treinamento possível para a prova e para a carreira. Cada artigo da série CEH tem laboratórios correspondentes.
• Organize com Project Files. Na versão Pro, salve o projeto (.burp) para preservar todo o estado — history, issues, scope, anotações. Na Community, use a função de salvar para não perder trabalho.
• Foobar: habilitar a opção de logging no Proxy para registrar tudo em arquivo — essencial para documentação e evidência.
• Nunca esqueça de desligar o proxy quando não estiver usando. Navegar com o Burp no meio sem necessidade expõe todo seu tráfego e pode causar problemas com HTTPS.

Conclusão

O Burp Suite é mais do que uma ferramenta — é uma plataforma completa de segurança web que centraliza praticamente todas as atividades de um pentester em uma interface coesa. Dominar o Proxy para interceptação, o Repeater para testes manuais, o Intruder para automação, e o Decoder para payload crafting é o mínimo que qualquer profissional de segurança web deve saber.

Para o CEH v13, o Burp Suite aparece como ferramenta recomendada em múltiplos módulos. Saber explicar o workflow de interceptação → modificação → reenvio, diferenciar Sniper de Pitchfork no Intruder, e entender o conceito de MITM proxy são pontos que aparecem na prova com frequência.

Para a vida real, o Burp Suite é inevitável. Seja em pentest, bug bounty, ou red teaming, é a ferramenta que você vai abrir primeiro. Invista tempo nos laboratórios da Web Security Academy — não há substituto para prática real.

Próximo Artigo