Pentest Web: exploração prática de vulnerabilidades e payloads

Introdução ao pentest web - Apresentação

Apresentando o curso e o instrutor

Olá! Seja muito bem-vinde ao curso Pentest Web: exploração prática de vulnerabilidades e payloads. Meu nome é Pedro Ketzer e serei seu instrutor nesta jornada.

Audiodescrição: Eu sou um homem branco, uso óculos de armação escura e bigode; meus cabelos são pretos. Atrás de mim há uma cadeira preta com apoio de cabeça da mesma cor. Na parede ao fundo, no armário à minha direita (à sua esquerda), aparecem as cores da Alura, roxo e azul. À minha direita (à sua esquerda), também está exposta a minha coleção de carrinhos em escala 1:64 de diversas marcas.

Ainda falando sobre mim, meu nome é Pedro Ketzer, ou Pedro Henrique Ketzer dos Reis. Eu sou o criador do repositório Roadmap AppSec Brasil, no qual compilei conteúdos para a área de Application Security (segurança de aplicações). Também sou Product Security Engineer (pessoa engenheira de segurança de produto) na KnowBe4, empresa americana com foco principalmente em conscientização em segurança, oferecendo plataformas de treinamento e de segurança de e-mail.

Definindo objetivos e contexto do curso

Qual é o foco deste curso? O que você vai aprender? Ao final, a proposta é que você compreenda a importância da web no ecossistema de aplicações e consiga executar alguns ataques básicos na web. Falaremos, por exemplo, de SQL Injection (injeção de SQL), IDOR, SSRF, Cross-Site Scripting (script entre sites) e outros. Como a IA já está muito presente, vamos discutir quando utilizar IA para criar determinados payloads (cargas úteis) e quando não.

O foco deste curso é 100% ofensivo, com abordagem introdutória e prática. Nós apresentaremos brevemente a teoria, proporemos um exercício básico em conjunto e, em seguida, você fará os laboratórios indicados. Você também pode nos chamar no LinkedIn para acessar os laboratórios. Como o curso é prático, a ideia é que você realize muitos exercícios para consolidar o conteúdo. Caso queira se aprofundar, há várias trilhas na Alura. Eu, por exemplo, ministro conteúdos de Application Security (segurança de aplicações) para a área web. Se você gostar desta aula, poderá aprofundar comigo a camada web — front-end (camada de interface), back-end (lado do servidor), navegador e assuntos relacionados — que esmiúço com mais detalhes.

Qual é a importância do pentesting (testes de invasão) em aplicações web? Gostamos de frisar este ponto. Com o avanço da IA nos últimos anos, já existem estimativas de que haverá cerca de 1,5 bilhão de aplicações web na internet em 2026 — um volume muito grande. Em parte, isso decorre do impulso da IA, que levou muitas pessoas a tirarem projetos do papel e a construírem soluções com IA. Não faltam casos na internet — inclusive abordamos alguns — de aplicações publicadas com apoio de IA que foram comprometidas por não estarem devidamente protegidas. Há, portanto, um cenário amplo pela frente.

Compreendendo o ecossistema web e tecnologias

Queremos oferecer um panorama do ecossistema geral. Tudo está conectado: front-end (camada de interface), back-end (lado do servidor), APIs e o navegador. Essa interconexão possibilita certos tipos de ataque. Muitas vezes, um ataque começa no client-side (lado do cliente) e termina atingindo diretamente o back-end (lado do servidor). Em alguns cenários, é possível alcançar uma instância na Amazon ou interagir com componentes do back-end que permitem escalar privilégios. Qualquer ponto desse ecossistema é um potencial vetor de ataque. Por isso, é fundamental manter essa visão e entender, em cada tentativa, com o que estamos interagindo naquele momento.

Navegadores, por exemplo, constituem um conteúdo bastante denso. A leitura de whitepapers (documentos técnicos) do próprio Google Chrome já exige profundidade. Não é necessário mergulhar nisso agora, mas é importante saber que existe.

Por fim, embora não seja exatamente o foco deste curso, reforçamos que a segurança de aplicações é agnóstica à linguagem. Ao realizar um pentest, podemos nos deparar com aplicações escritas em praticamente qualquer linguagem.

