Cibersegurança e segurança da informação

Metodologia de Teste de Penetração de Aplicações Web de acordo com OWASP WSTG

6 min de leituraPublicado: 5 de agosto de 2026

Ilustração visual profissional sobre Teste de Penetração de Aplicações Web na área de Web e API PT

Resposta rápida

O Teste de Penetração de Aplicações Web é realizado apenas em laboratório ou num sistema autorizado. São verificados o Request/Response, o comportamento do servidor, os Roles, o State e o impacto, utilizando testes mínimos que não danificam os dados.

Os testes de segurança de Web e API devem examinar os limites de confiança, permissões, entrada, State e lógica de negócios. Todos os testes neste artigo são destinados a laboratórios, CTF ou sistemas para os quais foi concedida permissão explícita. O presente artigo foca-se no Teste de Penetração de Aplicações Web e é destinado a estudantes de Web PT e Pentesters Juniores. O objetivo é fornecer um método de trabalho que possa ser implementado na prática, numa entrevista profissional e num ambiente de trabalho, sem se contentar com uma definição de dicionário.

O principal desafio é que os dados são quase sempre parciais. O Role e a sessão, o Endpoint e o método, o Request/Response podem indicar uma direção, mas o seu significado depende do tempo, do ativo, do utilizador e da atividade esperada. Portanto, construiremos o teste em torno de uma questão de investigação, evidências necessárias e um critério claro para a conclusão.

O cenário prático no artigo é: construir um Plano de Testes para OWASP Juice Shop num laboratório. Todos os exemplos são dados de laboratório ou descrições de processos. Quando se trata de Teste de Penetração, Web ou Cloud, deve-se trabalhar apenas com autorização explícita, um Scope definido e a capacidade de interromper o teste.

Pré-envolvimento e Plano de Testes

Um teste profissional de Teste de Penetração de Aplicações Web começa com condições de sucesso e condições de falha. Define-se um Caso positivo, um Caso negativo, um Caso limite e uma atividade legítima semelhante. Desta forma, podem ser identificados tanto Falsos Negativos como Falsos Positivos.

Num ambiente autorizado, utiliza-se uma ação mínima que prova a afirmação sem causar danos. Guardam-se Input, Output, tempo e versão, e após a correção, realiza-se um Reteste no mesmo cenário e verifica-se também a Regressão em funções próximas.

Coleta de informações e Configuração

Uma implementação correta começa com os requisitos e não com as configurações padrão. Define-se quais Use Cases são suportados, qual o volume de dados, quem gere a configuração e qual o mecanismo de Rollback. No Teste de Penetração de Aplicações Web, deve-se distinguir entre configurações que geram Telemetry e configurações que a filtram ou enriquecem.

Após a configuração, executa-se um teste controlado com um dado esperado, verifica-se que o evento foi registado, que os campos centrais existem e que a alteração não criou carga ou Blind spot. Todas as alterações são guardadas em versão, com data, proprietário, razão e resultado do teste.

Identidade, Autenticação e Autorização

No Teste de Penetração de Aplicações Web, identidade e autorização são duas questões distintas: quem é o cliente e o que lhe é permitido fazer no recurso. Verificam-se os Roles, Claims, Session, Object ownership e as alterações ao longo do ciclo de vida, e não se contenta com o facto de o utilizador estar 'ligado'.

Uma matriz de teste inclui um utilizador anónimo, um utilizador comum, um proprietário de objeto, outro utilizador e um administrador. Para cada ação, compara-se o Response e o impacto no lado do servidor. A alteração de um identificador ou Header é apenas um meio de teste; a evidência é que o servidor aprovou ou rejeitou uma ação em violação da política.

Sessão, Validação de entrada e Lógica de negócio

Evidências, Relatórios e Reteste

Pontos de teste únicos

Neste tópico, é recomendável construir antecipadamente um mapa de evidências focado. Os principais pontos de teste são: Role e sessão, Endpoint e método, Request/Response, Object identifier, Server-side effect, Control expected e remediation. A lista não é uma Lista de Verificação automática; cada item é selecionado porque pode ligar uma entidade, ação e tempo, ou explicar um comportamento legítimo.

Role e sessão: Defina qual o valor esperado, o que será considerado anómalo e qual a fonte adicional que verificará a descoberta.
Endpoint e método: Defina qual o valor esperado, o que será considerado anómalo e qual a fonte adicional que verificará a descoberta.
Request/Response: Defina qual o valor esperado, o que será considerado anómalo e qual a fonte adicional que verificará a descoberta.
Object identifier: Defina qual o valor esperado, o que será considerado anómalo e qual a fonte adicional que verificará a descoberta.
Server-side effect: Defina qual o valor esperado, o que será considerado anómalo e qual a fonte adicional que verificará a descoberta.
Control expected e remediation: Defina qual o valor esperado, o que será considerado anómalo e qual a fonte adicional que verificará a descoberta.

