Scanner de logs expostos

Como funciona esta verificação

O Scanaris pede sete rotas onde as aplicações mais comuns escrevem os seus registos quando ninguém lhes diz outra coisa: /debug.log, /error.log, /error_log, /laravel.log, /storage/logs/laravel.log, /npm-debug.log e /wp-content/debug.log. Se alguma responder com um ficheiro de texto que parece um registo, e não com a página genérica do teu site, abre um achado de severidade média com o caminho. Os registos raramente contêm a base de dados inteira, por isso não é crítico; mas raramente há um ficheiro que conte tanto sobre como o teu site funciona por dentro.

Porque importa

Um registo de erros é um diário de tudo o que falhou: caminhos internos do servidor, nomes de ficheiros e de funções, versões exatas de bibliotecas, consultas à base de dados que falharam com os seus parâmetros, endereços IP de utilizadores, às vezes emails ou tokens que apareciam num pedido. Com isso, alguém que procura uma vulnerabilidade sabe exatamente onde olhar e que versão atacar. E o registo cresce: cada dia que está exposto conta mais.

Porque acontece

O WordPress com WP_DEBUG_LOG ativado escreve em wp-content/debug.log, que é uma pasta pública; é o caso mais comum. O Laravel guarda os seus registos em storage/logs, que não devia ser acessível, mas é quando o servidor aponta para a raiz do projeto em vez de para public/. O Apache em alojamento partilhado deixa o error_log junto aos ficheiros do site. E o npm-debug.log aparece quando uma instalação falhou no servidor e ninguém limpou.

Como corrigir

• WordPress: em produção, define('WP_DEBUG', false); no wp-config.php. Se precisas do registo temporariamente, move-o para fora da pasta pública com define('WP_DEBUG_LOG', '/caminho/privado/debug.log'); e apaga o ficheiro atual.
• Laravel: o servidor web deve apontar para a pasta public/ do projeto, nunca para a raiz. Com isso o storage/ deixa de ser alcançável. E APP_DEBUG=false.
• Node e outros: escreve os registos fora do diretório servido e envia-os para um serviço de registos se puderes. Apaga os npm-debug.log e semelhantes do servidor.
• Bloqueia a extensão no servidor como segunda barreira. Em nginx: location ~* \.log$ { deny all; }. Em Apache: <FilesMatch "\.log$"> Require all denied </FilesMatch>.
• Reduz o que registas em produção: nível de erro em vez de depuração, sem despejar corpos de pedido completos nem tokens.

Confirma que está corrigido

for p in debug.log error.log error_log laravel.log storage/logs/laravel.log npm-debug.log wp-content/debug.log; do
  printf "%-28s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://oteudominio.com/$p"
done

O esperado é 404 ou 403 em todos. Se o teu site é uma aplicação de página única e responde 200 com o seu HTML, não é o registo; abre-o para confirmar.

Perguntas frequentes

O meu registo não tem nada sensível, só avisos de PHP.

Esses avisos incluem caminhos completos do servidor e versões de plugins, que é precisamente o que um atacante usa para escolher que exploit testar. E hoje não há nada sensível; amanhã, com um erro novo, pode haver.

Preciso de desativar os registos por completo?

Não. Precisas de que não sejam públicos. Regista o que quiseres numa pasta que o servidor web não sirva, ou num serviço externo.

Isto aplica-se a mim na Vercel ou na Netlify?

Quase nunca: aí os registos não são escritos em ficheiros públicos, veem-se no painel. O achado aparece sobretudo em servidores próprios, WordPress e alojamento partilhado.