As tecnologias e linguagens mais comuns de mercado — seja no contexto brasileiro ou internacional — incluem JavaScript, Java, PHP, TypeScript e assim por diante, geralmente organizadas em stacks (pilhas tecnológicas). É importante não nutrirmos apego excessivo a uma linguagem nem engajarmos em discussões infindáveis sobre “qual é a melhor”, como acontecia no Twitter. Devemos evitar esse tipo de debate, porque profissionais de segurança trabalham com o que surgir pela frente.

Preparando abordagem e referências de pentest

Dedicamos uma seção apenas para frisar um ponto essencial: saiba o que você está testando. Isso parece óbvio, mas muitas pessoas iniciantes acabam testando de qualquer maneira e, por consequência, realizam verificações que não fazem sentido para aquele contexto. Por exemplo, tentar explorar um Open Redirect (redirecionamento aberto) em uma aplicação que sequer possui front-end (interface), ou tentar um payload (carga útil) em PHP sabendo que a aplicação foi construída em JavaScript. Precisamos dessa compreensão não apenas técnica, mas também de negócio.

Empresas — especialmente quando atuamos com consultoria — percebem risco de maneiras diferentes. Em uma instituição de saúde, como o Hospital Albert Einstein, a proteção dos dados de pacientes é central. Há pacientes famosos que utilizam os serviços, então é crucial que dados e prontuários não vazem, inclusive pelas implicações da LGPD, pois são dados sensíveis. Já no setor financeiro (ramo em que já atuamos), os dados conhecidos como PII (Informações de Identificação Pessoal), como CPF, renda e localização, são prioridade máxima: não é permitido o vazamento desse tipo de dado. As melhores pessoas profissionais de segurança que conhecemos consideram sempre esses dois lados — técnico e de negócio — e, quando realizam pentests (testes de intrusão), avançam muito mais justamente por terem essa visão integrada.

Antes de irmos para a nossa primeira aula de fato, é importante conhecer as principais referências. A principal indicação aqui é o OWASP Top 10, que é o padrão da indústria. Se você ainda não viu o curso da Alura sobre esse tema, recomendamos pausar, assistir ao curso e depois retornar. Mesmo que você não atue diretamente com AppSec (Application Security, segurança de aplicações), é fundamental conhecer o OWASP Top 10. Não é necessário memorizar tudo de ponta a ponta — são cerca de 100 páginas —, mas vale ter esse material como uma referência para o seu pentest, para orientar o que procurar e onde estão as maiores dores das empresas, já que o OWASP Top 10 é atualizado periodicamente.

O que é o OWASP Top 10 além de um padrão da indústria? Trata-se de um compilado dos 10 riscos mais críticos para aplicações web. Ele é estruturado em dois eixos:

• De 1 a 8: baseados em dados reais, como a quantidade de CVEs, incidentes e afins compilados pela OWASP — em geral, os ataques mais comuns que ocorrem na web.
• Os 9 e 10: definidos via pesquisa. A cada atualização, abre-se uma votação em que membros da OWASP votam no que têm percebido como mais problemático. Não nos recordamos se essa votação também é aberta ao público em todas as edições.

Esse arcabouço já evidencia por que o OWASP Top 10 é uma base obrigatória para orientar seus pentests e demais atividades.

Como reforço, a Alura também oferece trilhas dedicadas sobre esse tema. Se necessário, vale retornar, fazer uma revisão e, em seguida, prosseguir, pois aqui teremos uma parte mais prática.

Encerrando a aula 0 e apresentando próximos passos

Este é o encerramento da nossa Aula 0. Na próxima aula, vamos diretamente à exploração e detalharemos a criação de payloads (cargas úteis) no Burp Suite.

Eu te espero lá, te desejo um ótimo dia e até mais.

Introdução ao pentest web - Criando payloads no Burp Suite

Iniciando a aula e apresentando objetivos

Olá!

Seja muito bem-vinde de volta. Vamos dar início agora à nossa primeira aula, na qual começamos a fazer o vínculo entre a teoria e a exploração. Nesta aula, especificamente, vamos tratar da criação de payloads (cargas úteis) no Burp Suite (ferramenta Burp), ou seja, de como realizar craft de payloads (criar cargas úteis) nessa ferramenta. Também apresentaremos uma explicação e uma visão de abordagem em prática ofensiva real. Embora atuemos com Product Security (Segurança de Produto), nosso escopo inclui a execução de testes de segurança ofensiva.

