# Biztonságos naplózás: hibák rögzítése adatszivárgás nélkül

> Hibák és események naplózása PHP-ban jelszavak, tokenek és ügyféladatok felfedése nélkül: mi való a logba, mi nem, és hogyan védi meg a naplókat.

Forrás: https://phpsos.de/hu/blog/sicher-loggen-php/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**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.

```ini
; 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](https://phpsos.de/hu/blog/display-errors-produktion/) í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](https://phpsos.de/hu/php/fehler-und-exceptions/) 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
<?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:

1. **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.
2. **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.
3. **Az olvasási hozzáférés korlátozása**, és maga is naplózott. A naplók szinte mindig személyes adatokat tartalmaznak.
4. **A kiesés felismerése:** ha a napló hirtelen üres marad, az figyelmeztető jel.
5. **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á.

> **Fontos:**
> 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](https://phpsos.de/hu/ratgeber/logfiles-auswerten/) 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](https://phpsos.de/hu/leistungen/security-monitoring/) 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.

## Források

- [OWASP: Logging Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html)
- [PHP-FIG: PSR-szabványok](https://www.php-fig.org/)
- [PHP kézikönyv](https://www.php.net/manual/de/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)