Pular para o conteúdo
>_ITDITDPlataforma de Segurança Web

Glossário

O que é path traversal — ler arquivos que o servidor jamais deveria servir, via ../

Path traversal (directory traversal) mistura ../ em um campo de nome de arquivo para ler ou escrever arquivos fora da pasta pretendida — .env, configurações, chaves, /etc. Como funciona e a defesa real (não use entrada como caminho; confine a um diretório base) — explicado de forma defensiva, sem passos de ataque.

Publicado 2026-06-10 Atualizado 2026-06-10 4 min de leitura

"Coloque ../ no campo de nome de arquivo e o .env lá no fundo do servidor fica legível" — isso é path traversal. Veja como funciona e como evitá-lo de forma confiável (sem passos de ataque).

Onde aparece

Em qualquer lugar onde "a entrada do usuário escolhe um arquivo".

RecursoO uso arriscado
Download / pré-visualizaçãoUsar ?file= diretamente como nome do arquivo
Exibição de imagem / anexoMontar parte do caminho a partir de um parâmetro da URL
UploadUsar um nome fornecido pelo usuário no caminho de salvamento (tipo escrita — o mais perigoso)
Carregamento de template / localeEscolher um arquivo dinamicamente via ?lang= etc.

Por que funciona

../ significa "subir um nível". Se a aplicação concatena pasta pública + entrada do usuário e abre esse arquivo, segmentos ../ empilhados deixam a requisição "caminhar" para fora da pasta pública.

Pretendido: /var/www/files/ + entrada do usuário
A entrada empilha "subir um nível" (../ ../ ../ …)
↓ a aplicação concatena sem normalizar, depois open()
Alcança fora da base (.env, configurações, chaves, /etc) = leitura/escrita
Concatene a entrada do usuário à pasta base e ../ empilhados alcançam arquivos fora dela.

Leitura significa divulgação; escrita (uploads) significa arquivos plantados em qualquer lugar, o que pode levar a RCE.

Defesa: não use entrada como caminho + confine à base

1

Nunca use entrada do usuário como caminho de arquivo cru (o mais importante)

Resolva os arquivos expostos por meio de uma allowlist de ID → arquivo real. O usuário passa apenas um identificador ("3", "fatura"); o servidor decide o caminho real.

2

Normalize e depois verifique que permanece dentro do diretório base

Transforme em um caminho absoluto com o resolvedor da linguagem (resolve/realpath), e então verifique se ele começa com o diretório base permitido. Rejeite qualquer coisa fora. A remoção ingênua da string '../' falha diante de contornos por codificação.

3

Rode a aplicação com privilégio mínimo

Limite quais arquivos o usuário de runtime da aplicação pode ler ao que o trabalho exige. Mesmo que alguém escape, arquivos ilegíveis não vazam nada.

4

Mantenha segredos totalmente fora da raiz pública

Não coloque .env, .git, chaves ou backups na raiz web ou na pasta de upload, para começar. Remova a superfície de ataque pelo posicionamento.

A visão deste site: é contínuo com erros de posicionamento — corrija na ordem certa

Path traversal é contínuo com o incidente de exposição do .env: ambos são "algo que jamais deveria ser alcançável pela web torna-se alcançável pela web". O primeiro socorro (cabeçalhos, filtros ingênuos) esconde o sintoma; se o código e o posicionamento não forem corrigidos, outra rota ainda vaza. A ordem é (1) código que não usa entrada como caminho, (2) confinamento ao diretório base, (3) manter segredos fora da raiz pública. Leia posicionamento seguro em hospedagem compartilhada junto com isto para o formato da correção real.

Leia a seguir

FAQ

QO que vaza no path traversal?
A

Arquivos que a aplicação nunca deveria expor: .env (credenciais de banco, chaves de API), arquivos de configuração, chaves privadas, código-fonte, caminhos do SO como /etc. Além de leitura, se alcançar o caminho de destino de um upload, pode escrever em qualquer lugar e escalar para RCE (execução remota de código).

QQual é a principal defesa?
A

Nunca use entrada do usuário como caminho de arquivo cru. Se precisar, mapeie-a por uma allowlist (um conjunto fixo de IDs/nomes de arquivo), normalize o caminho com uma biblioteca e verifique que o resultado permanece dentro do diretório base permitido. Verificações de extensão ou remoção ingênua de '../' são contornadas.

QPosso simplesmente bloquear com .htaccess ou cabeçalhos?
A

Isso é um primeiro socorro para um problema diferente (arquivos sensíveis na raiz web). A correção de raiz é colocar o corpo da aplicação, o .env e o .git FORA da raiz pública, mais código que não use entrada como caminho. Primeiro socorro e correção real são trabalhos separados.