Primeiras aulas do curso
Olá, estudantes! Eu sou o Felipe Carlos Soares Monteiro, o instrutor deste curso.
Audiodescrição: Eu sou um homem branco, estou sentado em frente ao computador, com a parede clara ao fundo e iluminação em tons azuis e lilás.
Vamos iniciar o curso de Burp Suite. A maioria dos trabalhos em aplicações web hoje utiliza essa ferramenta, que é um pré-requisito comum em vagas de pentester e base para certificações como a OSCP. Neste curso, vamos observar e analisar a comunicação entre o navegador e aplicações web para explorar vulnerabilidades. Todo o trabalho será realizado em ambientes locais e deliberadamente vulneráveis.
Para começar, vamos acompanhar o que acontece entre a página e o servidor — o cliente e o servidor — e entender como o Burp Suite torna essa troca visível. Quando uma aplicação web é utilizada, o navegador envia requisições e recebe respostas continuamente. Como essa conversa costuma se estender, dificilmente observamos, sem uma ferramenta dedicada, o que realmente foi enviado e o que foi devolvido.
O Burp atuará nesse caminho como um intermediário. Ele permite observar as requisições e pausar algumas delas antes de chegarem ao destino. Quando fizer sentido, podemos alterar campos da requisição de forma controlada e observar o efeito dessas mudanças na aplicação. Primeiro, vamos entender esse percurso, reconhecer as áreas principais da Burp Suite Community Edition (Edição Community) do Burp Suite e abrir um projeto temporário para conduzir as práticas.
O Burp funciona como um Proxy (proxy): fica entre o navegador e a aplicação-alvo para acompanharmos o tráfego entre servidor e cliente. O navegador envia uma requisição ao Proxy Listener (ouvinte do Proxy) do Burp; o Proxy encaminha essa requisição para a aplicação e a resposta retorna pelo mesmo caminho. O Proxy Listener é o ponto local que recebe a conexão destinada ao Proxy. Esse percurso de requisições HTTP é o que vamos observar e testar.
Quando uma requisição passa pelo Proxy, podemos decidir o que fazer com ela. O registro na aba HTTP History (histórico de requisições HTTP) do Burp Suite mostra o que já ocorreu — as requisições que já passaram. Se precisarmos interromper o envio, a funcionalidade Intercept (interceptar) pausa as requisições antes de chegarem ao destino, permitindo examiná-las e realizar alterações para então enviá-las ao servidor. A partir daí, podemos ajustar o método, o caminho, o cabeçalho ou algum parâmetro e comparar a nova resposta com a anterior. Essa sequência de observar, interceptar e modificar evita mudanças sem conhecer o comportamento inicial. Primeiro entendemos o que está acontecendo para, então, começar a alterar.
Com o caminho da nova requisição em mente, vamos conhecer as áreas do Burp que organizam esse trabalho. O Proxy recebe o tráfego do navegador e permite acompanhar as requisições que entram e saem. Já em Target (alvo), visualizamos as aplicações e usamos a funcionalidade Scope (escopo do alvo) para indicar quais URLs e domínios estão em nosso escopo e fazem parte do trabalho. Cada mensagem que passa pelo Proxy fica registrada na aba HTTP History, como mencionamos anteriormente.
O histórico registra o que já aconteceu, o que foi enviado e as requisições que passaram pelo Burp Suite. Ele forma uma linha do tempo da navegação. Quando uma requisição exige um teste mais cuidadoso, podemos enviá-la ao módulo Repeater e repeti-la com pequenas alterações. Já o módulo Inspector ajuda a localizar e organizar cabeçalhos.
Não precisamos memorizar essas áreas agora; não é nosso foco. O importante é perceber que cada uma participa de uma etapa do mesmo fluxo, e vamos utilizá-las na prática ao longo do curso.
O projeto temporário do Burp Suite, que é o que vamos criar, reúne configurações e tráfego enquanto o Burp está aberto. Como esses dados ficam em memória, a sessão deixa de estar disponível quando fechamos o programa; por isso é um projeto temporário. Para esta aula, isso nos ajuda a começar com um ambiente limpo.
O módulo Target, na aba Scope (escopo), reúne as regras de URL que definem o que pertence ao alvo autorizado, isto é, o que está dentro do nosso escopo. Vamos incluir apenas o domínio do DVWA, o Damn Vulnerable Web Application (DVWA), que é o foco do curso por enquanto e o laboratório que vamos explorar ao longo das aulas.
Com essas definições, já podemos abrir o nosso Kali Linux. A partir deste momento, se o Kali não estiver instalado no ambiente, recomendamos pausar para instalá-lo, se for o caso, ou instalar o Burp Suite diretamente no Windows. Recomendamos utilizá-lo em um ambiente isolado, como uma máquina virtual com o Kali.
Vamos abrir a Burp Suite Community Edition. Pode demorar porque está em máquina virtual, mas deve abrir. Demorou mais do que esperávamos, mas abriu.
Vamos manter as opções padrão marcadas: Temporary Project (projeto temporário) e Memory (memória). Queremos um projeto temporário; não vamos salvar nada por enquanto. Em seguida, vamos usar o perfil Burp defaults (padrão do Burp) e iniciar o Burp Suite.
Quando carregar, veremos a tela inicial. Nela, já conseguimos observar algumas abas importantes. Em Target, podemos definir o Scope (escopo) facilmente, na aba Scope, clicando em Adicionar. Podemos, por exemplo, colocar Guru.com. Independentemente do que acessarmos, apenas as requisições que pertencem a Guru.com ficarão registradas.
Em Proxy, temos a aba Intercept (interceptação), que neste caso está 'Intercept is on'. Em HTTP History (histórico HTTP), veremos todas as requisições que já ocorreram. Há também outras funcionalidades que veremos ao longo do curso, como Intruder, Repeater, Collaborator, Sequencer e Decoder, entre outras. Não entraremos em detalhes agora, pois esta é apenas uma visão inicial.
Agora o caminho fica mais claro: o navegador, a lista de requisições, a aplicação e a resposta, e como cada parte se conecta. Também separamos algumas ações — observar, interceptar e modificar — e abrimos um projeto temporário da Burp Suite Community Edition com as configurações padrão. Como a sessão fica em memória, ao fecharmos o programa, ela será perdida.
O próximo passo é colocar nosso laboratório nesse percurso. Vamos preparar o DVWA (Damn Vulnerable Web Application) e o OWASP Juice Shop. Esses são os dois laboratórios que utilizaremos ao longo do curso para realizar as práticas.
Continuamos na próxima aula.
Antes de testar uma aplicação web, precisamos de um ambiente em que seja possível praticar sem misturar com serviços reais ou serviços fora do nosso escopo. Para isso, vamos usar duas aplicações deliberadamente vulneráveis: o Damn Vulnerable Web Application (DVWA), que oferece cenários para começarmos nossas explorações, e o OWASP Juice Shop, que é mais completo em termos de vulnerabilidades disponíveis.
Neste curso, vamos utilizar duas máquinas: uma Kali, com o Burp Suite (como mostramos na aula anterior), e uma máquina Ubuntu Server para servir como servidor de laboratórios. Optamos pelo Ubuntu Server por preferência para esse tipo de uso, mas essa não é uma exigência. As aplicações podem ser instaladas diretamente no Windows — o que não recomendamos, por serem vulneráveis — ou no próprio Kali como serviço. Preferimos segregar.
No nosso caso, as duas máquinas estão na mesma rede NAT isolada. O Kali estará no endereço 192.168.244.129 e será utilizado para realizar os ataques com o Burp Suite. O Ubuntu Server, na versão 22.04 LTS, estará no endereço 192.168.244.177 e vai hospedar os dois laboratórios.
A instalação das máquinas virtuais não fará parte desta aula. Nosso foco é explorar o Burp Suite, mas faremos um overview (visão geral) do que está sendo feito. As duas VMs (Kali e Ubuntu Server) já estão prontas; vamos partir delas em funcionamento para preparar os serviços.
No diagrama apresentado, observamos o funcionamento da rede NAT com o Kali e o Ubuntu Server disponibilizando os dois laboratórios: DVWA e OWASP Juice Shop. Existem outras formas de executar os laboratórios, que também funcionam; sinta-se à vontade para explorar outras ideias.
Antes de qualquer coisa, vamos visitar o repositório oficial do DVWA. No Kali, acessamos o GitHub, no repositório digininja/DVWA. Você pode explorar o projeto para ver como ele está construído e outras possibilidades além do que será abordado nesta aula; isso é sempre recomendável.
No arquivo README, observamos como o projeto apresenta sua execução. No nosso caso, vamos utilizar a instalação com Docker. A partir daqui, seguiremos para a preparação e montagem do nosso laboratório.
Também vamos verificar o projeto do OWASP Juice Shop, no GitHub, em bkimminich/juice-shop. Vale a pena explorar como ele está estruturado e quais são seus requisitos; é bom entender isso antes de partir para a instalação. Faremos a execução via Docker dentro do servidor Ubuntu.
Agora, vamos abrir o Ubuntu Server por SSH. Já estamos dentro dele. Para isso, realizamos a conexão com o seguinte comando:
No nosso caso, o projeto já está instalado, então vamos apenas replicar os passos necessários para realizar a instalação.
Seguindo o que está no manual do GitHub, executaríamos o comando de clonagem com o link do projeto DVWA. Após a execução, acessamos a pasta "DVWA" para visualizar todos os arquivos necessários para a execução.
Para clonar o repositório e entrar no diretório do projeto:
git clone https://github.com/digininja/DVWA.git
Em seguida, acessamos a pasta:
cd DVWA
Antes de iniciar o Docker, um detalhe importante: caso não tenha o Docker instalado, recomendamos sua instalação. O próprio projeto do DVWA fornece instruções para instalar o Docker, o que reforça a importância de ler a documentação. Além disso, na página oficial do Docker (docs.docker.com), encontramos o guia de instalação no Ubuntu, com os pré-requisitos necessários para deixar todo o ambiente funcionando.
Este passo é um pré-requisito para a instalação em andamento. Vamos editar o arquivo docker-compose.yml e localizar a linha da seção ports:. Originalmente, o endereço estará como 127.0.0.1. Precisamos alterar para 0.0.0.0 para que o serviço escute na interface de rede NAT e fique acessível por essa interface.
Abrimos o arquivo para edição:
nano docker-compose.yml
Dentro do arquivo, ajustamos a seção de portas conforme abaixo, trocando o bind de 127.0.0.1 para 0.0.0.0:
ports:
# - 127.0.0.1:4280:80
- 0.0.0.0:4280:80
Faremos essa pequena alteração; o restante permanece inalterado. Poderíamos também ajustar outras configurações, como a senha do MySQL e o usuário, mas isso não é necessário para o funcionamento neste contexto. Após a modificação, saímos e salvamos o arquivo.
Também podemos realizar essa alteração de forma automática com um comando utilizando sed -i, que fará a substituição e deixará o arquivo conforme o necessário.
sed -i 's#127.0.0.1:4280:80#0.0.0.0:4280:80#' docker-compose.yml
Vamos subir agora os serviços do DVWA utilizando o comando do Docker para compor e iniciar os contêineres em modo destacado (em segundo plano). Esse procedimento iniciará o serviço do DVWA no Docker.
sudo docker compose up -d
Podemos verificar que está em execução utilizando o utilitário ss com as opções -nltp, o que exibirá os serviços ativos. Pela documentação, sabemos que o DVWA sobe na porta 4280, exatamente como indicado: em Local Address, deverá aparecer 0.0.0.0, o que confirma que está escutando em todas as interfaces. Em princípio, está funcionando.
ss -nltp
Vamos testar o acesso pelo navegador em 192.168.244.177:4280. Tudo está conforme esperado: a aplicação está funcionando e acessível.
Podemos acessar a interface do DVWA com as credenciais padrão (admin/password). Não é necessário salvar as credenciais no navegador. Na interface, vemos a lista de vulnerabilidades que serão exploradas: Brute Force (força bruta), Command Injection (injeção de comandos), CSRF (falsificação de solicitação entre sites) e File Inclusion (inclusão de arquivos), entre outras disponibilizadas pelo DVWA.
Uma informação importante: a seção DVWA Security define o nível de segurança das vulnerabilidades. Por padrão, está em Impossible. Durante o curso, vamos deixar em Low, pois nosso foco é testar o Burp Suite no contexto de exploração de vulnerabilidades web, sem a necessidade de contornar controles de segurança. Assim, definimos para Low.
A partir deste ponto, o DVWA está pronto para uso.
Agora vamos preparar a instalação do OWASP Juice Shop. O procedimento será semelhante, com uma pequena diferença: em vez de executar um clone via Git (git clone), podemos utilizar o comando de obtenção de imagem do Docker (docker pull) para puxar o projeto do OWASP Juice Shop. Tudo isso está detalhado na documentação oficial do projeto; em caso de dúvidas, vale a pena pausar e ler com atenção, inclusive para seguir por outra abordagem, se desejado.
Para baixar a imagem oficial:
docker pull bkimminich/juice-shop
Após obter a imagem, executamos o comando indicado no repositório do GitHub para rodar a aplicação em contêiner (lembrando de utilizar privilégios administrativos, pois são comandos do Docker).
Executando a aplicação expondo a porta 3000 (ouvindo em todas as interfaces por padrão ao não especificar o endereço):
sudo docker run --rm -d --name juice-shop -p 3000:3000 bkimminich/juice-shop
Na documentação do OWASP Juice Shop, costuma-se indicar a execução vinculada a 127.0.0.1. Contudo, também queremos que funcione na rede NAT. Para isso, podemos deixar sem especificar endereço (ouvindo em todas as interfaces) ou vincular explicitamente a 0.0.0.0: o resultado será o mesmo para nosso objetivo.
Como alternativa, vinculando explicitamente a 0.0.0.0:
sudo docker run --rm -d --name juice-shop -p 0.0.0.0:3000:3000 bkimminich/juice-shop
Se preferirmos que a execução não ocupe o terminal, podemos colocá-la em segundo plano utilizando o operador &. Há opções para configurá-lo como serviço a ser ativado, e isso pode ser editado, mas não faremos essa alteração agora.
sudo docker run --rm -d --name juice-shop -p 0.0.0.0:3000:3000 bkimminich/juice-shop &
Assim que a execução estiver ativa, confirmamos que o serviço subiu utilizando ss -nltp. O OWASP Juice Shop deve expor a aplicação na porta 3000. Em seguida, abrimos no navegador para confirmar o acesso. A aplicação está disponível e podemos explorar as funcionalidades. Todas as vulnerabilidades exploráveis do OWASP Juice Shop serão tratadas posteriormente em detalhes.
ss -nltp
A partir daqui, podemos realizar nossas explorações no contexto de utilização do Burp Suite. Fiquem à vontade para explorar, verificar outras possibilidades de instalação e modos de uso; é um ambiente bem interessante para testes.
Com os nossos laboratórios funcionando, estamos prontos para continuar o curso. Nos vemos na próxima aula.
Ao abrirmos a aplicação DVWA e apenas observarmos a página carregada, podemos ter a impressão de que nada mais está acontecendo. Porém, em segundo plano, o navegador já enviou requisições e recebeu respostas para essas requisições. Vamos acompanhar uma dessas trocas com o uso do Burp Suite. Partiremos da página desejada, localizaremos a requisição correspondente na aba HTTP history (histórico HTTP) do Burp e seguiremos a partir daí.
Antes de prosseguir, precisamos entender o que vai acontecer. No navegador integrado do Burp Suite, a requisição é encaminhada ao listener (ponto de escuta) do Burp Suite, o ponto local que recebe a conexão do proxy (proxy). Mantemos esse listener em loopback (retorno local) e conferimos na interface a porta em uso; o padrão é 127.0.0.1, na porta 8080.
Uma página raramente solicita um único recurso, o que pode ser um problema em alguns casos. Além dos documentos principais daquele servidor web, a página também pode buscar imagens, folhas de estilo e requisições de dados (APIs), inclusive de outros locais que não pertencem à aplicação. Tudo isso aparece no histórico do Burp Suite, em HTTP history. Para não misturar essas requisições com o restante que realmente queremos analisar, definimos o scope (escopo) em Target > Scope, como vimos na primeira aula. Essa marcação organiza e filtra nossa leitura.
Quando acessamos o DVWA no navegador integrado do Burp Suite, com o Intercept (interceptação) desativado, a requisição segue para o listener e, em seguida, para a aplicação. O DVWA devolve a resposta pelo mesmo caminho, o navegador exibe o resultado e o HTTP history conserva esse fluxo. O histórico associa o recurso acessado à requisição correspondente que selecionarmos.
A partir desse ponto, se ativarmos o Intercept, o percurso deixa de ser automático. A mensagem fica pausada, podemos decidir o que fazer com ela e só então encaminhá-la ou descartá-la. Se descartarmos, ela nunca chega ao servidor.
Uma vez localizada a mensagem, a leitura começa pelo pedido: o método e o caminho indicam qual ação foi enviada. Os cabeçalhos e, quando existirem, cookies, parâmetros e corpo complementam o contexto. No painel de resposta, o status, os cabeçalhos e o corpo revelam o que a aplicação web devolveu para nós. A funcionalidade Inspector (inspetor) do Burp ajuda a separar esses campos quando uma mensagem está selecionada. Como os valores dependem da navegação real, avaliamos caso a caso o que a nossa mensagem efetivamente apresenta.
Com esses conceitos, podemos voltar ao Burp. Abrimos a área de Proxy (proxy) e localizamos a configuração de listeners (pontos de escuta). Em Proxy > Settings (configurações), acessado pelo ícone de engrenagem, vemos os proxy listeners. Essa é a configuração padrão: 127.0.0.1 na porta 8080. Não vamos alterar, mas poderíamos ajustar conforme necessário. Mantemos assim.
Em seguida, abrimos o navegador integrado do Burp Suite clicando no ícone de globo no canto superior direito. Ele já usa o proxy do Burp como padrão, portanto não precisamos fazer nenhuma configuração adicional agora. Aguardamos a abertura e podemos fechar a janela do navegador padrão.
Vamos fazer um teste acessando google.com. Ao retornarmos ao Burp, observamos muitas requisições aparecendo. Vamos limpar o histórico: na aba HTTP history, clicamos com o botão direito do mouse em qualquer requisição e selecionamos “Clear history” para apagar tudo. No entanto, isso não é o que queremos em definitivo. Assim, acessamos a aba Target (alvo) > Scope (escopo) e clicamos em “Add”. Lá está “google.com”, que tínhamos deixado anteriormente; vamos removê-lo.
Vamos adicionar apenas a URL do DVWA. Vamos copiá-la; já estava aberta. Sabemos que está no endereço: 192.168.244.177. Vamos adicionar e confirmar. Não precisamos especificar a porta. Não há nenhum domínio definido; aqui é o endereço IP. Com isso, o scope (escopo) está definido.
Podemos refazer o teste. Se acessarmos o google.com novamente, o que acontece no HTTP history (histórico HTTP) do Burp Suite? Nada. Por quê? O HTTP history agora captura apenas as requisições dentro do scope (escopo) definido.
Podemos validar acessando 192.168.244.177 na porta 4280. Confirmamos que é a porta 4280. A página de login do DVWA está acessível. Agora as requisições aparecem no HTTP history (histórico HTTP) do Burp Suite. Entraremos em detalhes nelas em seguida, mas elas já estão visíveis.
No navegador integrado do Burp Suite, acessamos a URL do DVWA. Vamos deixar o Intercept (interceptação) desligado por enquanto, para a requisição funcionar e a página carregar.
Agora podemos mudar essa configuração. Fomos à aba Proxy, em Intercept, e ligamos o Intercept (interceptação) para observar o que acontece. A captura surgiu automaticamente porque estamos usando o navegador do Burp; caso contrário, a página ficaria apenas carregando, pois a requisição não chegaria ao servidor. Nesse ponto, temos duas opções: Forward (encaminhar) ou Drop (descartar). Também podemos alterar alguma informação da requisição. Por exemplo, no parâmetro security, podemos definir low e, em seguida, acionar o Forward (encaminhar). Ao voltar à aba do navegador integrado, a página do DVWA carrega corretamente.
Se atualizarmos novamente, também podemos acionar um Drop (descartar). Nesse caso, a requisição não chega ao servidor. Observamos a mensagem: “Request was dropped by user” (A requisição foi descartada pela pessoa usuária). Em seguida, podemos desligar o Intercept (interceptação). Sabemos que todas as requisições permanecem salvas na aba HTTP history (histórico HTTP) do Burp Suite e podemos revisitar qualquer uma delas quando necessário.
Agora que temos as requests (requisições) e responses (respostas) visíveis, podemos verificar o que está aparecendo. Observamos o host para o qual estamos fazendo a requisição, os cookies de sessão e que se trata de uma requisição GET. Portanto, qualquer parâmetro que viesse por GET apareceria ao lado do recurso que desejamos acessar. Também vemos a resposta associada à requisição para login.php.
Se quisermos manipular apenas essa requisição, exploramos outra funcionalidade do Burp Suite: podemos enviar a requisição para o Repeater (Repetidor). Ao enviar, teremos a mesma requisição que havia no fluxo original. Podemos confirmar pelo tamanho: no Repeater (Repetidor), a requisição apresenta 1696 bytes. Já no cabeçalho da resposta, vemos “Content-Length: 1342”. Isso nos ajuda a confirmar a correspondência com a interação original.
Se modificarmos qualquer coisa — por exemplo, adicionando uma aspa no final — obtemos “Not Found” e o “Content-Length: 319”. Alteramos a requisição e podemos verificar como a página renderiza na aba Render (Renderização): “Not Found”.
Conseguimos, portanto, alterar uma requisição original e, a partir daqui, vamos começar a trabalhar. Com essa correspondência entre navegação, requisição e resposta — na qual a resposta obtida se torna nossa referência para os trabalhos seguintes — vamos manter este projeto temporário aberto e deixar o Intercept (Interceptação) desligado para não interromper o fluxo das execuções.
A partir daqui, poderemos iniciar os trabalhos de exploração com o Burp Suite, agora que temos um entendimento melhor de como a ferramenta atua integrada no meio do caminho entre cliente e servidor.
Continuamos na próxima aula.
O curso Burp Suite: análise e manipulação do tráfego web possui 158 minutos de vídeos, em um total de 45 atividades. Gostou? Conheça nossos outros cursos de Red Team & Pentest em Cibersegurança, ou leia nossos artigos de Cibersegurança.
Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:
Todos os cursos, trilhas e certificados para evoluir.
7 dias para cancelar com reembolso
Aprenda mais rápido com IA, idiomas e imersões.
7 dias para cancelar com reembolso
TUDO DO PLUS, MAIS:
Aceleração de carreira: mentoria, vagas e prática guiada.
7 dias para cancelar com reembolso
TUDO DO PRO, MAIS: