'Burp Suite: o canivete suíço do pentester web'

Se o pentest de aplicações web tivesse uma ferramenta-símbolo, seria o Burp Suite. Ele funciona como um proxy entre o seu navegador e o servidor, permitindo interceptar, inspecionar e modificar cada requisição HTTP. A partir desse ponto de controle, abre-se um arsenal de módulos para testar segurança.

Neste guia, vamos configurar o Burp do zero, entender o fluxo de interceptação e percorrer os módulos essenciais — Proxy, Repeater e Intruder. Veremos também como organizar o trabalho por escopo, automatizar variações de payload e manter tudo dentro dos limites legais. O Burp é peça central na Metodologia de pentest: as fases de um teste de invasão sempre que o alvo é uma aplicação web.

O que é o Burp Suite

O Burp Suite é uma plataforma integrada para testes de segurança de aplicações web. Sua arquitetura gira em torno de um proxy que captura o tráfego entre cliente e servidor. Tudo o que passa por ele pode ser analisado e manipulado.

A grande sacada do Burp é unir, num só lugar, ferramentas que antes eram scripts soltos: um proxy de interceptação, um cliente HTTP para reenviar requisições, um motor de automação de payloads e utilitários de codificação. Em vez de pular entre curl, navegadores e editores de texto, você mantém todo o contexto — histórico, cookies, sessão — dentro de uma única interface.

Existe em três edições:

• Community: gratuita, com os módulos manuais essenciais (Proxy, Repeater, um Intruder limitado por throttling).
• Professional: paga, com scanner automatizado, Intruder sem limites de velocidade e uma biblioteca de extensões mais ampla.
• Enterprise: voltada a varredura contínua em pipelines de CI/CD e times de AppSec.

Para aprender, a edição Community basta. Quase todo o teste manual sério acontece nos módulos que ela já oferece. Os conceitos de proxy de interceptação são recomendados pelo guia de testes da OWASP como base do teste manual de aplicações (OWASP Foundation, 2020).

Como o Burp se encaixa no fluxo de teste

Pense no Burp como o microscópio do pentester web. Antes dele, você faz reconhecimento e mapeia a superfície de ataque; depois dele, você documenta e reporta. Durante o teste em si, praticamente toda interação com o alvo passa pelo Burp — é por ele que você enxerga o que o navegador esconde (cabeçalhos, redirecionamentos, chamadas de API em segundo plano) e por ele que você intervém.

Configurando o proxy

O coração do Burp é interceptar o tráfego do navegador. Para isso, você aponta o navegador para o proxy do Burp (por padrão, 127.0.0.1:8080).

Passos típicos:

1. Inicie o Burp e vá em Proxy → Options (ou Proxy settings nas versões recentes); confirme que o listener está em 127.0.0.1:8080.
2. Configure o navegador para usar esse proxy. A forma mais limpa é usar o navegador embutido do Burp (Proxy → Intercept → Open Browser) ou uma extensão de gerenciamento de proxy como o FoxyProxy.
3. Instale o certificado CA do Burp no navegador. Sem ele, o Burp não consegue inspecionar tráfego HTTPS sem erros de certificado.

# Acesse no navegador (com proxy ativo) para baixar o certificado:
http://burp

Depois disso, todo o tráfego do navegador passa pelo Burp, e você pode vê-lo no histórico.

Por que o certificado CA é necessário

O HTTPS existe justamente para impedir que um intermediário leia o tráfego. Quando o Burp se coloca no meio, ele precisa apresentar ao navegador um certificado que o navegador confie — caso contrário, você verá avisos de "conexão não segura". O Burp resolve isso gerando uma autoridade certificadora (CA) própria. Ao instalar o CA do Burp no repositório de confiança do navegador, você autoriza explicitamente esse intermediário no seu próprio ambiente de teste.

Aviso de segurança: o certificado CA do Burp é uma chave que, nas mãos erradas, permitiria interceptar o seu tráfego. Instale-o apenas na sua máquina de teste e remova-o quando terminar. Nunca o compartilhe.

Erros comuns na configuração

• Esquecer de instalar o CA: o tráfego HTTPS some do histórico ou aparece cheio de erros de handshake.
• Proxy do sistema vs. proxy do navegador: configurar o proxy no nível do sistema operacional pode capturar tráfego de telemetria de outros apps, poluindo o histórico. Prefira configurar só no navegador.
• HTTP/2 e WebSocket: lembre-se de que o Burp também intercepta WebSocket (aba própria no histórico) — não ignore esse canal em apps modernos.