Não se trata de um segredo, mas é muito importante, na área de segurança — especialmente para quem foca na parte ofensiva, como Red Team (Equipe Vermelha), Pentest (teste de invasão) ou atua em consultoria —, entender quando utilizar uma ferramenta (incluindo IA, que também é uma ferramenta) e quando realizar o trabalho manualmente.

Definindo o caminho feliz e formulando hipóteses

O que recomendamos, normalmente? O primeiro passo é entender o caminho feliz da aplicação.

O que é o caminho feliz?

Suponhamos que recebemos a tarefa de realizar um Pentest em uma funcionalidade de transferência via Pix. Não iniciamos testando de forma aleatória. Primeiro, construímos uma base de conhecimento. Como mencionamos na aula anterior, precisamos entender o que estamos testando. Executamos o caminho feliz: realizamos uma transferência Pix ponta a ponta para compreender o fluxo completo.

Nesse processo, priorizamos a execução no dispositivo móvel, capturando as requisições com o Burp Suite para, em seguida, revisarmos cada uma delas. A partir do caminho feliz, começamos a elaborar hipóteses de teste observando os comportamentos da aplicação. Por exemplo, uma requisição de transferência Pix, via de regra, será do tipo POST. A partir disso, verificamos se conseguimos manipular parâmetros. Em cenários extremos — que esperamos não ocorrer — poderíamos até identificar a possibilidade de impersonar outra pessoa, enviando um Pix em nome de outra identidade. O ponto central é que formulamos hipóteses de teste com base no caminho feliz e nas evidências coletadas.

Quando não temos acesso ao código — o que ocorrerá muitas vezes —, ou quando o código é complexo e difícil de entender, muitas hipóteses são formuladas por tentativa e erro. Isso ocorre porque, embora o código pareça correto, pode existir uma configuração periférica incorreta, como algo falhando no Nginx, no WAF ou em outro componente, que impede o comportamento esperado. Por isso, é fundamental formular hipóteses e testá-las metodicamente.

Conduzindo testes manuais e equilibrando ia

Entra, então, a etapa manual. Com testes manuais, executamos verificações simples e objetivas. Por exemplo, podemos tentar um SQL Injection (injeção de SQL) utilizando um determinado payload (carga útil). É importante destacar que não basta inserir um único payload e, caso não funcione, concluir que não há vulnerabilidade. Cada caso é um caso. Existem padrões que se repetem e, conforme ganhamos experiência e testamos em diferentes clientes, aprendemos a reconhecê-los. Ainda assim, é importante realizar esses testes básicos de forma estruturada.

Não faz sentido simplesmente solicitar à IA: “acreditamos que há SQL Injection, teste aí”. Muitas empresas, especialmente hoje, têm aumentado os custos e imposto limites de uso para ferramentas de IA e automações. Não devemos testar sem uma direção fundamentada — seja por percepção técnica, seja por evidências claras no comportamento da aplicação ou no código quando disponível. O ideal é alcançar um equilíbrio no uso da IA: aproveitar sua capacidade de acelerar a iteração sem abdicar do raciocínio crítico e da formulação de hipóteses.

Compartilhamos um exemplo recente. Testávamos SQL Injection sem acesso ao código-fonte. Pela análise das requisições, ficou evidente que uma variável estava sob nosso controle como pessoa usuária e que não passava por sanitização — confirmação obtida com a equipe de desenvolvimento. Apesar disso, não conseguíamos explorar a falha de imediato. O teste que utilizamos inicialmente resultava apenas em um erro genérico, sem evidência clara de falha explorável.

Explorando sql injection e reconhecendo limitações de ferramentas

A partir daí, conduzimos uma sessão de iteração com a IA, fornecendo informações contextuais da aplicação (versão, banco de dados utilizado e sua versão, além de outros detalhes do ambiente que não convém mencionar). Na época, trabalhamos manualmente, sem usar o Model Context Protocol (MCP) do Burp Suite: copiávamos a requisição e a resposta e colávamos no chat da IA, repetindo o ciclo por um tempo. Ao final, conseguimos explorar a injeção de SQL. No caso específico, tratava-se de uma injeção baseada em erro, na qual precisamos forçar um erro para que a aplicação retornasse as informações necessárias. A IA ajudou a acelerar as tentativas e a refinar os vetores até chegar à exploração bem-sucedida.

