Se o Nmap é a ferramenta do scanning e o Metasploit a da exploração, o Burp Suite é a bancada do teste web. Praticamente todo profissional de segurança de aplicações vive dentro do Burp — ele intercepta, inspeciona, modifica e reenvia requisições HTTP, dando controle total sobre a comunicação entre navegador e servidor. Todas as vulnerabilidades já vistas (SQLi, XSS, CSRF, command injection) são testadas e exploradas, na prática, através do Burp. Esta aula te apresenta a ferramenta; dominá-la é dominar o fluxo de trabalho web. A Community Edition é gratuita e suficiente para aprender; pratique contra o DVWA e o Juice Shop.

O Proxy entre navegador e servidor

O coração do Burp é o Proxy. Ele se posiciona entre o seu navegador e o servidor, interceptando todo o tráfego HTTP/HTTPS. Isso é transformador: lembra da aula Arquitetura web e HTTP: entendendo o terreno, quando dissemos que o atacante controla o cliente e pode forjar qualquer requisição? O Proxy é como você faz isso — você navega normalmente, e o Burp captura cada requisição, permitindo pausá-la, inspecioná-la e modificá-la antes de enviá-la ao servidor. Aquela validação que o front-end fazia (aula Arquitetura web e HTTP: entendendo o terreno)? Você a contorna interceptando a requisição depois do front-end e alterando-a. Para interceptar HTTPS, você instala o certificado do Burp no navegador (o man-in-the-middle consentido da aula TLS/SSL na prática: toda a criptografia trabalhando junta) — é por isso aquela aula importava. Com o Proxy, a comunicação web deixa de ser uma caixa-preta e vira algo que você lê e manipula byte a byte.

O Repeater: ajustar, reenviar, ler

A partir do tráfego capturado, o Burp oferece módulos especializados. O Repeater é o mais usado no dia a dia: ele permite pegar uma requisição, modificá-la e reenviá-la repetidamente, observando a resposta a cada mudança. É a ferramenta do teste manual — você ajusta um parâmetro, reenvia, lê a resposta; ajusta de novo, reenvia. Testar SQLi na mão (aula SQL Injection na mão: conversando com o banco de dados), refinar um payload de XSS, sondar uma command injection — tudo isso é iteração no Repeater. Ele materializa o "ajustar e observar" que define o teste manual de vulnerabilidades, e é onde você passa a maior parte do tempo.

O Intruder e a variação em massa

O Intruder automatiza ataques que exigem muitas requisições variando um valor. Você marca posições numa requisição e fornece uma lista de valores (uma wordlist), e o Intruder envia uma requisição para cada valor, permitindo comparar as respostas. Os usos: força bruta de login (variando senhas — conectando com o Bloco VII), fuzzing de parâmetros (testando muitos payloads para descobrir vulnerabilidades), enumeração (variando IDs para achar IDOR — Broken Access Control da aula OWASP Top 10: o mapa das vulnerabilidades web). É como o Repeater, mas em escala automatizada. Analisando as respostas (por tamanho, código de status, tempo — ler a resposta, aula Arquitetura web e HTTP: entendendo o terreno), você identifica qual valor produziu algo diferente, revelando a senha correta, o payload que funcionou, ou o recurso acessível. (A versão gratuita limita a velocidade do Intruder, mas o conceito se aprende bem nela.)

Decoder, Comparer e Sequencer

Outros módulos completam a bancada. O Decoder codifica e decodifica dados (Base64, URL encoding, hex — útil o tempo todo, já que a web codifica dados constantemente). O Comparer destaca diferenças entre respostas (essencial para injeção cega, onde a diferença revela a resposta). O Sequencer analisa a aleatoriedade de tokens (para detectar identificadores de sessão previsíveis, aula Falhas de autenticação, sessões e JWT: quebrando o controle de identidade). E o Scanner (nas versões pagas) automatiza a detecção de vulnerabilidades. Além disso, o Burp tem uma loja de extensões (o BApp Store) que adiciona funcionalidades — de detecção de vulnerabilidades específicas a integração com outras ferramentas. E o Target mapeia a superfície da aplicação (o sitemap) conforme você navega, organizando o que você descobriu.

