Veilig loggen: fouten registreren zonder datalek

Kort gezegd: Logging in PHP met oog voor privacy betekent: beveiligingsrelevante gebeurtenissen volledig vastleggen, maar wachtwoorden, tokens, sessie-ID's en gevoelige klantgegevens nooit in het log schrijven. Fouten horen in het logboek, niet op het scherm, logboeken staan buiten de webroot en zijn beschermd tegen wijziging. Hoe lang logboeken blijven bestaan, beslist u bewust samen met de functionaris voor gegevensbescherming.

Tussen sporen veiligstellen en datalek

Na PHP2Shell adviseerden vakmedia webserverlogboeken vanaf 20-10-2026 te bewaren. Wie dat wilde doorvoeren, stelde vaak tweeërlei vast. Of de logboeken waren allang geroteerd en gewist. Of ze bevatten dingen die er nooit in hadden mogen staan: volledige formulierinvoer, wachtwoorden uit mislukte aanmeldingen, API-sleutels in URL's.

Beide is een probleem. Zonder logboeken is een incident nauwelijks te reconstrueren. Met te veel inhoud wordt het logboek zelf een doelwit, want wie toegang tot de server krijgt, leest het graag mee. Goed loggen ligt daartussen: genoeg voor het opsporen van sporen, zo weinig mogelijk te beschermen gegevens.

Wat een PHP-applicatie moet loggen

De OWASP Logging Cheat Sheet noemt gebeurtenissen die voor beveiliging en navolgbaarheid tellen. Voor typische PHP-applicaties zijn ze zo samen te vatten:

Elke vermelding moet de vragen wanneer, waar, wie en wat beantwoorden: tijdstempel, applicatie en host, bronadres, gebruikersaanduiding, soort gebeurtenis en resultaat. Namen of e-mailadressen zijn vaak te maskeren of te vervangen door een interne aanduiding, zonder het nut te verliezen.

Twee bronnen van ongewenste gegevens in het log worden vaak over het hoofd gezien. De eerste zijn URL's: staat een token, een resetsleutel voor wachtwoorden of een e-mailadres in de querystring, dan belandt het automatisch in het toegangslogboek van de webserver, in proxylogboeken en in de browsergeschiedenis. Zulke waarden horen in de request-body of een header, niet in het adres. De tweede bron is de debugmodus. Frameworks en plug-ins schrijven in debugbedrijf vaak volledige verzoeken, databasequery's en omgevingsvariabelen mee. Blijft deze modus na een foutopsporing actief, dan groeit ongemerkt een bestand met precies de informatie die een aanvaller zoekt. Controleer na elke foutopsporing of debuguitvoer weer is uitgeschakeld en verwijder de daarbij ontstane bestanden.

Logging in PHP: de basisinstellingen

Het eerste niveau is PHP zelf. In productie moeten fouten worden gelogd, maar niet weergegeven. Het logboek staat buiten de webroot, zodat het niet via een URL op te halen is.

; php.ini of FPM-pool voor productie
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/app-error.log

Waarom zichtbare fouten gevaarlijk zijn, beschrijft Foutuitvoer in productie uitschakelen. Hoe fouten en exceptions in PHP samenhangen, legt Fouten en exceptions in PHP uit.

Het tweede niveau is de applicatie. Veel frameworks gebruiken daarvoor een bibliotheek volgens de standaard PSR-3 van de PHP-FIG, die een uniforme logger-interface vastlegt. Belangrijk is niet de bibliotheek, maar de discipline: contextgegevens bewust kiezen in plaats van hele verzoeken of objecten in het log te schrijven.

<?php
// Invoer vóór het loggen onschadelijk maken en maskeren
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'] ?? '',
    // nooit: 'passwort' => $_POST['passwort']
]);

Log-injectie en gemanipuleerde vermeldingen

Schrijft een applicatie invoer ongefilterd in het log, dan kan een aanvaller met regeleinden valse vermeldingen veroorzaken. Dat verwart de beoordeling en kan sporen verhullen. De OWASP Cheat Sheet adviseert gestructureerde formaten zoals JSON, het verwijderen of coderen van regeleinden en een lengtebeperking voor invoer in het log.

Even belangrijk is de bescherming van de logboeken zelf:

1. Opslag buiten de webroot en met rechten die de webservergebruiker nodig heeft om te schrijven, maar niet om oude bestanden te verwijderen.
2. Kopie op een tweede systeem, bijvoorbeeld via syslog over een versleutelde verbinding. Wie de server overneemt, mag de sporen niet zomaar kunnen wissen.
3. Leestoegang beperken en zelf loggen. Logboeken bevatten bijna altijd persoonsgegevens.
4. Uitval herkennen: blijft het log plotseling leeg, dan is dat een waarschuwingssignaal.
5. Tijd afstemmen: alle servers betrekken de tijd van dezelfde bron en schrijven een eenduidige tijdzone in het log. Anders zijn vermeldingen van webserver, PHP en database na een incident nauwelijks tot een tijdlijn samen te voegen.

Bewaartermijn en privacy bewust beslissen

Hoe lang logboeken mogen en moeten blijven, is een afweging tussen beveiligingsbelang, gegevensminimalisatie en wettelijke of contractuele voorschriften. Art. 32 AVG vereist technische en organisatorische maatregelen die passen bij het risico, onder meer om vertrouwelijkheid, integriteit en beschikbaarheid van de systemen blijvend te waarborgen; logging kan daaraan bijdragen. Tegelijk mogen persoonsgegevens niet langer dan nodig worden opgeslagen.

Leg daarom per soort logboek een termijn vast, schrijf de motivering op en stem beide af met uw functionaris voor gegevensbescherming. Voor een lopend onderzoek kan het nodig zijn logboeken langer dan de normale termijn veilig te stellen. Ook dat moet dan worden gedocumenteerd. Deze pagina is algemene informatie en geen juridisch advies; bij concrete vragen helpen functionarissen voor gegevensbescherming en advocaten. Hoe u logboeken na een aanval beoordeelt, toont Weblogboeken na een aanval beoordelen.

Hoe helpt PHP SOS concreet?

• Wij controleren uw bestaande logboeken op wachtwoorden, tokens en andere gegevens die daar niet horen.
• Wij stellen PHP en applicatie zo in dat fouten worden gelogd, maar niet getoond.
• Wij richten een beschermde kopie van de logboeken in op een afzonderlijk systeem.
• Via security-monitoring beoordelen wij beveiligingsrelevante vermeldingen doorlopend en melden wij opvallende zaken begrijpelijk.

Conclusie: Goede logboeken zijn zuinig met de inhoud en royaal met de bescherming. Wie nu vastlegt wat wordt gelogd en wat nooit, heeft in het ergste geval bruikbare sporen en geen extra datalek.

Veelgestelde vragen

Bronnen

• OWASP: Logging Cheat Sheet
• PHP-FIG: PSR-standaarden
• PHP-handleiding
• OWASP Top 10