Jurnalizare sigură: înregistrarea erorilor fără scurgeri de date

Pe scurt: Logging în PHP, cu atenție la protecția datelor, înseamnă: consemnați complet evenimentele relevante pentru securitate, dar nu scrieți niciodată în jurnal parole, token-uri, identificatori de sesiune și date sensibile ale clienților. Erorile aparțin jurnalului, nu ecranului, jurnalele se află în afara webroot-ului și sunt protejate împotriva modificării. Cât timp rămân jurnalele decideți în mod conștient, împreună cu responsabilul cu protecția datelor.

Între asigurarea urmelor și scurgerea de date

După PHP2Shell, mediile de specialitate au sfătuit păstrarea jurnalelor serverului web începând cu 20.10.2026. Cine a vrut să facă acest lucru a constatat adesea două lucruri. Fie jurnalele fuseseră de mult rotite și șterse. Fie conțineau lucruri care nu ar fi trebuit să apară niciodată acolo: introduceri complete din formulare, parole din autentificări eșuate, chei API în URL-uri.

Ambele sunt o problemă. Fără jurnale, un incident poate fi greu reconstituit. Cu prea mult conținut, jurnalul însuși devine țintă, deoarece cine obține acces la server îl citește cu plăcere. Un logging bun se află între: suficient pentru căutarea urmelor, cât mai puține date care merită protejate.

Ce ar trebui să jurnalizeze o aplicație PHP

OWASP Logging Cheat Sheet enumeră evenimente care contează pentru securitate și trasabilitate. Pentru aplicațiile PHP tipice, ele pot fi rezumate astfel:

Fiecare înregistrare ar trebui să răspundă la întrebările când, unde, cine și ce: marcaj de timp, aplicație și host, adresă sursă, identificator de utilizator, tipul evenimentului și rezultatul. Numele sau adresele de e-mail pot fi adesea mascate sau înlocuite cu un identificator intern, fără a pierde utilitatea.

Două surse de date nedorite în jurnal sunt adesea trecute cu vederea. Prima sunt URL-urile: dacă un token, o cheie de resetare a parolei sau o adresă de e-mail se află în query string, ajunge automat în access log-ul serverului web, în jurnalele proxy și în istoricul browserului. Asemenea valori aparțin în corpul cererii sau într-un antet, nu în adresă. A doua sursă este modul de depanare. Framework-urile și pluginurile scriu în modul de depanare adesea cereri complete, interogări de bază de date și variabile de mediu. Dacă acest mod rămâne activ după o depanare, crește pe nesimțite un fișier cu exact informațiile pe care le caută un atacator. Verificați după fiecare depanare dacă ieșirile de depanare au fost din nou dezactivate și ștergeți fișierele apărute.

Logging în PHP: setările de bază

Primul nivel este PHP însuși. În producție, erorile trebuie jurnalizate, dar nu afișate. Jurnalul se află în afara webroot-ului, pentru a nu putea fi accesat printr-un URL.

; php.ini sau pool FPM pentru producție
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/app-error.log

De ce sunt periculoase erorile vizibile descrie Dezactivarea ieșirilor de eroare în producție. Cum se leagă erorile și excepțiile în PHP explică Erori și excepții în PHP.

Al doilea nivel este aplicația. Multe framework-uri folosesc pentru aceasta o bibliotecă conform standardului PSR-3 al PHP-FIG, care definește o interfață unitară de logger. Important nu este biblioteca, ci disciplina: alegeți în mod conștient datele de context, în loc să scrieți în jurnal cereri sau obiecte întregi.

<?php
// Dezamorsați și mascați introducerile înainte de jurnalizare
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'] ?? '',
    // niciodată: 'passwort' => $_POST['passwort']
]);

Log injection și înregistrări manipulate

Dacă o aplicație scrie nefiltrate introduceri în jurnal, un atacator poate produce, cu întreruperi de rând, înregistrări falsificate. Aceasta încurcă analiza și poate ascunde urme. Cheat Sheet-ul OWASP recomandă formate structurate precum JSON, eliminarea sau codarea întreruperilor de rând și o limitare a lungimii pentru introducerile din jurnal.

La fel de important este protecția jurnalelor însele:

1. Depunere în afara webroot-ului și cu drepturi de care utilizatorul serverului web are nevoie pentru scriere, dar nu pentru ștergerea fișierelor vechi.
2. Copie pe un al doilea sistem, de exemplu prin Syslog printr-o conexiune criptată. Cine preia serverul nu trebuie să poată șterge pur și simplu urmele.
3. Limitați accesul de citire și jurnalizați-l la rândul lui. Jurnalele conțin aproape întotdeauna date cu caracter personal.
4. Recunoașteți căderea: Dacă jurnalul rămâne brusc gol, este un semnal de alarmă.
5. Sincronizați ora: Toate serverele iau ora din aceeași sursă și scriu în jurnal un fus orar fără echivoc. Altfel, înregistrările serverului web, ale PHP și ale bazei de date pot fi greu asamblate într-o cronologie după un incident.

Decideți conștient asupra păstrării și protecției datelor

Cât timp au voie și trebuie să rămână jurnalele este o cântărire între interesul de securitate, minimizarea datelor și cerințe legale sau contractuale. Art. 32 RGPD cere măsuri tehnice și organizatorice adecvate riscului, printre altele pentru a asigura durabil confidențialitatea, integritatea și disponibilitatea sistemelor; jurnalizarea poate contribui la aceasta. În același timp, datele cu caracter personal nu au voie să fie stocate mai mult decât este necesar.

Stabiliți de aceea un termen pentru fiecare tip de jurnal, notați motivarea și convenți ambele cu responsabilul dumneavoastră cu protecția datelor. Pentru o investigație în curs poate fi necesar să salvați jurnale dincolo de termenul normal. Și acest lucru ar trebui documentat. Această pagină este informație generală și nu reprezintă consiliere juridică; la întrebări concrete ajută responsabilul cu protecția datelor și avocatul. Cum analizați jurnalele după un atac arată Analiza jurnalelor serverului web după un atac.

Cum ajută PHP SOS concret?

• Verificăm jurnalele dumneavoastră existente pentru parole, token-uri și alte date care nu aparțin acolo.
• Configurăm PHP și aplicația astfel încât erorile să fie jurnalizate, dar nu afișate.
• Configurăm o copie protejată a jurnalelor pe un sistem separat.
• Prin monitorizarea de securitate analizăm continuu înregistrările relevante pentru securitate și raportăm înțeles ce iese în evidență.

Concluzie: Jurnalele bune sunt econome la conținut și generoase la protecție. Cine stabilește astăzi ce se jurnalizează și ce niciodată are, în caz de urgență, urme utilizabile și nicio scurgere de date suplimentară.

Întrebări frecvente

Surse

• OWASP: Logging Cheat Sheet
• PHP-FIG: standardele PSR
• Manualul PHP
• OWASP Top 10