Quando um dos pontos não está disponível, deve-se documentar a lacuna e escolher uma alternativa. Por exemplo, se o Process identifier não é estável, pode-se usar tempo, Host, User e Parent; se o Payload é criptografado, usam-se Metadados, volume, frequência e contexto TLS/DNS.

Processo de trabalho recomendado

Defina o Scope e uma única questão de trabalho sobre Teste de Penetração de Aplicações Web.
Registe as fontes de dados e as evidências necessárias: Role e sessão, Endpoint e método, Request/Response, Object identifier.
Crie um Baseline curto de comportamento correto ou resultado esperado.
Execute o teste mínimo num ambiente de laboratório e guarde tempo, entrada e saída.
Construa uma Linha do Tempo ou tabela de comparação e separe facto de interpretação.
Faça um Pivot para uma fonte adicional para verificar ou refutar a explicação inicial.
Resuma a decisão, limitações, ação recomendada e critério de Reteste.

Cenário prático

O cenário escolhido é a construção de um Plano de Testes para o OWASP Juice Shop num laboratório. O objetivo do exercício não é provar a capacidade de ataque, mas sim praticar a recolha, comparação e documentação de forma segura. Antes de iniciar o trabalho, definem-se dados simulados, uma janela de tempo e um resultado esperado.

No final do exercício, deve-se submeter um produto que um analista ou outro testador possa rever: uma captura de ecrã ou Export da evidência, uma Linha do Tempo curta, uma hipótese inicial, uma evidência de verificação, uma limitação e uma recomendação. Quando não há evidência suficiente, a conclusão correta é que o cenário não foi provado.

Passo	O que é realizado	Produto
Preparação	Defina o Scope, tempo e objetivo. Registe quais campos ou evidências de Role e sessão, Endpoint e método, Request/Response devem aparecer.	Plano de teste curto
Criação de dados	Execute uma ação segura e simulada relacionada com Teste de Penetração de Aplicações Web, sem informações reais ou impacto num sistema de produção.	Evento/Request/Fluxo controlado
Coleta	Recolha a evidência bruta e o contexto de uma fonte adicional. Verifique o Time zone, identificadores e integridade.	Duas evidências ligadas
Análise	Escreva o que cada evidência prova, o que não prova e qual a possível explicação legítima.	Conclusão intermédia
Conclusão	Escolha fechar, escalar, Finding ou Tuning; adicione uma recomendação e Reteste.	Produto documentado

Checklist prático

Verifique e documente: Role e sessão.
Verifique e documente: Endpoint e método.
Verifique e documente: Request/Response.
Verifique e documente: Object identifier.
Verifique e documente: Server-side effect.
Verifique e documente: Control expected e remediation.
Indique o Time zone, a versão da ferramenta e a hora da coleta.
Guarde os dados brutos antes de filtrar ou modificar.
Escreva o que a descoberta prova e o que ainda é desconhecido.
Defina o proprietário e a próxima ação com uma data.

Erros comuns

Verificar apenas o Status code.
Confiar na alteração Client-side.
Usar um Payload perigoso.
Não testar Roles diferentes.
Ignorar a lógica de negócio.
Relatar sem Request/Response limpos.

Resumo e CTA

A metodologia de Teste de Penetração de Aplicações Web de acordo com OWASP WSTG é um tópico que conecta conhecimento técnico com disciplina de trabalho. Comece com uma questão, recolha apenas evidências relevantes, mantenha o contexto e o tempo, e escolha uma ação que possa ser justificada e testada novamente.

No curso Cybersecurity & AI da HPI, estes princípios são praticados usando sistemas, logs e laboratórios. O passo seguinte natural é passar para os artigos relacionados, realizar o exercício de laboratório e guardar o produto como parte de um portfólio profissional.

Perguntas frequentes

É permitido realizar Teste de Penetração de Aplicações Web num site público?

Não, sem autorização explícita do proprietário do sistema. Mesmo um teste que parece simples pode alterar dados, ativar mecanismos de defesa ou ser considerado acesso não autorizado.

O que fazer quando alguns dados estão em falta?

Documente o que falta, verifique uma fonte alternativa e reduza o nível de confiança. Não preencha campos por suposição nem apresente 'Desconhecido' como correto.

Quanto tempo as evidências devem ser guardadas?

O tempo depende da política, regulamentação, custo e tipo de evento. É importante definir antecipadamente o Retention, Legal hold e a capacidade de exportar evidências num formato que possa ser verificado.

Como praticar sem comprometer um sistema real?

Utilize máquinas virtuais, dados simulados, CTF ou um laboratório dedicado. Em testes autorizados, defina o Scope, Stop conditions e um backup antes de iniciar o trabalho.