Como proteger o log de depuração do WordPress

Quando o modo de depuração do WordPress está habilitado, erros e avisos são gravados em um arquivo de log em /wp-content/debug.log. Isso é incrivelmente útil durante o desenvolvimento. Em um site de produção, no entanto, um log de depuração publicamente acessível é um sério risco de segurança. Qualquer pessoa que conheça a URL pode lê-lo, e ele frequentemente contém muito mais informações sensíveis do que a maioria dos donos de site percebe.

O que o log de depuração contém

O arquivo debug.log não é apenas uma lista de avisos do PHP. Dependendo da configuração do seu site e dos plugins que executa, ele pode conter:

• Erros e avisos do PHP: Eles incluem caminhos de arquivo, números de linha e nomes de função. Um atacante pode usar essas informações para mapear a estrutura de diretórios do seu servidor e identificar código vulnerável.
• Erros de consultas ao banco de dados: Consultas com falha às vezes incluem nomes de tabelas, nomes de colunas e até fragmentos dos dados sendo consultados. Isso dá aos atacantes uma visão do esquema do seu banco de dados.
• Erros de plugins e temas com stack traces: Stack traces revelam quais plugins você usa, suas versões e como interagem. Isso é valioso para planejar ataques direcionados contra vulnerabilidades conhecidas de plugins.
• Chaves de API e credenciais: Plugins mal escritos às vezes registram respostas de API ou erros de conexão que incluem tokens de autenticação, chaves de API ou até senhas em texto simples.
• Dados de usuário e endereços de e-mail: Erros relacionados a registro de usuários, envios de formulário ou envio de e-mail podem incluir dados pessoais como nomes, endereços de e-mail e entrada de formulário.
• Caminhos do sistema de arquivos: Cada erro do PHP inclui o caminho completo do servidor para o arquivo onde ocorreu. Isso revela a estrutura de diretórios da sua hospedagem, nome de usuário e às vezes seu provedor de hospedagem.

Por que o log de depuração é publicamente acessível

Por padrão, o WordPress armazena debug.log dentro do diretório wp-content. Esse diretório é servido pelo seu servidor web como qualquer outra pasta em sua instalação WordPress. A menos que você tenha bloqueado especificamente o acesso, qualquer pessoa pode digitar https://seusite.com/wp-content/debug.log em um navegador e ler o arquivo.

Muitos provedores de hospedagem não bloqueiam esse caminho por padrão. E como o arquivo cresce ao longo do tempo sem qualquer rotação automática, ele pode acumular meses ou até anos de dados sensíveis de erro.

Como atacantes encontram logs de depuração

Scanners automatizados verificam rotineiramente /wp-content/debug.log em todos os sites WordPress que encontram. É um dos primeiros caminhos que ferramentas de varredura de segurança testam. Alguns atacantes também verificam variações comuns:

• /wp-content/debug.log (localização padrão)
• /debug.log (às vezes mal configurado)
• /wp-content/uploads/debug.log (outra má configuração comum)
• /error_log ou /error.log (nomes genéricos de log de erro)

Essas varreduras são baratas, rápidas e totalmente automatizadas. Se seu log de depuração estiver acessível, ele será encontrado.

Bloquear acesso com .htaccess (Apache)

Se seu servidor executa Apache, adicione essa regra ao arquivo .htaccess dentro do seu diretório wp-content:

    Order allow,deny
    Deny from all

Isso diz ao Apache para negar todas as requisições HTTP ao arquivo debug.log. O arquivo ainda existe no disco e o PHP ainda pode escrever nele, mas ninguém pode baixá-lo por meio de um navegador. Se quiser bloquear todos os arquivos de log como precaução, pode usar uma regra mais ampla:

    Order allow,deny
    Deny from all

Bloquear acesso com Nginx

Para servidores Nginx, adicione esse bloco location à sua configuração de servidor:

location ~* /debug\.log$ {
    deny all;
    return 404;
}

Retornar um 404 em vez de um 403 é uma escolha deliberada. Uma resposta 403 (Forbidden) diz a um atacante que o arquivo existe mas está protegido. Um 404 (Not Found) não revela nada. Após adicionar essa regra, recarregue a configuração do Nginx com sudo nginx -s reload.

Mover o arquivo de log para fora do web root

A abordagem mais segura é armazenar o log de depuração em um diretório que seu servidor web não pode servir de forma alguma. No seu wp-config.php, defina a constante WP_DEBUG_LOG para um caminho absoluto fora do seu web root:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', '/home/seuusuario/logs/wp-debug.log');
define('WP_DEBUG_DISPLAY', false);

O diretório /home/seuusuario/logs/ deve existir e ser gravável pelo processo do servidor web. Definir WP_DEBUG_DISPLAY como false é igualmente importante: impede que erros do PHP sejam exibidos diretamente em suas páginas, onde visitantes (e atacantes) poderiam vê-los.

Desativar o modo de depuração em sites de produção

Em um site de produção em funcionamento, a depuração quase sempre deve estar desativada. Raramente há um bom motivo para deixá-la habilitada permanentemente. Defina esses valores em wp-config.php:

define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);

Se você precisa depurar um problema em produção, habilite o modo de depuração temporariamente, reproduza o problema, verifique o log e desabilite-o imediatamente em seguida. Nunca deixe a depuração habilitada "por precaução". O risco não vale a conveniência.

Monitore o tamanho do arquivo de log de depuração

Se você mantém a depuração habilitada em um site de staging ou desenvolvimento, monitore o tamanho do log de depuração. Sem rotação de log, ele pode crescer para centenas de megabytes e eventualmente preencher seu disco. Considere configurar um cron job para rotacioná-lo ou truncá-lo:

# Rotate debug.log weekly, keep 4 backups
# Add to /etc/logrotate.d/wp-debug
/home/seuusuario/logs/wp-debug.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
}

O que fazer se dados sensíveis já foram expostos

Se seu log de depuração esteve publicamente acessível e continha informações sensíveis, tome essas medidas imediatamente:

• Excluir o arquivo de log de depuração: Remova-o do servidor imediatamente.
• Rotacionar todas as chaves de API e credenciais: Qualquer chave de API, senha ou token que tenha aparecido no log deve ser considerado comprometido. Regenere-os.
• Alterar senhas do banco de dados: Se erros de conexão com o banco de dados foram registrados, as credenciais podem ter sido expostas.
• Verificar acesso não autorizado: Revise os logs de acesso do seu servidor por requisições a debug.log. Se alguém o baixou, avalie quais informações obteve.
• Notificar usuários afetados: Se dados pessoais (e-mails, nomes, envios de formulário) foram registrados, você pode ter uma obrigação de GDPR ou privacidade de notificar os indivíduos afetados.

Verifique com o InspectWP

O InspectWP verifica se /wp-content/debug.log está publicamente acessível em seu site. Após proteger o arquivo (bloqueando o acesso, movendo-o ou desabilitando o modo de depuração), execute uma nova varredura do InspectWP. A seção de segurança do relatório confirmará se o arquivo ainda é alcançável. Se o aviso persistir, limpe quaisquer caches do lado do servidor e verifique se suas regras de .htaccess ou Nginx estão aplicadas ao diretório correto.