Interceptando requisições

Com o proxy ativo, vá à aba Proxy → Intercept. Quando a interceptação está ligada (Intercept is on), cada requisição fica pausada esperando sua decisão: encaminhar (Forward), descartar (Drop) ou modificar antes de enviar.

Esse é o momento mágico: você pode alterar parâmetros, cabeçalhos, cookies e corpo da requisição antes que cheguem ao servidor. É assim que se testa, por exemplo, manipulação de parâmetros e controle de acesso.

Dica: deixe a interceptação desligada durante a navegação normal e ligue só quando quiser pausar uma requisição específica. O histórico em Proxy → HTTP history guarda tudo mesmo com a interceptação desligada.

O histórico de requisições é também onde você mapeia a aplicação, complementando o trabalho descrito em Reconhecimento (recon): a fase mais importante do pentest.

O que observar em cada requisição

Ao interceptar, treine o olho para alguns sinais que costumam render achados:

• Identificadores em parâmetros (id=42, user=joao): candidatos a falhas de controle de acesso (IDOR), em que trocar o valor revela dados de outro usuário.
• Campos ocultos e tokens: muitas aplicações confiam em valores que o usuário pode adulterar (preço, papel, flags de permissão).
• Cabeçalhos de confiança: X-Forwarded-For, Referer, Origin e cookies de sessão podem ser pontos de manipulação.
• Chamadas de API silenciosas: o histórico revela endpoints que a interface nunca mostra diretamente.

Match and Replace: automatizando alterações repetitivas

Em vez de interceptar manualmente a mesma mudança toda vez, use Proxy → Options → Match and Replace para reescrever requisições ou respostas automaticamente. Exemplos úteis: forçar um cabeçalho User-Agent específico, injetar um cookie de sessão em toda requisição ou reescrever um valor que você está testando de forma sistemática.

O módulo Repeater

O Repeater é provavelmente o módulo que você mais usará. Ele permite pegar uma requisição, modificá-la e reenviá-la quantas vezes quiser, observando a resposta a cada tentativa.

Fluxo típico:

1. No histórico do Proxy, clique com o botão direito numa requisição interessante.
2. Escolha Send to Repeater.
3. Na aba Repeater, edite o que quiser e clique em Send.
4. Analise a resposta no painel ao lado.

O Repeater é ideal para testar manualmente uma hipótese — por exemplo, ver como o servidor reage a uma aspas simples num parâmetro, primeiro passo da exploração descrita em Explorando SQL Injection na prática (ético):

GET /produto?id=10' HTTP/1.1
Host: loja.exemplo.com

Se a resposta mudar de comportamento (erro de banco, página diferente), você tem um indício forte a investigar.

Lendo a resposta como um detetive

O Repeater brilha quando você compara respostas de forma metódica. Mude um fator de cada vez e observe:

• Código de status: um 200 virando 500 indica que o servidor engasgou com a sua entrada — possível injeção.
• Tamanho da resposta: diferenças de bytes (visíveis no rodapé do Repeater) revelam respostas distintas mesmo quando a página parece igual.
• Tempo de resposta: atrasos consistentes podem indicar injeção baseada em tempo (time-based SQLi, por exemplo).
• Mensagens de erro: stack traces e mensagens do banco são ouro para entender a tecnologia por trás.

Abas e organização no Repeater

Cada requisição enviada ao Repeater ganha uma aba. Renomeie as abas (duplo clique no nome) para descrever a hipótese que cada uma testa — por exemplo, "IDOR pedido", "SQLi login", "bypass de auth". Em testes longos, essa disciplina evita que você perca a linha de raciocínio entre dezenas de abas.

O módulo Intruder

Enquanto o Repeater é manual, o Intruder automatiza variações de uma requisição. Você marca posições na requisição e fornece payloads; o Intruder envia uma requisição por payload e tabula as respostas.

Tipos de ataque do Intruder:

• Sniper: um conjunto de payloads, uma posição por vez. Bom para fuzzing de um parâmetro.
• Battering ram: o mesmo payload em todas as posições simultaneamente.
• Pitchfork: conjuntos paralelos, um por posição (payload 1 da lista A com payload 1 da lista B, e assim por diante).
• Cluster bomb: todas as combinações entre conjuntos. Útil para força bruta de usuário e senha.

Um uso clássico é o fuzzing de um parâmetro para detectar comportamentos anômalos. O Manual do Web Application Hacker descreve o Intruder como ferramenta central para automatizar ataques personalizados contra parâmetros (Stuttard & Pinto, 2011).