Para quem está no início da carreira, é comum encontrar, em grupos de Discord ou Telegram, pessoas afirmando que determinada ferramenta é uma “bala de prata” que nunca falha, a ponto de nem precisarem mais explorar manualmente. Observamos esse discurso se repetir ao longo dos anos. Atualmente, a confiança excessiva está frequentemente na IA. De fato, a IA tem melhorado, mesmo com as restrições de segurança nas versões mais recentes. Porém, toda ferramenta tem limitações — inclusive a IA —, especialmente quando não entendemos com precisão o que estamos testando. Além disso, dependendo da empresa e do ambiente, mecanismos de segurança podem ser acionados e bloquear testes automatizados, o que acrescenta complexidade.

Portanto, não devemos confiar exclusivamente em ferramentas. Precisamos compreender profundamente o alvo de teste, formular hipóteses e validá-las com método. Ferramentas falham em certos momentos. O que diferencia uma pessoa profissional competente de uma mediana é saber até onde a ferramenta pode ir e quando ela realmente aumenta nossa produtividade e melhora nossa performance durante o engajamento.

Apresentando o model context protocol do burp suite

Vamos dedicar um tempo para falar do Model Context Protocol (MCP) do Burp Suite, que muitas pessoas não conhecem. Nós não conhecíamos na época e, quando testamos SQL Injection (injeção de SQL), ele teria nos poupado bastante tempo.

O Model Context Protocol (MCP) realiza a conexão com o Burp Suite. Não devemos confundi-lo com o Burp Suite AI, que é outro recurso e é pago. O MCP é gratuito, podemos instalá-lo e vinculá-lo à nossa IA de uso profissional ou pessoal.

Com ele, todo o processo de copiar e colar seria automatizado apenas por meio de conversa. A IA monta os payloads (cargas úteis) e os envia diretamente para o Burp Suite, especificamente para o Burp Repeater, na aba do Repeater. O MCP realiza essa comunicação de forma precisa e ajuda a economizar muito tempo.

Se não estivermos utilizando e tivermos acesso a uma IA — seja fornecida pela empresa para estudo ou já disponível —, vale reservar um tempo, durante ou após esta aula, para instalá-lo. Ele é realmente muito bom; recomendamos fortemente.

Introdução ao pentest web - Laboratório: Explorando SQL injection

Apresentando o laboratório de injeção de SQL

Para finalizar esta aula, queremos realizar um laboratório muito rápido para ilustrar um exemplo não de IA, mas de como testar uma SQL Injection (injeção de SQL) e a lógica envolvida. Esse exemplo é muito simples e serve apenas para apresentar a ideia.

Agora vamos trocar de tela e ir diretamente ao laboratório.

Vamos utilizar o laboratório da PortSwigger. Gostamos muito dele. Eles são os criadores do Burp Suite, nossa ferramenta principal, que é basicamente a base de qualquer ferramenta, independentemente da área. É possível que quem está acompanhando não conheça, o que está tudo bem. Nós utilizamos bastante, colegas utilizam bastante; praticamente todas as pessoas que conhecemos utilizam. Eles disponibilizam gratuitamente a Web Security Academy, o que é excelente. Recomendamos fortemente que, além do curso da Alura, ela seja utilizada como base para os estudos. Esses laboratórios funcionam, basicamente, da seguinte forma: criar uma conta, acessar o tópico de preferência e realizar os testes.

Definindo o objetivo do laboratório

Vamos fazer agora o laboratório de bypass (contorno) de login (entrada) no nível Apprentice. Qual é o objetivo? Realizar o login (entrada) como o usuário administrador.

Vamos alternar a aba e observar a aplicação. Vamos limpar o histórico.

Em cenários reais, muitas vezes não temos acesso ao código da aplicação, ou a aplicação é muito legada e apresenta um código macarrônico, difícil de entender, a ponto de nem a IA interpretar corretamente. Isso acontece com frequência. Muitos testes são baseados em tentativa e erro.

