Registar com segurança: registar erros sem fuga de dados

Em resumo: Logging em PHP com atenção à proteção de dados significa: registar por completo os eventos relevantes para a segurança, mas nunca escrever no registo palavras-passe, tokens, identificadores de sessão e dados sensíveis de clientes. Os erros pertencem ao registo, não ao ecrã, os registos ficam fora do webroot e estão protegidos contra alterações. Durante quanto tempo os registos se mantêm, decide-o de forma consciente em conjunto com o encarregado da proteção de dados.

Entre a preservação de provas e a fuga de dados

Após o PHP2Shell, os meios especializados aconselharam a conservar os registos do servidor web a partir de 20 de outubro de 2026. Quem quis fazê-lo verificou muitas vezes duas coisas. Ou os registos já tinham sido rodados e apagados. Ou continham coisas que nunca deviam lá estar: entradas completas de formulários, palavras-passe de inícios de sessão falhados, chaves de API em URLs.

Ambas são um problema. Sem registos, um incidente dificilmente se reconstitui. Com demasiado conteúdo, o próprio registo torna-se alvo, pois quem obtém acesso ao servidor gosta de o ler. O bom logging está no meio: suficiente para a busca de vestígios, o mínimo possível de dados dignos de proteção.

O que uma aplicação PHP deve registar

O Logging Cheat Sheet da OWASP indica os eventos que contam para a segurança e a rastreabilidade. Para aplicações PHP típicas, podem resumir-se assim:

Cada entrada deve responder às perguntas quando, onde, quem e o quê: carimbo de data/hora, aplicação e anfitrião, endereço de origem, identificador do utilizador, tipo de evento e resultado. Nomes ou endereços de correio eletrónico podem muitas vezes ser mascarados ou substituídos por um identificador interno, sem perder utilidade.

Duas fontes de dados indesejados no registo são muitas vezes esquecidas. A primeira são os URLs: se um token, uma chave de reposição de palavra-passe ou um endereço de correio eletrónico estiver na query string, vai automaticamente parar ao registo de acessos do servidor web, aos registos de proxy e ao histórico do navegador. Tais valores pertencem ao corpo do pedido ou a um cabeçalho, não ao endereço. A segunda fonte é o modo de depuração. Frameworks e plugins escrevem muitas vezes, em modo de depuração, pedidos completos, consultas à base de dados e variáveis de ambiente. Se este modo permanecer ativo após uma deteção de erros, cresce sem se notar um ficheiro com exatamente as informações que um atacante procura. Verifique, após cada deteção de erros, se as saídas de depuração foram novamente desligadas, e apague os ficheiros gerados.

Logging em PHP: as definições básicas

O primeiro nível é o próprio PHP. Em produção, os erros devem ser registados, mas não apresentados. O registo fica fora do webroot, para que não possa ser consultado através de um URL.

; php.ini ou pool FPM para produção
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/app-error.log

Porque são perigosos os erros visíveis é descrito em display_errors off: desativar a saída de erros em produção. Como os erros e as exceções se relacionam em PHP é explicado em Erros e exceções em PHP.

O segundo nível é a aplicação. Muitos frameworks usam para isso uma biblioteca segundo a norma PSR-3 da PHP-FIG, que fixa uma interface de logger uniforme. O importante não é a biblioteca, mas a disciplina: escolher conscientemente os dados de contexto, em vez de escrever pedidos ou objetos inteiros no registo.

<?php
// Neutralizar e mascarar as entradas antes de registar
function logSicher(string $text): string {
    return mb_substr(str_replace(["\r", "\n"], ' ', $text), 0, 200);
}

function maskiereMail(string $mail): string {
    [$name, $domain] = array_pad(explode('@', $mail, 2), 2, '');
    return mb_substr($name, 0, 1) . '***@' . $domain;
}

$logger->warning('Anmeldung fehlgeschlagen', [
    'benutzer' => maskiereMail(logSicher($_POST['email'] ?? '')),
    'ip'       => $_SERVER['REMOTE_ADDR'] ?? '',
    // nunca: 'passwort' => $_POST['passwort']
]);

Log injection e entradas manipuladas

Se uma aplicação escrever entradas sem filtro no registo, um atacante pode gerar entradas falsificadas com quebras de linha. Isso confunde a análise e pode ocultar vestígios. O Cheat Sheet da OWASP recomenda formatos estruturados como JSON, a remoção ou codificação de quebras de linha e um limite de comprimento para as entradas no registo.

Igualmente importante é a proteção dos próprios registos:

1. Armazenamento fora do webroot e com permissões de que o utilizador do servidor web precisa para escrever, mas não para apagar ficheiros antigos.
2. Cópia para um segundo sistema, por exemplo por syslog através de uma ligação cifrada. Quem assumir o controlo do servidor não deve poder simplesmente apagar os vestígios.
3. Restringir o acesso de leitura e registá-lo também. Os registos contêm quase sempre dados pessoais.
4. Detetar falhas: se o registo ficar de repente vazio, é um sinal de alerta.
5. Sincronizar a hora: todos os servidores obtêm a hora da mesma fonte e escrevem um fuso horário inequívoco no registo. Caso contrário, as entradas do servidor web, do PHP e da base de dados dificilmente se podem reunir numa cronologia após um incidente.

Decidir de forma consciente a conservação e a proteção de dados

Durante quanto tempo os registos podem e devem permanecer é uma ponderação entre o interesse de segurança, a minimização de dados e requisitos legais ou contratuais. O Art. 32 do RGPD exige medidas técnicas e organizativas adequadas ao risco, entre outras coisas para garantir de forma duradoura a confidencialidade, a integridade e a disponibilidade dos sistemas; o registo de eventos pode contribuir para isso. Ao mesmo tempo, os dados pessoais não podem ser conservados por mais tempo do que o necessário.

Defina por isso um prazo por tipo de registo, escreva a fundamentação e acorde ambos com o seu encarregado da proteção de dados. Para uma investigação em curso, pode ser necessário guardar registos para além do prazo normal. Isso deve igualmente ser documentado. Esta página é informação geral e não constitui aconselhamento jurídico; para questões concretas, ajudam o encarregado da proteção de dados e o advogado. Como analisar registos após um ataque é mostrado em Analisar os registos do servidor web após um ataque.

Como ajuda concretamente a PHP SOS?

• Verificamos os seus registos existentes à procura de palavras-passe, tokens e outros dados que lá não pertencem.
• Configuramos o PHP e a aplicação de modo a que os erros sejam registados, mas não apresentados.
• Configuramos uma cópia protegida dos registos num sistema separado.
• Através da monitorização de segurança, analisamos continuamente as entradas relevantes para a segurança e comunicamos de forma compreensível o que for invulgar.

Conclusão: Bons registos são parcimoniosos no conteúdo e generosos na proteção. Quem define hoje o que é registado e o que nunca é, tem, em caso grave, vestígios aproveitáveis e nenhuma fuga de dados adicional.

Perguntas frequentes

Fontes

• OWASP: Logging Cheat Sheet
• PHP-FIG: normas PSR
• Manual do PHP
• OWASP Top 10