Röviden: A naplózás PHP-ban, az adatvédelemre tekintettel, azt jelenti: a biztonság szempontjából releváns eseményeket teljes körűen rögzíteni, a jelszavakat, tokeneket, munkamenet-azonosítókat és az érzékeny ügyféladatokat viszont soha nem a logba írni. A hibák a naplóba valók, nem a képernyőre, a naplók a webrooton kívül vannak, és védettek a módosítás ellen. Hogy a naplók meddig maradnak, azt tudatosan, az adatvédelmi tisztviselővel együtt döntse el.
Nyomrögzítés és adatszivárgás között
A PHP2Shell után a szakmédiumok azt javasolták, hogy a webszerver-naplókat 2026. október 20-tól őrizzék meg. Aki ezt meg akarta valósítani, gyakran kétféle dolgot állapított meg. Vagy a naplók már régen rotálva és törölve voltak. Vagy olyan dolgokat tartalmaztak, amelyeknek soha nem lett volna szabad ott állniuk: teljes űrlapbemeneteket, sikertelen bejelentkezések jelszavait, URL-ekben lévő API-kulcsokat.
Mindkettő probléma. Naplók nélkül egy incidens aligha rekonstruálható. Túl sok tartalommal maga a napló válik célponttá, mert aki hozzáférést szerez a szerverhez, szívesen elolvassa. A jó naplózás a kettő között van: elég a nyomkereséshez, a lehető legkevesebb védendő adat.
Mit kell naplóznia egy PHP-alkalmazásnak
Az OWASP Logging Cheat Sheet megnevezi azokat az eseményeket, amelyek a biztonság és a visszakövethetőség szempontjából számítanak. A tipikus PHP-alkalmazásokra ez így foglalható össze:
| A logba | Nem a logba |
|---|---|
| sikeres és sikertelen bejelentkezések | jelszavak, a hibásan megadottak is |
| sikertelen jogosultság-ellenőrzések | munkamenet-azonosítók nyílt szövegben |
| változások a fiókokban és jogokban | access tokenek és API-kulcsok |
| hibák a bemenet ellenőrzésénél | az adatbázis hozzáférési adatai |
| feltöltések, importok és exportok | fizetési és bankadatok |
| konfigurációs változások, indítás és leállítás | egészségügyi adatok és más különösen védendő adatok |
| futásidejű hibák helymegadással, felhasználói adatok nélkül | teljes űrlaptartalmak |
Minden bejegyzésnek meg kell válaszolnia a mikor, hol, ki és mi kérdéseket: időbélyeg, alkalmazás és host, forráscím, felhasználói azonosító, az esemény fajtája és eredménye. A neveket vagy e-mail-címeket gyakran maszkolni lehet, vagy belső azonosítóval helyettesíteni a haszon elvesztése nélkül.
A naplóban lévő nem kívánt adatok két forrása gyakran elkerüli a figyelmet. Az első az URL-ek: ha egy token, egy jelszó-visszaállító kulcs vagy egy e-mail-cím a lekérdezési stringben áll, automatikusan a webszerver access logjába, a proxynaplókba és a böngészőelőzményekbe kerül. Az ilyen értékek a kérés törzsébe vagy egy fejlécbe valók, nem a címbe. A második forrás a debug mód. A keretrendszerek és bővítmények debug üzemben gyakran teljes kéréseket, adatbázis-lekérdezéseket és környezeti változókat is kiírnak. Ha ez a mód egy hibakeresés után aktív marad, észrevétlenül egy olyan fájl nő, amelyben éppen azok az információk vannak, amelyeket a támadó keres. Minden hibakeresés után ellenőrizze, hogy a debug kimenetek ismét ki vannak-e kapcsolva, és törölje a közben keletkezett fájlokat.
Naplózás PHP-ban: az alapbeállítások
Az első szint maga a PHP. Éles üzemben a hibákat naplózni kell, de nem kiírni. A napló a webrooton kívül van, hogy ne legyen lekérhető URL-en keresztül.
; php.ini vagy FPM-pool éles üzemhez
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/app-error.log
Hogy a látható hibák miért veszélyesek, azt a Hibakimenetek kikapcsolása éles üzemben írja le. Hogy a hibák és a kivételek hogyan függnek össze a PHP-ban, azt a Hibák és kivételek PHP-ban magyarázza el.
A második szint az alkalmazás. Sok keretrendszer erre a PHP-FIG PSR-3 szabványa szerinti könyvtárat használ, amely egységes logger-interfészt határoz meg. Nem a könyvtár a fontos, hanem a fegyelem: a kontextusadatokat tudatosan kiválasztani, ahelyett hogy egész kéréseket vagy objektumokat írnának a logba.
<?php
// A bemeneteket naplózás előtt semlegesíteni és maszkolni
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'] ?? '',
// soha: 'passwort' => $_POST['passwort']
]);
Log-injection és manipulált bejegyzések
Ha egy alkalmazás a bemeneteket szűretlenül írja a logba, a támadó sortörésekkel hamis bejegyzéseket hozhat létre. Ez összezavarja a kiértékelést, és nyomokat takarhat el. Az OWASP Cheat Sheet strukturált formátumokat, például JSON-t, a sortörések eltávolítását vagy kódolását és a logban lévő bemenetek hosszkorlátját ajánlja.
Ugyanilyen fontos maguknak a naplóknak a védelme:
- Tárolás a webrooton kívül, olyan jogokkal, amelyekre a webszerver-felhasználónak írni kell, de régi fájlokat törölni nem.
- Másolat egy második rendszerre, például syslogon keresztül titkosított kapcsolaton. Aki átveszi a szervert, ne törölhesse egyszerűen a nyomokat.
- Az olvasási hozzáférés korlátozása, és maga is naplózott. A naplók szinte mindig személyes adatokat tartalmaznak.
- A kiesés felismerése: ha a napló hirtelen üres marad, az figyelmeztető jel.
- Az idő egyeztetése: minden szerver ugyanabból a forrásból kapja az időt, és egyértelmű időzónát ír a logba. Különben a webszerver, a PHP és az adatbázis bejegyzései egy incidens után aligha illeszthetők össze idővonallá.
Az a napló, amely csak a feltört szerveren van, gyenge bizonyítási eszköz. Egy futó másolat egy különálló rendszeren egy incidens után gyakran az egyetlen megbízható forrás.
A megőrzés és az adatvédelem tudatos eldöntése
Hogy a naplók meddig maradhatnak és kell maradniuk, az a biztonsági érdek, az adattakarékosság, valamint a törvényi vagy szerződéses előírások közötti mérlegelés. A GDPR 32. cikke a kockázattal arányos technikai és szervezési intézkedéseket követel, többek között a rendszerek bizalmasságának, sértetlenségének és rendelkezésre állásának tartós biztosítására; a naplózás hozzájárulhat ehhez. Ugyanakkor a személyes adatokat nem szabad a szükségesnél tovább tárolni.
Ezért naplótípusonként állapítson meg határidőt, írja le az indoklást, és mindkettőt egyeztesse az adatvédelmi tisztviselőjével. Egy folyamatban lévő vizsgálathoz szükséges lehet a naplókat a szokásos határidőn túl is megőrizni. Ezt szintén dokumentálni kell. Ez az oldal általános információ, nem jogi tanácsadás; konkrét kérdésekben az adatvédelmi tisztviselők és az ügyvéd segít. Hogyan értékelheti a naplókat egy támadás után, azt a Webszerver-naplók kiértékelése egy támadás után mutatja.
Hogyan segít konkrétan a PHP SOS?
- Ellenőrizzük a meglévő naplóit jelszavak, tokenek és más olyan adatok után, amelyek nem oda valók.
- A PHP-t és az alkalmazást úgy állítjuk be, hogy a hibákat naplózza, de ne jelenítse meg.
- Védett másolatot állítunk be a naplókról egy különálló rendszeren.
- A biztonsági monitoringon keresztül folyamatosan kiértékeljük a biztonság szempontjából releváns bejegyzéseket, és érthetően jelezzük a feltűnőt.
Összegzés: A jó naplók takarékosak a tartalomban és bőkezűek a védelemben. Aki ma meghatározza, mit naplóznak, és mit soha, éles helyzetben felhasználható nyomokkal rendelkezik, nem pedig további adatszivárgással.
Gyakori kérdések
Szerepelhetnek IP-címek a naplófájlokban?
Az IP-címek személyes adatok lehetnek. Hogy tárolhatja-e őket, és meddig, a céltól és a jogalaptól függ. A terjedelmet és a megőrzést egyeztesse az adatvédelmi tisztviselőjével; ez az oldal nem jogi tanácsadás.
Meddig kell megőrizni a naplókat?
Addig, amíg a biztonsághoz és a hibakereséshez szükséges és jogilag megengedett, és nem tovább. A PHP2Shell után a szaksajtó azt javasolta, hogy a webszerver-naplókat 2026. október 20-tól őrizzék meg. A határidőket tudatosan állapítsa meg és dokumentálja.
Mi az a log-injection?
Ha egy bemenet sortöréseket vagy vezérlőkaraktereket tartalmaz, és szűretlenül írják a logba, hamis bejegyzéseket hozhat létre. Ez meghamisítja a kiértékeléseket. Strukturált formátumok, mint a JSON, és a sortörések eltávolítása ezt megakadályozza.
Ki legyen kapcsolva a display_errors éles üzemben?
Igen. A hibák a logba valók, nem a látogatóknak szóló kimenetbe. A látható hibaüzenetek elárulják az útvonalakat, lekérdezéseket és olykor a hozzáférési adatokat.