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

Path Traversal e Local File Inclusion: Como testar com segurança

6 min de leituraPublicado: 5 de agosto de 2026

Ilustração visual profissional sobre teste de Path Traversal na área de Web e API PT

Resposta rápida

O teste de Path Traversal é feito apenas em laboratório ou em um sistema autorizado. Verifica-se o Request/Response, o comportamento do servidor, os Roles, o State e o impacto, usando testes mínimos que não danificam os dados.

O teste de segurança Web e API deve examinar os limites de confiança, permissões, entrada, State e lógica de negócios. Cada teste neste artigo é projetado para um laboratório, CTF ou sistema para o qual foi dada permissão explícita. Este artigo foca no teste de Path Traversal e é destinado a estudantes de Web PT. O objetivo é fornecer uma metodologia que possa ser aplicada na prática, em uma entrevista profissional e em um ambiente de trabalho, sem se limitar a uma definição de dicionário.

O principal desafio é que os dados são quase sempre parciais. A canonicalization, o base directory, os encoded separators 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 pergunta de investigação, das evidências necessárias e de um critério claro para a conclusão.

O cenário prático neste artigo é: acesso a um arquivo Marker dedicado dentro de um laboratório. Todos os exemplos são dados de laboratório ou descrições de processos. Quando se trata de Penetration Testing, Web ou Cloud, deve-se trabalhar apenas com autorização explícita, Scope definido e capacidade de interromper o teste.

Fontes de entrada para o Path

Nesta fase, define-se quais evidências são necessárias para responder à pergunta de investigação. Para o teste de Path Traversal, os pontos de base são Role e session, Endpoint e method, Request/Response, Object identifier. Para cada fonte, são registados o proprietário, o período de retenção, o fuso horário, o atraso de receção e os campos que podem estar em falta.

A qualidade da recolha não é medida pela "chegada" do log. É necessário verificar a Completeness, Latency, Parsing, Duplicate events e a sincronização do tempo. Um teste Canary ou um evento de laboratório conhecido permite verificar se a operação apareceu na fonte, passou pelo Pipeline e pode ser pesquisada nos campos corretos.

Traversal vs LFI

O tópico 'Traversal vs LFI' é uma parte central do trabalho de teste de Path Traversal. Recomenda-se dividi-lo em três perguntas: qual é a entrada, que decisão se deseja tomar e qual evidência é suficiente para justificá-la. Estas perguntas evitam o uso automático de uma ferramenta sem entender o objetivo.

Na prática, anote a canonicalization, base directory, encoded separators, symlink, allowlist, compare com o comportamento esperado e defina pelo menos um Pivot. O resultado deve ser verificável por outro analista, incluindo limitações e próximos passos.

Codificação e Canonicalization

O tópico 'Encoding e Canonicalization' é uma parte central do trabalho de teste de Path Traversal. Recomenda-se dividi-lo em três perguntas: qual é a entrada, que decisão se deseja tomar e qual evidência é suficiente para justificá-la. Estas perguntas evitam o uso automático de uma ferramenta sem entender o objetivo.

Validação Segura

Um teste profissional de Path Traversal 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, é possível identificar tanto False Negative quanto False Positive.

Num ambiente autorizado, usa-se uma ação mínima que comprove a alegação sem causar danos. Guarda-se Input, Output, tempo e versão, e após a correção, realiza-se um Retest no mesmo cenário e verifica-se também a Regression em funções próximas.

Remediação e Reteste

Pontos de teste únicos

Neste tópico, recomenda-se construir um mapa de evidências focado antecipadamente. Os principais pontos de teste são: canonicalization, base directory, encoded separators, symlink, allowlist, error handling. A lista não é um Checklist automático; cada item é escolhido porque pode vincular uma entidade, ação e tempo ou explicar um comportamento legítimo.