O cliente é controlável, tornado concreto

O ponto conceitual que quero fixar: o Burp Suite é a manifestação prática do princípio da aula Arquitetura web e HTTP: entendendo o terreno — que o cliente é controlável e nada que vem dele é confiável. Ele te dá o poder de interceptar e manipular tudo que atravessa a fronteira cliente-servidor, tornando concretas as vulnerabilidades que, sem ele, seriam teóricas. Todo o Bloco XII, na prática, acontece dentro do Burp: você intercepta a requisição, a modifica para injetar seu payload, e observa a resposta. Dominar o Burp não é dominar mais uma ferramenta — é dominar o ambiente onde o teste web é conduzido. E, fiel ao curso, o Burp amplifica quem entende as vulnerabilidades: ele não encontra SQLi por você (nas versões básicas), ele te dá o controle para testá-la — é o seu entendimento que guia o que você faz com esse controle.

Toda segurança deve estar no servidor

Do lado defensivo, entender o Burp é entender o que o atacante consegue fazer com o tráfego, e reforça a lição central da segurança web: como o atacante controla e manipula o cliente livremente (o Burp prova isso), toda segurança deve estar no servidor. Nenhuma validação de front-end, nenhum campo "oculto", nenhuma restrição de JavaScript resiste a alguém com um proxy de interceptação — porque tudo isso é contornado interceptando e modificando a requisição. A existência do Burp é, em si, o argumento definitivo para a validação server-side. Do lado do Blue Team, o tráfego gerado por testes de Burp (Intruder, Scanner) tem padrões que WAFs e monitoramento detectam.

Fontes e leituras recomendadas

Exercícios

  1. O que o Proxy do Burp faz, e como ele concretiza o princípio de que "o atacante controla o cliente"?

    ✓ Resposta:

    O Proxy posiciona-se entre o navegador e o servidor, interceptando todo o tráfego HTTP/HTTPS e permitindo pausar, inspecionar e modificar cada requisição antes de enviá-la. Concretiza o controle do cliente porque permite alterar a requisição depois do front-end, contornando qualquer validação client-side e forjando o que se quiser enviar ao servidor.

  2. Qual a diferença de uso entre o Repeater e o Intruder?

    ✓ Resposta:

    O Repeater é para teste manual: pegar uma requisição, modificá-la e reenviá-la repetidamente, observando a resposta a cada ajuste. O Intruder é para automação: enviar muitas requisições variando um valor a partir de uma wordlist, útil para força bruta, fuzzing e enumeração.

  3. Cite dois usos do Intruder e explique como se identifica o resultado "interessante" entre muitas respostas.

    ✓ Resposta:

    Usos: força bruta de login, fuzzing de parâmetros, enumeração de IDs (IDOR). Identifica-se o resultado interessante comparando as respostas por tamanho, código de status ou tempo — a resposta que difere das demais revela a senha correta, o payload que funcionou ou o recurso acessível.

  4. Por que é preciso instalar o certificado do Burp no navegador para interceptar HTTPS, e a que conceito da aula TLS/SSL na prática: toda a criptografia trabalhando junta isso se liga?

    ✓ Resposta:

    Porque o Burp faz um man-in-the-middle no tráfego HTTPS, apresentando seu próprio certificado; o navegador só confia nesse certificado se ele for instalado como confiável. Liga-se ao conceito da aula TLS/SSL na prática: toda a criptografia trabalhando junta de que a segurança do TLS depende da cadeia de confiança de certificados — aqui, um MITM consentido e local para inspeção.

  5. Como a existência do Burp Suite é "o argumento definitivo para a validação server-side"?

    ✓ Resposta:

    Porque o Burp prova que o atacante pode interceptar e modificar livremente tudo que sai do cliente, contornando validações de front-end, campos ocultos e restrições de JavaScript. Como nada disso resiste a um proxy de interceptação, a única segurança confiável é a que ocorre no servidor — daí o Burp ser o argumento definitivo para validação server-side.