Posição marcada:  /buscar?q=§teste§
Payloads:         <script>alert(1)</script>
                  ' OR '1'='1
                  ../../etc/passwd

Variar payloads assim ajuda a detectar falhas como as exploradas em XSS na prática: explorando Cross-Site Scripting eticamente.

Escolhendo o tipo de ataque na prática

A confusão mais comum de iniciantes é escolher o modo errado. Um guia rápido:

• Tem uma posição e uma lista de payloads? Use Sniper.
• Quer testar combinações de usuário e senha? Use Cluster bomb (uma lista de usuários, outra de senhas).
• Tem dois valores que andam juntos (como um par token/ID válido)? Use Pitchfork.
• Precisa repetir o mesmo valor em vários campos (como o mesmo CSRF token)? Use Battering ram.

Filtrando o sinal do ruído

Depois de rodar um ataque, a tabela de resultados pode ter centenas de linhas. Ordene por Status, Length ou pelo tempo de resposta para isolar a anomalia. Um payload cuja resposta tem tamanho diferente de todos os outros geralmente é o que disparou um comportamento distinto — exatamente o que você procura. Você também pode adicionar colunas com Grep — Match para sinalizar respostas que contêm uma string específica (como "error" ou "welcome").

Atenção (Community): a edição gratuita aplica throttling pesado no Intruder, tornando ataques grandes lentos. Para listas longas, considere o Professional ou ferramentas dedicadas como ffuf. Para aprender o conceito, porém, o Intruder Community é suficiente.

Módulos de apoio: Decoder, Comparer e Sequencer

Além dos três principais, o Burp traz utilitários valiosos:

• Decoder: codifica e decodifica dados (URL, Base64, HTML, hex). Essencial para entender e construir payloads, especialmente quando a aplicação espera valores codificados.
• Comparer: compara duas respostas byte a byte, revelando diferenças sutis entre um pedido bem-sucedido e um bloqueado.
• Sequencer: analisa a aleatoriedade de tokens (de sessão, CSRF), detectando geração previsível.

Esses módulos parecem secundários, mas resolvem problemas pontuais que apareceriam o tempo todo durante um teste sério. O Decoder, por exemplo, é seu aliado quando um parâmetro chega em Base64 e você precisa adulterar o conteúdo decodificado antes de re-codificar. O Sequencer responde a uma pergunta concreta: "será que consigo prever o próximo token de sessão?". Se a entropia for baixa, a aplicação pode estar vulnerável a sequestro de sessão.

Extensões com o BApp Store

O Burp é extensível. O BApp Store (aba Extensions) reúne plugins que ampliam suas capacidades — desde geradores de payload até integrações com outras ferramentas. Extensões populares incluem auxiliares para autorização (testar IDOR em massa), decodificadores adicionais e ferramentas de análise de JWT. Comece com o essencial; instalar dezenas de extensões só polui a interface.

Um fluxo de teste de ponta a ponta

Para amarrar tudo, veja como os módulos se encadeiam em um teste real de uma funcionalidade de busca:

1. Mapeie navegando pela aplicação com a interceptação desligada. O HTTP history registra cada endpoint, inclusive chamadas de API que a interface esconde.
2. Defina o escopo em Target → Scope para que só o domínio autorizado apareça, e configure o Burp para interceptar apenas o que está no escopo.
3. Identifique um candidato no histórico — por exemplo, GET /buscar?q=camisa. Mande para o Repeater com Send to Repeater.
4. Levante hipóteses no Repeater: insira uma aspas simples, observe se o status muda de 200 para 500 ou se o tamanho da resposta varia. Renomeie a aba para "SQLi busca".
5. Automatize a variação mandando a mesma requisição para o Intruder, marcando a posição §q§ e carregando uma lista de payloads de fuzzing. Ordene os resultados por tamanho para isolar a anomalia.
6. Apoie-se nos utilitários quando necessário: o Decoder para codificar um payload que precisa ir em Base64, o Comparer para confrontar a resposta "boa" com a "anômala", o Sequencer se desconfiar de tokens previsíveis.
7. Documente cada passo com capturas de tela e exporte as requisições e respostas relevantes para o relatório.

Esse encadeamento — Proxy mapeia, Repeater confirma, Intruder amplia, utilitários apoiam — é o ritmo natural de quem domina a ferramenta.

Dicas de produtividade