Iniciando os testes de autenticação

Qual é a lógica que vamos seguir aqui? Nós já sabemos o objetivo neste laboratório, mas, no mundo real, começaríamos testando a parte de login. Clicamos em Minha conta e visualizamos uma tela simples de login.

Vamos realizar um teste básico. Por mais trivial que pareça, nunca devemos deixar de testar o simples. Em muitos testes que executamos, casos simples expõem vulnerabilidades graves.

Tentamos autenticar com o usuário administrator. A tentativa não funcionou, como era esperado, pois este é um laboratório de SQL Injection. Temos a requisição POST e a enviamos ao Repeater. Este laboratório é o mais simples, portanto isso nem seria necessário, mas seguimos assim mesmo.

Em seguida, inserimos uma aspa (') para observar o comportamento. O servidor retornou um erro. Isso, no mundo real, não confirma a existência de SQL Injection — especialmente porque sabemos que este é um laboratório propositalmente vulnerável —, mas pode indicar que algo não está funcionando adequadamente.

Injetando comandos e depurando a requisição

Para deixar claro como essa aspa foi enviada no corpo da requisição, o payload ficou assim:

csrf=YOUR_TOKEN&username=administrator'&password=admin

Vamos forçar o comportamento de SQL Injection, injetando um comando. Utilizamos o valor administrator' --, isto é, incluímos uma aspa (') e dois hífens (--) para comentar o restante da consulta. Dessa forma, o banco de dados recebe a instrução com o restante comentado, a verificação do usuário administrator é realizada e a condição tende a retornar true.

Enviamos a requisição e recebemos um retorno OK, mas não funcionou como esperado. O corpo que foi enviado nessa tentativa ficou:

csrf=YOUR_TOKEN&username=adminstrator'--&password=admin

Percebemos que havíamos digitado incorretamente o valor de administrator. Corrigimos e reenviamos.

Depois de corrigir o valor do usuário e manter o comentário SQL, o payload ficou:

csrf=YOUR_TOKEN&username=administrator'--&password=admin

Consolidando o ataque e revisando com ferramentas

Recebemos um 302 e tentamos efetuar o login diretamente pela interface. Copiamos administrator, colamos no campo de usuário e inserimos a senha 123. A aplicação indicou falta de token. Atualizamos a página e repetimos o processo. Inserimos administrator e a senha 123. Agora funcionou: estamos autenticados.

Este é um exemplo simples e demonstra como erros pequenos — como faltar uma letra — são comuns e podem nos confundir. Ainda assim, resolvemos o laboratório.

Voltamos àquela requisição incorreta para revisá-la. Agora vamos ao ChatGPT para pedir a correção, apenas para demonstrar como o MCP (Model Context Protocol) funciona com o Burp Suite.

Selecionamos o modelo GPT-4. Colamos a requisição e solicitamos a correção. O sistema pediu permissão e começou a verificar os elementos, o que é normal. Solicitamos à produção que faça um corte até a conclusão do processamento.

Voltamos. Infelizmente, não serviu para o nosso propósito, pois fomos barrados pelas travas de segurança. Provavelmente não temos um modelo autorizado para conteúdos de segurança. Ainda assim, foi possível observar que o fluxo abriu o Repeater, inspecionou a requisição e, em teoria, teria enviado a requisição correta. O erro estava no valor administrator.

Encerrando a aula e indicando próximos passos

Vamos encerrar esta aula por aqui. Nós vamos testar depois este mesmo laboratório com o sqlmap, para conhecimento.

Recomendamos que, depois de criar sua conta na PortSwigger Web Security Academy, você explore os laboratórios (Labs) de SQL Injection. Há muitos exercícios. Aqui também há conteúdos de Cross-Site Scripting, mas a seção citada é dedicada a SQL Injection. Esses laboratórios ajudam muito no aprendizado.

Por esta aula é isso. Eu te vejo na próxima aula. Eu te desejo um ótimo dia e até mais.

Sobre o curso Pentest Web: exploração prática de vulnerabilidades e payloads

O curso Pentest Web: exploração prática de vulnerabilidades e payloads possui 168 minutos de vídeos, em um total de 43 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:

• Da teoria à exploração: craft de payloads no Burp Repeater