canonicalization: Defina qual é o valor esperado, o que será considerado uma exceção e qual outra fonte verificará a descoberta.
base directory: Defina qual é o valor esperado, o que será considerado uma exceção e qual outra fonte verificará a descoberta.
encoded separators: Defina qual é o valor esperado, o que será considerado uma exceção e qual outra fonte verificará a descoberta.
symlink: Defina qual é o valor esperado, o que será considerado uma exceção e qual outra fonte verificará a descoberta.
allowlist: Defina qual é o valor esperado, o que será considerado uma exceção e qual outra fonte verificará a descoberta.
error handling: Defina qual é o valor esperado, o que será considerado uma exceção e qual outra fonte verificará a descoberta.

Quando um dos focos não estiver disponível, documente a lacuna e escolha uma alternativa. Por exemplo, se o Process identifier não for estável, pode-se usar tempo, Host, User e Parent; se o Payload for criptografado, usa-se Metadata, volume, frequência e TLS/DNS context.

Processo de trabalho recomendado

Defina o Scope e uma pergunta de trabalho sobre o teste de Path Traversal.
Anote as fontes de dados e as evidências necessárias: canonicalization, base directory, encoded separators, symlink.
Crie uma Baseline curta de comportamento correto ou resultado esperado.
Execute o teste mínimo em um ambiente de laboratório e registre tempo, entrada e saída.
Construa um Timeline ou tabela comparativa e separe os fatos da interpretação.
Faça um Pivot para uma fonte adicional para verificar ou refutar a explicação inicial.
Resuma a decisão, as limitações, a ação recomendada e o critério de Retest.

Cenário prático

O cenário escolhido é o acesso a um arquivo Marker dedicado dentro de um laboratório. O objetivo do exercício não é provar a capacidade de ataque, mas praticar a recolha, comparação e documentação de forma segura. Antes de iniciar o trabalho, são definidos dados simulados, uma janela de tempo e um resultado esperado.

No final do exercício, deve ser entregue um produto que um analista ou outro testador possa rever: uma captura de ecrã ou exportação da evidência, um breve Timeline, uma suposição 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.

Etapa	O que fazer	Produto
Preparação	Defina Scope, tempo e objetivo. Anote quais campos ou evidências de canonicalization, base directory, encoded separators são esperados.	Plano de teste curto
Criação de dados	Execute uma ação segura e simulada relacionada ao teste de Path Traversal, sem informações reais ou impacto num sistema de produção.	Evento/Request/Flow controlado
Recolha	Recolha a evidência bruta e o contexto de uma fonte adicional. Verifique Time zone, identificadores e integridade.	Duas evidências relacionadas
Análise	Escreva o que cada evidência prova, o que não prova e qual é a explicação legítima possível.	Conclusão provisória
Conclusão	Escolha fechar, escalar, encontrar ou ajustar; adicione uma recomendação e um Retest.	Produto documentado

Checklist prático

Verifique e documente: Role e session.
Verifique e documente: Endpoint e method.
Verifique e documente: Request/Response.
Verifique e documente: Object identifier.
Verifique e documente: Server-side effect.
Verifique e documente: Control expected e remediation.
Indique Time zone, versão da ferramenta e hora da recolha.
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 ação de acompanhamento com uma data.

Erros Comuns

Verificar apenas o Status code.
Depender de uma alteração Client-side.
Usar um Payload perigoso.
Não verificar Roles diferentes.
Ignorar a lógica de negócios.
Reportar sem Request/Response limpos.

Resumo e CTA

Path Traversal e Local File Inclusion: Como testar com segurança é um tópico que conecta o conhecimento técnico à disciplina de trabalho. Comece com uma pergunta, recolha apenas evidências relevantes, mantenha contexto e tempo, e escolha uma ação que possa ser justificada e testada novamente.

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

Perguntas frequentes

É permitido testar Path Traversal num site público?

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

O que fazer quando faltam alguns dados?

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

Por quanto tempo as evidências devem ser mantidas?

O tempo depende da política, regulamentação, custo e tipo de evento. É importante definir antecipadamente a Retenção, Legal hold e a capacidade de exportar evidências em um formato verificável.

Como praticar sem comprometer um sistema real?

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