Varno beleženje: napake beležite brez uhajanja podatkov

Na kratko: Beleženje v PHP z ozirom na varstvo podatkov pomeni: varnostno pomembne dogodke popolnoma zabeležiti, gesel, žetonov, identifikatorjev sej in občutljivih podatkov strank pa nikoli ne zapisati v dnevnik. Napake sodijo v dnevnik, ne na zaslon, dnevniki ležijo zunaj webroota in so zaščiteni pred spremembami. Kako dolgo dnevniki ostanejo, se odločite zavestno skupaj s pooblaščencem za varstvo podatkov.

Med zavarovanjem sledi in uhajanjem podatkov

Po PHP2Shell so strokovni mediji svetovali hranjenje dnevnikov spletnega strežnika od 20. 10. 2026. Kdor je to hotel izvesti, je pogosto ugotovil dvoje. Ali so bili dnevniki že zdavnaj zavrteni in izbrisani. Ali pa so vsebovali stvari, ki tam nikoli ne bi smele stati: popolne vnose obrazcev, gesla iz neuspelih prijav, ključe API v URL-jih.

Oboje je težava. Brez dnevnikov incidenta skoraj ni mogoče rekonstruirati. S preveč vsebine postane dnevnik sam cilj, saj ga kdor pride do strežnika, rad prebere zraven. Dobro beleženje leži vmes: dovolj za iskanje sledi, čim manj zaščitenih podatkov.

Kaj naj aplikacija PHP beleži

OWASP Logging Cheat Sheet navaja dogodke, ki štejejo za varnost in sledljivost. Za tipične aplikacije PHP jih je mogoče povzeti takole:

Vsak vnos naj odgovori na vprašanja kdaj, kje, kdo in kaj: časovni žig, aplikacija in gostitelj, izvorni naslov, oznaka uporabnika, vrsta dogodka in rezultat. Imena ali e-poštne naslove je pogosto mogoče maskirati ali nadomestiti z notranjo oznako, ne da bi izgubili korist.

Dva vira neželenih podatkov v dnevniku se pogosto spregledata. Prvi so URL-ji: če žeton, ključ za ponastavitev gesla ali e-poštni naslov stoji v nizu poizvedbe (query string), samodejno pristane v dnevniku dostopa spletnega strežnika, v dnevnikih proxyja in v zgodovini brskalnika. Take vrednosti sodijo v telo zahteve ali glavo, ne v naslov. Drugi vir je način za odpravljanje napak. Ogrodja in vtičniki v tem načinu pogosto zapisujejo popolne zahteve, poizvedbe v bazo in spremenljivke okolja. Če ta način po iskanju napak ostane aktiven, neopazno raste datoteka natanko s podatki, ki jih napadalec išče. Po vsakem iskanju napak preverite, ali so izpisi za odpravljanje napak spet izklopljeni, in izbrišite datoteke, ki so pri tem nastale.

Beleženje v PHP: osnovne nastavitve

Prva raven je sam PHP. V produkciji naj se napake beležijo, a ne izpisujejo. Dnevnik leži zunaj webroota, da ni dosegljiv prek URL.

; php.ini ali pool FPM za produkcijo
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/app-error.log

Zakaj so vidne napake nevarne, opisuje prispevek Izklop izpisa napak v produkciji. Kako napake in izjeme v PHP sodelujejo, pojasnjuje Napake in izjeme v PHP.

Druga raven je aplikacija. Mnoga ogrodja za to uporabljajo knjižnico po standardu PSR-3 skupine PHP-FIG, ki določa enoten vmesnik za beleženje. Pomembna ni knjižnica, ampak disciplina: kontekstne podatke izbirajte zavestno, namesto da bi v dnevnik pisali cele zahteve ali objekte.

<?php
// Vnose pred beleženjem razstrupite in maskirajte
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'] ?? '',
    // nikoli: 'passwort' => $_POST['passwort']
]);

Log injection in manipulirani vnosi

Če aplikacija vnose nefiltrirano zapisuje v dnevnik, lahko napadalec s prelomi vrstic ustvari ponarejene vnose. To zmede analizo in lahko prikrije sledi. OWASP Cheat Sheet priporoča strukturirane oblike, kot je JSON, odstranjevanje ali kodiranje prelomov vrstic in omejitev dolžine vnosov v dnevniku.

Enako pomembna je zaščita samih dnevnikov:

1. Shranjevanje zunaj webroota s pravicami, ki jih uporabnik spletnega strežnika potrebuje za pisanje, ne pa za brisanje starih datotek.
2. Kopija na drugem sistemu, na primer prek syslog po šifrirani povezavi. Kdor prevzame strežnik, naj sledi ne more preprosto izbrisati.
3. Omejite bralni dostop in ga sami beležite. Dnevniki skoraj vedno vsebujejo osebne podatke.
4. Prepoznajte izpad: če dnevnik nenadoma ostane prazen, je to opozorilni znak.
5. Uskladite uro: vsi strežniki naj čas prejemajo iz istega vira in v dnevnik zapisujejo nedvoumen časovni pas. Sicer vnosov spletnega strežnika, PHP in baze podatkov po incidentu skoraj ni mogoče sestaviti v časovnico.

Hrambo in varstvo podatkov določite zavestno

Kako dolgo smejo in morajo dnevniki ostati, je tehtanje med varnostnim interesom, zmanjševanjem količine podatkov in zakonskimi ali pogodbenimi zahtevami. 32. člen GDPR zahteva tehnične in organizacijske ukrepe, ki so sorazmerni tveganju, med drugim za trajno zagotavljanje zaupnosti, celovitosti in razpoložljivosti sistemov; beleženje lahko k temu prispeva. Hkrati se osebni podatki ne smejo hraniti dlje, kot je nujno.

Zato za vsako vrsto dnevnika določite rok, zapišite utemeljitev in oboje uskladite s pooblaščencem za varstvo podatkov. Za tekočo preiskavo bo morda treba dnevnike zavarovati prek običajnega roka. Tudi to naj se dokumentira. Ta stran je splošna informacija in ni pravno svetovanje; pri konkretnih vprašanjih pomagajo pooblaščenci za varstvo podatkov in odvetnik. Kako dnevnike ovrednotite po napadu, kaže Ocena dnevnikov spletnega strežnika po napadu.

Kako konkretno pomaga PHP SOS?

• Preverimo vaše obstoječe dnevnike glede gesel, žetonov in drugih podatkov, ki tja ne sodijo.
• PHP in aplikacijo nastavimo tako, da se napake beležijo, a ne prikazujejo.
• Vzpostavimo zaščiteno kopijo dnevnikov na ločenem sistemu.
• Prek varnostnega nadzora sproti ovrednotimo varnostno pomembne vnose in razumljivo javimo nenavadnosti.

Sklep: Dobri dnevniki so skopi pri vsebini in radodarni pri zaščiti. Kdor danes določi, kaj se beleži in kaj nikoli, ima v skrajnem primeru uporabne sledi in ne dodatnega uhajanja podatkov.

Pogosta vprašanja

Viri

• OWASP: Logging Cheat Sheet
• PHP-FIG: standardi PSR
• Priročnik PHP
• OWASP Top 10