Listagem de diretórios: por que expõe seus arquivos e como desativar
Listagens automáticas de pastas revelam backups, logs e uploads. Como encontrá-las no seu site e desativá-las.
Severidade típica: Alta · Verificado pelo módulo da NovaPentest: Directory Listing
O que é
A listagem de diretórios, também chamada de auto-indexação, é um recurso do servidor web que gera uma página HTML com o conteúdo de uma pasta quando a requisição aponta para um diretório e não existe arquivo de índice, como index.html. No Apache o nome é Options Indexes, no nginx é autoindex, no IIS é Directory Browsing, e o http.server embutido do Python faz isso por padrão.
O recurso é útil em um servidor de arquivos interno e quase nunca desejado em um site público. Em produção, os arquivos de uma pasta devem ser acessados pelos links que a aplicação publica, não navegados como um catálogo.
O controle é simples: o servidor deve se recusar a listar diretórios. Uma requisição para /uploads/ deve retornar 403 ou 404, ou uma página de índice escrita por você, nunca uma lista gerada automaticamente com nomes, tamanhos e datas de modificação dos arquivos.
A listagem costuma ser ativada por acidente: uma configuração padrão que ninguém revisou, uma pasta estática nova criada sob um virtual host antigo, uma imagem de container construída sobre uma base que já traz o recurso ligado, ou um bucket de armazenamento exposto por um proxy. Ela também costuma ser herdada: ativar em um caminho no Apache vale para todos os subdiretórios abaixo dele.
Desligar a listagem não protege um arquivo cuja URL já é conhecida. Ela remove o jeito fácil de descobrir quais arquivos existem, e por isso importa mais em pastas que acumulam conteúdo com o tempo, como uploads, exportações, backups e logs.
Como é explorada
Uma listagem de diretório transforma adivinhação em leitura. Quem abre a pasta vê todos os arquivos dela, inclusive os que nunca tiveram link no site e que o dono talvez nem lembre que existem.
Os arquivos que aparecem assim raramente são os que deveriam ser públicos. Exemplos comuns são dumps de banco de dados ou arquivos compactados do site esquecidos em uma pasta de backup, cópias de arquivos de configuração salvas com extensão .bak ou .old que o servidor agora devolve como texto puro, arquivos de log com e-mails de usuários, endereços IP ou erros internos, planilhas e notas fiscais exportadas em uma pasta de uploads, e documentos enviados por usuários cuja privacidade dependia de ninguém saber o nome do arquivo.
Para os usuários, a consequência é a exposição direta de dados pessoais sem que a aplicação em si tenha sido invadida. Para o site, uma configuração ou um backup vazado pode conter credenciais de banco ou chaves de API, transformando um vazamento de informação em comprometimento total.
A listagem também revela estrutura: nomes de frameworks, números de versão em nomes de arquivo e a organização da aplicação, o que facilita encontrar qualquer outra fraqueza.
Buscadores e serviços de arquivamento às vezes indexam essas páginas, então uma listagem pode continuar encontrável por um tempo depois de corrigida. Remover a listagem não basta se arquivos sensíveis foram expostos; eles devem ser apagados da raiz web, e as credenciais contidas neles, trocadas.
Como detectar
O módulo Directory Listing da NovaPentest requisita dez caminhos comuns sob o alvo: /, /images/, /uploads/, /static/, /assets/, /backup/, /files/, /logs/, /data/ e /tmp/. Para cada caminho que responde com status de sucesso, procura no corpo da resposta assinaturas típicas de listagem, como Index of /, Parent Directory ou Directory listing for, e reporta cada ocorrência como um achado separado de severidade Alta, indicando o caminho. Como sonda caminhos ativamente, o módulo roda nos scans completos autenticados e não faz parte do scanner passivo gratuito em novapentest.com/scan.
A abordagem tem limites. Só esses dez caminhos são testados, então uma listagem em /media/, em /wp-content/uploads/ ou em qualquer pasta específica da aplicação não será encontrada. A detecção é por correspondência de texto, então um servidor com template de listagem personalizado ou traduzido pode passar despercebido, e uma página comum que por acaso contenha a expressão Parent Directory ou Index of / será reportada como listagem. Redirecionamentos são seguidos, então o achado reflete o destino final do caminho.
Para conferir manualmente, requisite cada pasta de onde o site serve arquivos estáticos e observe a resposta: curl -s https://example.com/uploads/ | head -n 20. Uma listagem é inconfundível, normalmente com um título Index of e uma tabela de nomes de arquivos. Veja a linha de status com curl -sI https://example.com/uploads/; o esperado é 403 ou 404. Teste com e sem a barra final e inclua pastas criadas por plugins, ferramentas de build e recursos de upload. Uma busca por site:example.com intitle:"index of" em um buscador pode mostrar listagens que já foram indexadas.
Como corrigir
1. Desligue a listagem globalmente e só reative onde for realmente necessário, o que em um site público quase nunca acontece.
2. nginx: o autoindex vem desligado por padrão, então procure autoindex on; na configuração e remova a linha, ou use autoindex off; no bloco http ou server.
3. Apache: retire Indexes da diretiva Options, por exemplo com Options -Indexes na configuração principal, no bloco Directory correspondente ou em um .htaccess. Como Options é herdado, confira também os diretórios pai.
4. IIS: no IIS Manager, abra Directory Browsing e escolha Disable, ou defina o atributo enabled do elemento directoryBrowse como false em system.webServer no web.config.
5. ASP.NET Core: não chame app.UseDirectoryBrowser() nem services.AddDirectoryBrowser() em produção; o UseStaticFiles sozinho não lista diretórios.
6. Express: sirva arquivos estáticos com express.static, que não lista diretórios, e remova o serve-index se estiver instalado.
7. Esvazie a raiz web de tudo o que não deve ser servido. Backups, dumps, logs e exportações ficam fora do document root ou em armazenamento privado com controle de acesso. Um servidor que se recusa a listar uma pasta ainda entrega um arquivo cujo nome alguém adivinhe.
8. Proteja pastas de upload servindo os arquivos dos usuários por código da aplicação que verifica permissão, ou com nomes aleatórios e impossíveis de adivinhar em um armazenamento que não permite listagem. No S3 ou em serviços similares, mantenha o bucket privado e use URLs assinadas.
9. Se arquivos sensíveis foram expostos, apague-os, troque as credenciais que eles continham e peça a remoção das URLs aos buscadores.
10. Teste de novo cada pasta com curl e inclua a verificação no processo de deploy.
Verifique o seu próprio site
Comece pelo scan passivo gratuito: não precisa de conta e você recebe uma nota de A a F cobrindo cabeçalhos, TLS, cookies, DNS e outras configurações que qualquer visitante consegue observar. Ele não envia payloads de ataque, então não confirma todas as classes de falha. O scan completo, disponível com uma conta gratuita, executa as verificações ativas, incluindo a descrita nesta página.