• Atalhos: Ctrl+R manda a requisição focada para o Repeater; Ctrl+Espaço (no Repeater) envia a requisição. Memorizar os atalhos acelera muito o trabalho.
• Anote nos comentários e cores: o histórico permite marcar itens com cores e comentários. Use isso para sinalizar requisições suspeitas que você ainda vai investigar.
• Use o filtro do histórico: esconda recursos estáticos (imagens, CSS, JS) para focar nas requisições que realmente importam.
• Capture o estado cedo: exporte achados à medida que avança, em vez de deixar tudo para o fim.

Organizando o trabalho com escopo

Sem disciplina, o histórico do Burp vira um caos com tráfego de anúncios, telemetria e domínios fora do escopo. Por isso, defina o Target Scope:

1. Vá em Target → Scope.
2. Adicione apenas os domínios autorizados no seu teste.
3. Ative o filtro para mostrar somente itens dentro do escopo (e configure o Burp para interceptar apenas o que está no escopo).

Manter o escopo limpo não é só conforto: testar fora do alvo autorizado é violação de contrato e potencialmente crime. O guia da OWASP reforça que o teste deve respeitar rigorosamente os limites acordados (OWASP Foundation, 2020).

Salvando o projeto e o estado

Em testes que duram dias, salve o projeto do Burp (disponível na edição Professional) para preservar histórico, abas do Repeater e configurações. Mesmo na Community, exporte itens importantes (requisições, respostas e capturas de tela) à medida que avança — você vai precisar deles no relatório final, e perder horas de trabalho por um travamento é frustrante e evitável.

Usando o Burp com ética

O Burp é poderoso justamente porque dá controle total sobre as requisições. Esse poder exige responsabilidade:

• Use apenas em aplicações que você possui ou tem autorização escrita para testar.
• Pratique em alvos legais: laboratórios próprios ou desafios de O que é um CTF? Aprenda hacking jogando.
• Documente tudo: requisições, respostas e evidências entram no relatório.

A linha entre o pentester e o atacante não está na ferramenta, e sim na autorização e na intenção.

Cuidados para não causar dano

Mesmo com autorização, um teste descuidado pode derrubar a aplicação ou corromper dados. Algumas precauções:

• Evite o Intruder em produção sem combinar antes: rajadas de requisições podem parecer um ataque de negação de serviço e disparar alarmes (ou multas contratuais).
• Cuidado com payloads destrutivos: um DROP TABLE "para testar" pode apagar dados reais. Prefira provas de conceito não destrutivas.
• Respeite janelas de manutenção: combine horários para testes intrusivos, especialmente em sistemas com tráfego de usuários reais.

Perguntas frequentes

A edição Community é suficiente para aprender? Sim. Proxy, Repeater, Decoder, Comparer e Sequencer estão completos. A maior limitação é o throttling do Intruder e a ausência do scanner automatizado — recursos importantes em trabalho profissional, mas dispensáveis para estudo e para boa parte do teste manual.

Preciso instalar o certificado toda vez? Não. Uma vez instalado no repositório de confiança do navegador, ele permanece. Lembre-se de removê-lo quando não estiver mais testando, por higiene de segurança.

Burp ou OWASP ZAP? Ambos são proxies de interceptação competentes. O ZAP é totalmente gratuito e open source; o Burp tem uma experiência mais polida e é o padrão de mercado em consultorias. Aprender os conceitos em um facilita migrar para o outro.

Por que minhas requisições HTTPS não aparecem? Quase sempre é o certificado CA do Burp não instalado ou instalado no lugar errado. Confirme que o navegador está usando o proxy e que o CA está no repositório de confiança correto.

Conclusão

O Burp Suite transforma o navegador em um laboratório de testes de segurança. O Proxy dá visibilidade e controle sobre cada requisição; o Repeater permite refinar hipóteses manualmente; o Intruder automatiza variações em escala; e os utilitários de apoio — Decoder, Comparer e Sequencer — resolvem as tarefas do dia a dia. Configure bem o proxy e o certificado, mantenha o escopo limpo, escolha o tipo de ataque certo no Intruder, leia as respostas com método e use tudo isso dentro dos limites éticos e legais. Com o Burp dominado, você terá o canivete suíço que todo pentester web carrega.

Referências

• Dafydd Stuttard, Marcus Pinto (2011). The Web Application Hacker's Handbook (2nd ed.). Wiley.
• OWASP Foundation (2020). OWASP Web Security Testing Guide v4.2. OWASP.
• PortSwigger (2023). Burp Suite Documentation. PortSwigger Web Security.